Skip to content

Instantly share code, notes, and snippets.

@Inclushe

Inclushe/book-of-accessibility-notes.md

Last active April 15, 2022 21:28
Show Gist options
  • Save Inclushe/437f077ee0d13af768631a2822fbf98c to your computer and use it in GitHub Desktop.
Save Inclushe/437f077ee0d13af768631a2822fbf98c to your computer and use it in GitHub Desktop.
Download ZIP
The Book on Accessibility notes
Raw
book-of-accessibility-notes.md

The Book on Accessibility notes

  • Ideas
  • 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
      • 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment