Skip to content

Latest commit

 

History

History
314 lines (250 loc) · 19.2 KB

README.mx.md

File metadata and controls

314 lines (250 loc) · 19.2 KB
Raw

build status npm version license Coverage Status Total npm downloads

Obtenga soporte profesional para eslint-plugin-jsx-a11y en Tidelift

eslint-plugin-jsx-a11y

Comprobador AST estático para reglas de accesibilidad en elementos JSX.

¿Porque?

Ryan Florence desarrolló esta increíble herramienta de análisis de tiempo de ejecución llamada [react-a11y] (https://github.com/reactjs/react-a11y). Es super útil. Dado que probablemente ya esté utilizando linting en su proyecto, este plugin es gratuito y más cerca del proceso de development real. Si combina este plugin con un editor lint plugin, puede incorporar estándares de accesibilidad a su aplicación en tiempo real.

Nota: Este proyecto no * reemplaza * react-a11y, pero puede y debe usarse junto con él. Las herramientas de análisis estático no pueden determinar los valores de los variables que se colocan en props antes del tiempo de ejecución, así que el linting no fallará si ese valor no está definido y / o no pasa la regla de lint.

Instalación

Si está instalando este complemento a través de eslint-config-airbnb, por favor sigue estas instrucciones.

Primero tendrá que instalar ESLint:

# npm
npm install eslint --save-dev

# yarn
yarn add eslint --dev

Siguiente, instale eslint-plugin-jsx-a11y:

# npm
npm install eslint-plugin-jsx-a11y --save-dev

# yarn
yarn add eslint-plugin-jsx-a11y --dev

Nota: Si instaló ESLint globalmente (usando -g en npm, o el prefijo global en yarn) tambien tendra que instalar eslint-plugin-jsx-a11y globalmente.

Uso

Añade jsx-a11y a la sección de "plugins" de su .eslintrc archivo de configuración. Puede omitir el prefijo eslint-plugin- :

{
  "plugins": [
    "jsx-a11y"
  ]
}

Luego configure las reglas que quiera usar bajo la sección "rules".

{
  "rules": {
    "jsx-a11y/nombre-de-regla": 2
  }
}

También puede permitir todas las reglas recomendadas o estrictas de una vez. Añade plugin:jsx-a11y/recommended o plugin:jsx-a11y/strict dentro "extends":

{
  "extends": [
    "plugin:jsx-a11y/recommended"
  ]
}

Reglas Soportadas

Diferencia entre modos 'recomendedo' y 'estricto'

Regla Recomendedo Estricto
accessible-emoji error error
alt-text error error
anchor-has-content error error
anchor-is-valid error error
aria-activedescendant-has-tabindex error error
aria-props error error
aria-proptypes error error
aria-role error error
aria-unsupported-elements error error
autocomplete-valid error error
click-events-have-key-events error error
heading-has-content error error
html-has-lang error error
iframe-has-title error error
img-redundant-alt error error
interactive-supports-focus error error
label-has-associated-control error error
media-has-caption error error
mouse-events-have-key-events error error
no-access-key error error
no-autofocus error error
no-distracting-elements error error
no-interactive-element-to-noninteractive-role error, con opciones error
no-noninteractive-element-interactions error, con opciones error
no-noninteractive-element-to-interactive-role error, con opciones error
no-noninteractive-tabindex error, con opciones error
no-onchange error error
no-redundant-roles error error
no-static-element-interactions error, con opciones error
role-has-required-aria-props error error
role-supports-aria-props error error
scope error, con opciones error
tabindex-no-positive error error

Las siguiente reglas tienen otras opciones disponibles cuando en modo recomendado:

no-interactive-element-to-noninteractive-role

'jsx-a11y/no-interactive-element-to-noninteractive-role': [
  'error',
  {
    tr: ['none', 'presentation'],
  },
]

no-noninteractive-element-interactions

'jsx-a11y/no-noninteractive-element-interactions': [
  'error',
  {
    handlers: [
      'onClick',
      'onMouseDown',
      'onMouseUp',
      'onKeyPress',
      'onKeyDown',
      'onKeyUp',
    ],
  },
]

no-noninteractive-element-to-interactive-role

'jsx-a11y/no-noninteractive-element-to-interactive-role': [
  'error',
  {
    ul: [
      'listbox',
      'menu',
      'menubar',
      'radiogroup',
      'tablist',
      'tree',
      'treegrid',
    ],
    ol: [
      'listbox',
      'menu',
      'menubar',
      'radiogroup',
      'tablist',
      'tree',
      'treegrid',
    ],
    li: ['menuitem', 'option', 'row', 'tab', 'treeitem'],
    table: ['grid'],
    td: ['gridcell'],
  },
]

no-noninteractive-tabindex

'jsx-a11y/no-noninteractive-tabindex': [
  'error',
  {
    tags: [],
    roles: ['tabpanel'],
  },
]

no-static-element-interactions

'jsx-a11y/no-noninteractive-element-interactions': [
  'error',
  {
    handlers: [
      'onClick',
      'onMouseDown',
      'onMouseUp',
      'onKeyPress',
      'onKeyDown',
      'onKeyUp',
    ],
  },
]

Creando una nueva regla

Si está desarrollando nuevas reglas para este proyecto, puede usar el create-rule script para aplicar scaffolding a los nuevos archivos.

$ ./scripts/create-rule.js my-new-rule

Contexto sobre WAI-ARIA, el árbol AX y los navegadores

API de accesibilidad

El sistema operativo proporcionará un API de accesibilidad que mapea el estado y el contenido de la aplicación en controladores de entrada / salida, como ejemplo un lector de pantalla, dispositivo braille, teclado, etc.

Estas APIs se desarrollaron cuando las interfaces de computadora se cambiaron de búferes (que son basados en texto e intrínsecamente bastante accesibles) a interfaces gráficas de usuario (GUI). Los primeros intentos de hacer GUIs accesibles involucraron el análisis sintáctico de imágenes ráster para reconocer caracteres, palabras, etc. Esta información se almacenó en un búfer paralelo y se hizo accesible a los dispositivos de tecnología de asistencia (AT).

Las GUIs se volvieron más complejas, y el análisis sintáctico ráster se volvió insostenible. Las APIs de accesibilidad fueron desarrolladasolladas para reemplazarlas. Consulte NSAccessibility (AXAPI) por ejemplos. Consulte Core Accessibility API Mappings 1.1 para más detalles.

Navegadores

Los navegadores apoyan ciertad API de accesibilidad dependiendo en el sistema operativo. Por ejemplo, Firefox implementa la API de accesibilidad MSAA en Windows, pero no implementa AXAPI en OSX.

El árbol de accesibilidad (AX) y DOM

De parte de W3 Core Accessibility API Mappings 1.1

El árbol de accesibilidad y el árbol DOM son estructuras paralelas. En términos generales, el árbol de accesibilidad es un subconjunto del árbol DOM. Incluye los objetos de la interfaz de usuario y los objetos del documento. Los objetos accesibles se crean en el árbol de accesibilidad por cada elemento DOM que debe ser expuesto a la tecnología de asistencia, ya sea porque puede desencadenar un evento de accesibilidad o porque tiene una propiedad, relación o característica que debe exponerse. Generalmente, si algo puede ser omitido, sera, por razones de rendimiento y simplicidad. Por ejemplo, un <span> con solo un cambio de estilo y sin semántica puede que no obtenga su propio objeto accesible, pero el cambio de estilo será expuesto por otros medios.

Los proveedores de navegadores están comenzando a exponer el árbol AX a través de herramientas de inspección. Chrome tiene un experimento disponible para permitir su herramienta de inspección.

También puede ver una versión basada en texto del árbol AX en Chrome en la versión estable.

Ver el árbol de AX en Chrome

  1. Navegar a chrome://accessibility/ en Chrome.
  2. Cambie el accessibility off enlace por cualquier tab que quiere inspeccionar.
  3. Un enlace mostrando show accessibility tree aparecerá; seleccione el enlace.
  4. Vacile ansiosamente a la pantalla de texto, pero luego recupere su convicción.
  5. Utilice el comando de búsqueda para localizar cadenas y valores en el texto.

Juntándolo todo

El navegador construye un árbol AX como un subconjunto del DOM. ARIA informa en gran medida las propiedades del árbol AX. Este árbol AX está expuesto a la API de accesibilidad a nivel del sistema, que actúa como intermediario en los agentes de tecnología de asistencia.

Modelamos ARIA en el proyecto aria-query. Modelamos AXObjects (que componen el árbol AX) en el proyecto axobject-query. El objetivo de la especificación WAI-ARIA es ser una interfaz declarativa completa para el modelo AXObject. La versión 1.2 en borrador avanza hacia este objetivo. Pero hasta entonces, debemos considerar las construcciones semánticas que ofrece ARIA, así como las que ofrece el modelo AXObject (AXAPI) para determinar cómo se puede usar HTML para expresar las ofrendas de la interfaz de usuario para los usuarios de tecnología de asistencia.

Licencia

eslint-plugin-jsx-a11y es licenciada bajo el MIT License.