Навыки accessibility-fundamentals

accessibility-fundamentals

Безопасно

Revisar JSX para Accesibilidad

Muchos desarrolladores crean barreras involuntariamente para usuarios con discapacidades. Esta habilidad proporciona una lista de verificación sistemática para revisar componentes JSX según las pautas WCAG, asegurando que tu código sea inclusivo y legalmente conforme.

Поддерживает: Claude Codex Code(CC)
📊 69 Адекватно
1

Скачать ZIP навыка

2

Загрузить в Claude

Перейдите в Settings → Capabilities → Skills → Upload skill

3

Включите и начните использовать

Протестировать

Использование «accessibility-fundamentals». <div onClick={handleSubmit} className="submit-btn">Submit</div>

Ожидаемый результат:

Este elemento tiene problemas de accesibilidad:
1. No es accesible por teclado - los elementos div no responden a las teclas Enter/Espacio
2. No es anunciado como botón por los lectores de pantalla
3. Falta el rol semántico

Solución: Usar el elemento <button> en su lugar:
<button onClick={handleSubmit} className="submit-btn">Submit</button>

Использование «accessibility-fundamentals». <input type="email" placeholder="Enter your email" />

Ожидаемый результат:

Este campo de entrada carece de accesibilidad:
1. No tiene etiqueta visible - el placeholder desaparece al escribir
2. Los lectores de pantalla no pueden anunciar el propósito

Opciones de solución:
<label>
Email
<input type="email" placeholder="Enter your email" />
</label>

O:
<label htmlFor="email">Email</label>
<input id="email" type="email" placeholder="Enter your email" />

Использование «accessibility-fundamentals». <button><TrashIcon /></button>

Ожидаемый результат:

Los botones solo con iconos necesitan nombres accesibles:
1. Los lectores de pantalla anuncian como "button" sin contexto

Solución: Agregar aria-label:
<button aria-label="Delete item">
<TrashIcon aria-hidden="true" />
</button>

Аудит безопасности

Безопасно
v6 • 1/21/2026

All 63 static findings are false positives. The scanner misinterpreted markdown code block delimiters as shell execution, ARIA attributes as cryptographic patterns, and CSS color hex values as IP addresses. This is a legitimate accessibility documentation skill containing only static guidance and code examples.

2
Просканировано файлов
982
Проанализировано строк
0
находки
6
Всего аудитов
Проблем безопасности не найдено

Оценка качества

38
Архитектура
100
Сопровождаемость
85
Контент
20
Сообщество
100
Безопасность
91
Соответствие спецификации

Что вы можете построить

Revisión de Código para Componentes React

Antes de fusionar solicitudes de extracción, invoca esta habilidad para verificar que los nuevos componentes interactivos cumplan con los estándares de accesibilidad. Detecta problemas como etiquetas faltantes, anti-patrones de div-como-botón y mala gestión del enfoque.

Aprender Patrones de Diseño Inclusivo

Los nuevos miembros del equipo usan esta habilidad para comprender los requisitos de accesibilidad. La habilidad proporciona ejemplos concretos de patrones de código accesibles vs inaccesibles con explicaciones.

Auditoría de Accesibilidad para Funcionalidades

Antes de lanzar nuevas funcionalidades, usa esta habilidad para verificar el cumplimiento con los requisitos de accesibilidad. Cubre modales, formularios, menús de navegación y actualizaciones dinámicas de contenido.

Попробуйте эти промпты

Verificación Rápida de Componente
Review this JSX component for accessibility issues. Check for keyboard accessibility, proper form labels, semantic HTML, and screen reader support.
Revisión de Accesibilidad de Formulario
Review this form component. Check that every input has a label, error messages are linked with aria-describedby, and required fields are marked appropriately.
Auditoría de Diálogo Modal
Check this modal component. Verify focus trapping works, escape key closes it, keyboard focus is managed, and it has proper ARIA attributes.
Revisión de Menú de Navegación
Review this navigation component. Check keyboard navigation works, active states are announced, and menu structure is semantic.

Лучшие практики

  • Usar elementos semánticos nativos (<button>, <a>, <input>) en lugar de divs con controladores de eventos
  • Cada campo de entrada de formulario debe tener una etiqueta visible y asociada
  • Todos los elementos interactivos deben ser accesibles por teclado con estados de enfoque visibles

Избегать

  • Usar <div onClick> en lugar de <button> - rompe el soporte de teclado y lector de pantalla
  • Eliminar outline: none sin reemplazo - deja perdidos a los usuarios de teclado
  • Usar solo color para transmitir información - falla para usuarios daltónicos

Часто задаваемые вопросы

¿Cuál es la relación mínima de contraste de color para texto?
El texto normal requiere una relación de contraste de 4.5:1 contra el fondo. El texto grande (18px negrita o 24px regular) requiere una relación de 3:1.
¿Cómo hago accesible un modal?
Atrapar el enfoque dentro del modal mientras esté abierto, devolver el enfoque al elemento activador cuando se cierre, incluir la tecla Escape para cerrar, y agregar aria-modal="true".
¿Cuál es la primera regla de ARIA?
Ningún ARIA es mejor que ARIA mal usado. Usar HTML semántico nativo primero. Solo agregar ARIA cuando HTML no pueda expresar lo que necesitas.
¿Cómo pruebo la accesibilidad sin herramientas?
Navegar toda tu página usando solo Tab y el teclado. Verificar que puedas completar todas las acciones, que el enfoque siempre sea visible y que no puedas quedar atrapado.
¿Qué es focus-visible y cuándo debo usarlo?
focus-visible muestra indicadores de enfoque solo cuando se navega por teclado, ocultándolos para usuarios de ratón. Usar :focus-visible para lo mejor de ambos mundos.
¿Cómo hago accesibles los mensajes de error?
Vincular errores a campos de entrada con aria-describedby, establecer aria-invalid="true" en campos no válidos, y usar role="alert" o aria-live para anuncios.

Сведения для разработчиков

Автор

DanielPodolsky

Лицензия

MIT

Ссылка

main

Структура файлов

📄 SKILL.md