2. HTML and Accessibility

ARIA (Accessible Rich Internet Applications)

Accessible Rich Internet Applications (ARIA) es un conjunto de atributos que definen formas de hacer que los contenidos y aplicaciones web (especialmente los desarrollados con JavaScript) sean más accesibles para las personas con discapacidad.

Complementa el HTML para que las interacciones y los widgets utilizados habitualmente en las aplicaciones puedan pasarse a las tecnologías de asistencia cuando no exista otro mecanismo. Por ejemplo, ARIA permite utilizar puntos de referencia de navegación accesibles en HTML4, widgets de JavaScript, sugerencias para formularios y mensajes de error, actualizaciones de contenido en directo, etc.

Estas son algunas pautas de accesibilidad relacionadas con ARIA:

[aria-*]cada rol ARIA admite un subconjunto específico de atributos aria-. Si no coinciden, los atributos aria- quedan invalidados. Más información.

[aria-hidden="true"] no está presente en el documento <body>. Las tecnologías de asistencia, como los lectores de pantalla, funcionan de forma incoherente cuando aria-hidden="true" se establece en el documento <body>. Más información.

button, link, y inputy elementos de entrada tienen nombres accesibles. Cuando un elemento no tiene un nombre accesible, los lectores de pantalla lo anuncian con un nombre genérico, lo que lo hace inutilizable para los usuarios que dependen de lectores de pantalla. Más información.

meter, progressbar, tooltip, treeitem, y menuitem tienen nombres accesibles. Cuando un elemento no tiene un nombre accesible, los lectores de pantalla lo anuncian con un nombre genérico, lo que lo hace inutilizable para los usuarios que dependen de lectores de pantalla. Más información.

[aria-hidden="true"]no contienen descendientes enfocables Los descendientes enfocables dentro de un elemento [aria-hidden="true"] impiden que esos elementos interactivos estén disponibles para los usuarios de tecnologías de asistencia, como los lectores de pantalla. Más información.

[role]tienen todos los atributos [aria-*] que describen el estado del elemento a los lectores de pantalla. Más información.

[role]son válidos los roles ARIA, deben tener valores válidos para realizar las funciones de accesibilidad previstas. Más información.

[aria-*]son válidos y no están mal escritos. Las tecnologías de asistencia, como los lectores de pantalla, no pueden interpretar los atributos ARIA con nombres no válidos. Más información.

Los elementos con un [role] ARIA requieren que los hijos contengan un [role] específico con todos los hijos requeridos. Algunos roles padre ARIA deben contener roles hijo específicos para realizar sus funciones de accesibilidad previstas. Más información.

Los campos ARIA toggle tienen nombres accesibles. Cuando un campo no tiene un nombre accesible, los lectores de pantalla lo anuncian con un nombre genérico, lo que lo hace inutilizable para los usuarios que dependen de lectores de pantalla. Más información.

Los controles personalizados tienen funciones ARIA Los controles interactivos personalizados tienen funciones ARIA adecuadas. Más información.

Las identificaciones ARIA ID's son únicas. El valor de una identificación ARIA debe ser único para evitar que las tecnologías de asistencia pasen por alto otras instancias. Más información.

Los controles personalizados tienen etiquetas asociadas. Los controles interactivos personalizados tienen etiquetas asociadas, proporcionadas por aria-label o aria-labelledby. Más información.

Navigation

Navigation is how users find and traverse the different pages available on your site. For this reason, navigation must be accessible. By their nature, links are tab-able and all keyboard users and screen readers will read them–so, if your navigation is coded with links, a screen reader should find them.

Here are some accessibility guidelines related to navigation:

  • HTML5 landmark elements are used to improve navigation Landmark elements (<main>, <nav>, etc.) are used to improve the keyboard navigation of the page for assistive technology. Learn more

  • The page contains a heading, skip link, or landmark region Adding ways to bypass repetitive content lets keyboard users navigate the page more efficiently. Learn more

  • [accesskey] values are unique Access keys let users quickly focus a part of the page. For proper navigation, each access key must be unique. Learn more

  • Visual order on the page follows DOM order DOM order matches the visual order, improving navigation for assistive technology. Learn more

  • The page has a logical tab order Tabbing through the page follows the visual layout. Users cannot focus elements that are offscreen. Learn more

  • No element has a [tabindex] value greater than 0 A value greater than 0 implies an explicit navigation ordering. Although technically valid, this often creates frustrating experiences for users who rely on assistive technologies. Learn more

  • Interactive controls are keyboard focusable Custom interactive controls are keyboard focusable and display a focus indicator. Learn more

  • The user's focus is directed to new content added to the page If new content, such as a dialog, is added to the page, the user's focus is directed to it. Learn more

  • User focus is not accidentally trapped in a region A user can tab into and out of any control or region without accidentally trapping their focus. Learn more

  • Buttons have an accessible name When a button doesn't have an accessible name, screen readers announce it as "button", making it unusable for users who rely on screen readers. Learn more

Previous1. What is accessibility?Next3. Semantic structure

Last updated