Diferencia real entre UIAccessibilityLayoutChangedNotification y UIAccessibilityScreenChangedNotification?
Estoy tratando de determinar qué sucede exactamente de manera diferente al publicar un UIAccessibilityLayoutChangedNotification y un UIAccessibilityScreenChangedNotification. Por lo que puedo ver, puedo usarlos indistintamente en todas partes y no sucede nada diferente.
La documentación de Apple simplemente dice usar LayoutChanged cuando (por ejemplo) se ha ocultado o mostrado un elemento, y usar ScreenChanged si cambia toda la pantalla, pero estoy interesado en lo que hacen cuando proporciono esta información, y lo que debería ver de manera diferente al usar uno o otro.
¿Puede alguien dar una explicación clara de las diferencias de implementación entre los dos?
2 answers
Estas dos notificaciones son para contenido dinámico en vistas y para comunicar estos cambios a VoiceOver para usuarios de screenreader. Hay poca diferencia entre estas dos notificaciones, excepto por su comportamiento predeterminado, y el tonto "boop beep" para las notificaciones de cambio de pantalla.
En ambos casos, el argumento
UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, arg);
Representa una cadena para ser leída, o un elemento en pantalla, al que VoiceOver cambiará su enfoque. En caso de dramatismo cambios de contexto, es importante enviar el foco a un lugar que tenga sentido, o anunciar que tales cambios han tenido lugar. Cualquiera de los dos enfoques es aceptable desde el punto de vista de la accesibilidad, aunque prefiero los enfoques que implican la menor cantidad de cambio posible. En el caso de cambios simples de diseño, casi siempre es mejor anunciar el cambio de contexto y dejar el foco donde estaba. Aunque a veces, el elemento que causó el cambio de contexto está oculto, y entonces es claramente necesario dirigir voiceover para resaltar el nuevo contenido, porque el comportamiento predeterminado en este caso es indefinido, o tal vez determinista, pero determinado por un marco que no sabe absolutamente nada acerca de su aplicación!
La diferencia entre los dos eventos, dado que ambos hacen exactamente lo mismo, está en su comportamiento predeterminado. Si usted suministra nil a la UIAccessibilityLayoutChangedNotification es como si usted no ha hecho nada. Si proporciona un argumento nil a UIAccessibilityScreenChangedNotification, enviará focus al primer UIObject en su jerarquía de vista que está marcada como un elemento accessibilityElement, una vez que todos los cambios de jerarquía de vista y dibujos están completos.
UIAccessibilityLayoutChangedNotification
Un buen ejemplo de caso de uso para UIAccessibilityLayoutChangedNotification es para formas dinámicas. Desea que los usuarios sepan que, en función de las decisiones que han tomado en el formulario, hay nuevas opciones disponibles. Por ejemplo, si en un formulario seleccionas que eres un veterano, pueden aparecer áreas adicionales del formulario para proporcionar más información, pero estas las áreas pueden haber sido ocultas a otros usuarios que no se preocuparon por ellas. Así que podría cambiar el enfoque a estos elementos después de la interacción del usuario:
UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, firstNewFormElement);
Que cambiaría el enfoque al elemento proporcionado, y anunciaría su accessibilityLabel.
O simplemente diles que los nuevos elementos de la forma están allí:
UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, @"Veterans form elements available");
Lo que dejaría el foco donde está, pero VoiceOver anunciaría "Veterans form elements available".
Nota: Este comportamiento en particular está iPad (8.1.2).
O finalmente podrías hacer esto:
UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, nil);
Que no hace absolutamente nada :). En serio, ni siquiera creo que al backend del framework a11y le importe. ¡Esta línea de código en particular es un completo desperdicio!
UIAccessibilityScreenChangedNotification
Un buen ejemplo de caso de uso para el UIAccessibilityScreenChangedNotification es situaciones de navegación por pestañas personalizadas. Cuando toda la pantalla, con la excepción de su área de navegación, cambia. Quieres que voiceover sepa que esencialmente toda la pantalla cambió, pero NO para enfocar el primer elemento (tu primera pestaña) sino para enfocar el primer elemento de contenido.
UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, firstNonGlobalNavElement);
Que reproduciría el sonido "boop beep" y luego cambiaría el enfoque a justo debajo de la barra de navegación global. O podrías hacer esto:
UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, @"You're on a new tab");
Que esperaría a que se cargue la nueva pestaña, reproduciría el sonido "beep boop", anunciaría" Estás en una nueva pestaña " en voiceover, luego cambiaría el enfoque al primer elemento en la pantalla, luego anunciaría el accessibilityLabel para ese elemento. (UF! ¡Eso es mucho! Esto es discordante para los usuarios de lectores de pantalla. Evitar este escenario, a menos que sea absolutamente necesario).
Y finalmente, por supuesto, puedes hacer esto:
UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, nil);
Que es equivalente a:
UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, firstA11yElement);
Ambos reproducirán el sonido "beep boop", cambiarán el enfoque de VoiceOver al primer elemento en la pantalla y luego lo anunciarán.
Finalmente
En un comentario alguien mencionó el almacenamiento en caché, y yo de vez en cuando comentar en mi respuesta acerca de las cosas que el Backend A11y puede o no importa. Si bien es ciertamente posible que haya algo de magia de backend sucediendo, no creo en ninguna de estas circunstancias, el back-end se preocupa en absoluto. La razón por la que digo esto es porque:
Si alguna vez has usado el protocolo UIAccessibilityContainer, puedes ver cómo se consulta tu contenedor de vistas. No hay almacenamiento en caché. Incluso la propiedad accessibilityElementCount recibe un ping cada vez que VoiceOver cambia de foco a un nuevo elemento de accesibilidad dentro de su contenedor. Luego pasa por el proceso de verificar en qué elemento está, preguntar por el siguiente elemento, y así sucesivamente. Está diseñado en su núcleo para manejar situaciones dinámicas. Si usted fuera a insertar un nuevo elemento en su contenedor después de la interacción, todavía ir a través de todas estas consultas y estar bien al respecto! Además, si anula las propiedades del protocolo UIAccessibility, con el fin de proporcionar sugerencias dinámicas y etiquetas, puede también ver que estas funciones se llaman cada vez! Como tal, creo que el backend del marco A11y obtiene ABSOLUTAMENTE CERO información de estas notificaciones. La única información que VoiceOver necesita para hacer su trabajo es su Elemento de Accesibilidad actualmente enfocado, y este contenedor de Accesibilidad de elementos. Las notificaciones simplemente están ahí para que su aplicación sea más utilizable para los usuarios de VoiceOver.
Imagine si este no fuera el caso cuántas veces Safari publicaría estos las notificaciones!!!! :)
Estas afirmaciones en particular solo pueden ser confirmadas por alguien con conocimiento de backend del framework, que trabaja con el código, y deben ser vistas como conjeturas. Podría ser el caso de que esto es altamente versión/implementación dependiente. Definitivamente abierto a la discusión sobre estos puntos! El resto de este post es bastante concreto.
Para Su Referencia
La mayor parte de esto proviene de la experiencia trabajando con los frameworks, pero aquí hay un referencia útil si desea profundizar más.
Https://developer.apple.com/documentation/uikit/accessibility/uiaccessibility
Https://developer.apple.com/documentation/uikit/uiaccessibilitylayoutchangednotification
Https://developer.apple.com/documentation/uikit/uiaccessibilityscreenchangednotification
Y finalmente, un repositorio de código abierto de la pequeña aplicación tonta que armé para probar todo esto cosa.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-06-29 17:10:23
UIAccessibilityScreenChangedNotification es indicar que toda la pantalla ha cambiado y VoiceOver debe restablecerse.
UIAccessibilityLayoutChangedNotification es indicar que uno o más elementos de la pantalla, pero no todos, han cambiado.
Cuando su interfaz de usuario cambia drásticamente. Por lo general, cuando un usuario se mueve a una parte diferente de su aplicación (navega a una pantalla diferente). VoiceOver notifica al usuario con un tono, borra sus cachés y hace otros preparativos para lidiar con un nuevo conjunto de datos de accesibilidad. Avisa a VoiceOver que la pantalla ha cambiado y puede haber nuevos elementos en la pantalla, por lo que VoiceOver reconstruirá su índice de elementos de accesibilidad.
UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, nil);
Si alguna parte de tu IU cambia, pero el usuario no necesariamente ha saltado a una parte completamente diferente de tu app. (Ejemplo: en la aplicación iTunes Store, toque en la etiqueta de precio ($0.99, etc.).) junto a una canción lo cambia a un botón "Comprar".) Esta notificación le dice a VoiceOver que vuelva a leer el estado actual de todos los elementos accesibles que están en pantalla, y al hacer esto, se da cuenta de lo que ha cambiado e informa al usuario de esos cambios. Avisa a VoiceOver de que el diseño ha cambiado y que su índice actual está desactualizado porque los elementos de la pantalla se han reordenado solos.
UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, nil);
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-02-04 23:52:24