Implement WCAG 2.1 compliant keyboard navigation for full accessibility. Core requirements: (1) All interactive elements accessible via keyboard (Tab, Shift+Tab, Enter, Space, Arrow keys), (2) No keyboard traps (users can navigate away from any element), (3) Visible focus indicators (3:1 contrast ratio minimum against background). Key patterns: Tab/Shift+Tab navigate between focusable elements (buttons, links, inputs), Enter activates buttons and links, Space toggles checkboxes and activates buttons, Arrow keys navigate within dropdowns, radio buttons, sliders, Escape closes modals and menus. HTML semantics: use native elements for free keyboard support:
Accessibility ensures web content is usable by everyone including people with disabilities. Importance: (1) Legal compliance: ADA Title III and Section 508 require accessibility in US, WCAG 2.1 is international standard, lawsuits increasing for non-compliance, (2) Expanded audience: 15% of world population has disabilities, elderly users need accessible design, temporary disabilities (broken arm, eye strain), (3) Better UX for all: keyboard navigation helps power users, captions help in noisy environments, clear language helps non-native speakers. WCAG 2.1 principles (POUR): (1) Perceivable: text alternatives for images, captions for videos, sufficient color contrast (4.5:1 for text), (2) Operable: keyboard accessible, enough time to interact, no seizure-inducing content, (3) Understandable: readable text, predictable behavior, error prevention and correction, (4) Robust: compatible with assistive technologies (screen readers, magnifiers). Key practices: semantic HTML (
Use semantic HTML and ARIA for accessible complex forms. Structure: (1) Fieldsets for grouped inputs:
, screen readers announce group context. (2) Labels for all inputs: , click label focuses input, screen readers read label. (3) Required field indicators: , both visual and semantic. (4) Error messages:- Step 1
- Step 2
- . (3) Multi-select:
Use ARIA to make custom controls accessible to assistive technologies. Custom checkbox: <div role="checkbox" aria-checked="false" tabindex="0" @click="toggle" @keydown.space.prevent="toggle">✓
- Option 1
Implement internationalization (i18n) with proper language metadata and content structure. HTML lang attribute: for primary language, Hola for inline changes, screen readers use this for pronunciation. Vue i18n setup: const i18n = createI18n({ locale: 'en', fallbackLocale: 'en', messages: { en: { greeting: 'Hello' }, es: { greeting: 'Hola' } } });. Usage: {{ $t('greeting') }} or const { t } = useI18n(); t('greeting');. Language switcher: <select @change="changeLocale" aria-label="Select language">. Store preference: localStorage.setItem('locale', locale); persist across sessions. RTL support: for Arabic, Hebrew, etc., CSS logical properties: margin-inline-start instead of margin-left, flexbox and grid automatically adjust. Pluralization: { "apple": "no apples | one apple | {count} apples" }, $t('apple', count). Number/date formatting: {{ n(1000, 'currency') }} → $1,000.00 (locale-aware), {{ d(date, 'long') }} → January 15, 2025. Accessibility considerations: (1) Set lang on dynamically loaded content, (2) Announce language changes to screen readers: