The Book on Accessibility notes

Ideas
- Use detailed checklists on https://www.magentaa11y.com/web/ for audits?
- How to test
- Add requirements to test with screen reader software + more?
- Plugins must be compliant with WCAG level AA as well
Strategic Goals
- Strategic goals are not tactics
- Publish compliance standards
  - MVP (minimum viable product) releases are WCAG level A feature compliant without exception
  - Core functionality products must meet WCAG level AA feature compliant
  - Check competitor's stance on it
- Remediate issues by priority
- Run automated and manual assessments
  - Manual should be in an excel spreadsheet
- Run a CI/CD with automated tests
Policies
- Policies are written to be enforced. While always imperfect, they should provide an expectation that must be met or consequences will ensue.
- Qualities of good policies
  - Enforceable
    - "All products must pass an automated Google Lighthouse accessibility score of 95"
  - Updatable
  - Adaptable to circumstances
- Core functionality meets WCAG AA
- Severity, priority & remediation
  - Blocker, High, Medium, Low
  - Make a set of simplified rules
12 Simple Rules
- Using only a keyboard (no mouse) all interactive elements (links, buttons, inputs) are intuitively and visibly functional.
- All features have appropriate names, roles and states for screenreaders
- Media that aid in understanding the content of the page must have alternative text
- Use headings to structure the page
- Contrast, color and size of text and controls must be easily distinguishable
- Use HTML landmarks to improve navigation for screenreaders
- Feature multiple ways to find information
- Required fields are indicated visually and in the code
- Offer programmatic hints and suggest ways to correct errors
- Don’t use media that flash more than 3x/second
- Don’t trap the keyboard user
- Don’t play audio or video media automatically
Design Systems
- Defines interactions for custom components
- Annotation layer and stickers
- Accessible component patterns
  - Uses logical headings
  - Decouples headings from styles
  - Vertical layout for forms
  - Allows for appropriate alt text
    - Good alt text would allow anyone who can’t see the screen to describe it to someone else
    - If an icon doesn’t add meaning or would be repetitive, the alt attribute should be empty
  - Avoid pure black and white
  - Don’t use color as the sole means of conveying content.
  - Uses large clickable target size
  - Includes focus states
  - Responds to reduced motion settings
Component Library
- Best practices documentation and support
- Accessibility requirements and policies
- Establishes help channels
Designers
- Can use assistive technology
  - Screenreader basics
    - Shortcut to browse by headings
    - Shortcut to browse by links
    - Shortcut to browse by landmarks
    - Browse content with the arrow keys
    - Focus interactive elements with the tab key
- Basic layout and structure
  - Design for mobile first
  - Keep elements vertically stacked and grouped by proximity
  - Consider simpler ways to convey content
    - Carousels are almost always a bad idea.
    - Tooltips are always a bad idea
    - Modals are often unnecessary and interruptive
    - Dropdown select menus should be used sparingly
    - Be wary of interactive mashups of controls
- Blindness
  - Define headings logically
    - Headings create a skimmable outline
  - Use alt text for images
    - Good alt text would allow anyone who can’t see the screen to describe it to someone else
    - If an icon doesn’t add meaning or would be repetitive, the alt attribute should be empty
  - Define aria-label for clear interactions
  - Define role for custom components
  - Define states for custom components
- Designing for Low vision
  - Associate controls visually
  - Paragraph typeface should be no smaller than 16px
    - Typeface scaling may differ
  - Justify text left, never fully justify text
  - Ensure color contrast meets guidelines
- Designing for color perception
  - Don’t use color as the sole means of conveying content
- Designing for motor disabilities
  - Design accounts for keyboard and switch devices
  - Focus order defined for custom components
  - Design for focus states
  - Clickable area minimum of 44x44px
- Designing for photosensitivity
  - Respond to reduced motion settings
  - Flashing content shouldn’t sequence more than 3x per second
  - Video or animations should have controls to be able to quickly pause
- Designing for cognitive differences
  - Use plain language
  - Align names and labels with purpose
  - Don’t write actionable sounding text that isn’t actionable
Developers
- Testing
  - Manual testing
    - Not the same as usability study
    - https://www.magentaa11y.com/
  - Automated testing
    - Even the most robust tools can identify less than half of the potential defects on a page.
  - Can test with assistive technology
  - Semantic HTML and WAI-ARIA
  - Can understand accessibility acceptance criteria
  - What are the components of acceptance criteria
    - Name
    - Role
    - State
    - Group
  - Can interpret accessibility assessments
- Assistive technology test suite
  - Desktop
    - Keyboard
    - PC + NVDA + Chrome (if testing with one reader)
    - Mac + VoiceOver + Safari (if testing with two readers)
    - PC + JAWS + Chrome (not always ideal)
  - Mobile
    - iOS device + VoiceOver + Bluetooth keyboard
    - Android device + Talkback + Bluetooth keyboard
- Definition of ready
  - UX includes accessibility annotation (code is the UX)
  - UX annotation should include notes for:
    - Heading structure
    - Aria labels for ambiguous controls
    - alt text for images
    - Correct semantic component (ex: is it a button or a link that just looks like a button)
- Definition of done
  - Product demos use assistive technology
  - Manual accessibility QA testing is complete
  - Uniform automated testing tools meet requirements

Inclushe/book-of-accessibility-notes.md

The Book on Accessibility notes