Toward amazing accessibility!

Introduction to accessibility testing and 'shifting left' to operationalise amazing accessibility throughout the development life cycle.

Synopsis

IT departments in the Higher Education sector and elsewhere know they must commit to accessibility, but how can we take this ambition and embed it within our operations?

Within the University of Southampton IT department (which is named iSolutions) senior leadership committed to delivering "amazing accessibility" but has not yet set out how this might happen.

In this internal presentation within the department, held on Global Accessibility Awareness Day on 20 May 2021, I attempt to show how we could start that journey. This was joint session of both the Digital Accessibility Community of Practice and the Testing Community of Practice. The event was open to all iSolutions staff.

Whilst some of the language and examples are specific to our department I believe many should find this information of interest and use.

Watch the presentation

Introduction: 0:00
What accessibility barriers might users experience?: 3:09
Examples from University of Southampton iSolutions services: 5:58
Introducing shift left and accessibility gatekeeping 8:56
Accessibility testing: 9:18
Automated tests: 11:52
Simple manual accessibility tests you can use now: 16:00
Gherkin tests: 26:44
Prioritising accessibility defects: 29:14
Accessibility in the build process: 30:16
Accessibility in the design process: 31:04
Accessibility in the requirements process: 35:04
Accessibility and UK law: 35:37
Accessibility statements: 37:41
Accessibility and procurement: 39:29
Accessibility in the release process: 41:18
So what now?: 43:52
A wave of momentum toward accessibility: 46:24

Slide deck

Videos and presentations referred to in the presentation

Back to top.

Other references

Back to top.

Testing

My Testing Spreadsheet

This is the testing spreadsheet I built.

Simple, achievable tests

  1. Run automated tests, verify failures, and report back to developers for resolution.
  2. Validate pages
    1. The above two should cover
      1. 2.4.2 Page Titled
      2. 4.1.1 Parsing
  3. Test the website is operable using a keyboard, do make sure to test at increased zoom, some interface details that are shown at increased zoom such as hamburger menu may not appear until a screen is zoomed in. Check that the colours of the focus indicators, and changes to buttons states etc have sufficient contrast.
    1. Check that the colours of the focus indicators, and changes to buttons states etc have at least 3:1 contrast compared with the unfocussed state. Focus indicators should have 4px thick indicator on the shortest side of the control (but no less than 2px thick).
    2. Confirm that
      1. You can skip repeated elements such as a navigation menu.
      2. All user pathways can be navigated using the keyboard without becoming "trapped" within an interface element.
      3. No specific timings are required for individual keystrokes.
      4. As you navigate using the keyboard that focusable components receive focus in an order that preserves meaning and operability.
      5. If keyboard shortcuts are implemented that these can either be
        1. Turned off
        2. Remapped to different keys
        3. Are only operable while keyboard focus is upon the relevant component.
    3. Covers:
      1. 2.1.1 Keyboard
      2. 2.1.2 No Keyboard Trap
      3. 2.1.3 Keyboard (No Exception)
      4. 2.1.4 Character Key Shortcuts
      5. 2.4.1 Bypass Blocks
      6. 2.4.11 Focus Appearance (Minimum)
      7. 2.4.12 Focus Appearance (Enhanced)
      8. 2.4.3 Focus Order
      9. 2.4.7 Focus Visible
  4. Test for reflow, text-resize and text-spacing
    1. Set the browser window to 1280px wide.
    2. Zoom in to 400%.
    3. Check content & functionality is available, and no horizontal scrolling (in LTR languages).
    4. Check text is at least 200% bigger.
    5. Turn on text-spacing (e.g. with a bookmarklet).
    6. Un-zoom through each media query, looking for overlaps / missing content.
      1. The above covers
        1. 1.4.4 Resize text
        2. 1.4.10 Reflow
        3. 1.4.12 Text Spacing
  5. Test in greyscale (use Accessibility Insights or Greyscale the web). Ensure the content and interface retain intended contextual meaning, i.e. that colour is not solely used to convey meaning.
    1. 4.1: Use of Colour
  6. Test with CSS disabled and images turned off. Confirm that content is still in sequence, usable, and understandable. Confirm that alternative text contextually meaningful.
    1. 1.1.1 Non-text Content
    2. 1.3.2 Meaningful Sequence
    3. 1.4.5 Images of Text
  7. Test in high contrast mode
    1. See Quick Tips for High Contrast Mode for tips on resolving issues.
    2. Is all necessary content displayed?
    3. Can you read all links, buttons, and controls?
    4. Is important information communicated through images still apparent?
    5. Are forms still understandable?
  8. Test with screen reader. Really listen to ensure that users who are not sighted are being given enough context to understand the experience.
    1. Using a screen reader
    2. How A Screen Reader User Surfs The Web
      1. Short excerpt
    3. Screen reader testing guide by Ross Mullen
    4. How screen readers navigate data tables
    5. 5 Myths About Screen Readers That Can Hurt Accessibility
    6. How Sighted and Blind Web Navigation Differs
    7. How can screen readers be used in accessibility testing?
    8. NVDA
      1. Useful keyboard shortcuts
      2. Testing accessibility using NVDA
      3. Accessibility Testing with NVDA
        1. How screenreader usage differs from keyboard usage
        2. 3 Quick Tasks to Get Familiar with Screen Readers (VoiceOver on Mac)
        3. Accessibility testing as a screen reader user
        4. Learn NVDA: Using the Internet, Part 1
        5. The effect of CSS on screen readers
  9. Review colours used
    1. For icons / UI components with no text, must have minimum 3:1 contrast ratio
    2. For text must have minimum 4.5:1 contrast ratio
    3. For AAA level aim for 7:1 or higher.
    4. Check focus / hover states comply with 2.4.11
    5. If links are not underlined check use the webaim link checker to check contrast meets accessibility guidelines.
    6. Use button buddy to check button and similar UI
    7. University brand colours and their accessibility are set out in the colour accessibility matrix.
    8. How to deal with text over graphics or gradients.
    9. Evaluating Color and Contrast-How hard can it be? This is an important article that will demonstrate how many aspects of testing for colour contrast could be missed.
    10. The above helps to cover:
      1. 1.4.11 Non-text Contrast (Level AA)
      2. 1.4.3 Contrast (Minimum) (Level AA)
      3. 1.4.6 Contrast (Enhanced) (Level AAA)
      4. 2.4.11 Focus Appearance (Minimum)
      5. 2.4.12 Focus Appearance (Enhanced)
  10. Turn on the OS "prefers reduced motion" flag and check there are no animations, flashes, or auto playing videos.
    1. 3.3 Animation from Interactions
  11. Use some further quick tools:
    1. Use 44x44 Pixel Cursor Bookmarklet to confirm that target size for interactive interface objects like icons, buttons, and links meet the 44x44px minimum. Note that this does not mean the size of the icon itself, it's the size including the icon and any space around it before the next icon is reached.
      1. 2.5.5: Target Size
      2. 2.5.8: Pointer Target Spacing
    2. Use headingsMap browser extension to verify heading structure is both in the correct order and not missing headings.
      1. 2.4.6: Headings and Labels
    3. Web Disability Simulator to test how the page performs for those with visual impairments and Specific Learning Differences.
  12. Identify any content that moves, blinks, scrolls, or auto-updates.
    1. If moving, flashing, or blinking starts automatically, confirm that it last no more than five seconds. If it does confirm that there is a mechanism to pause, stop, or hide this movement.
    2. If content auto-updates, confirm that there is a mechanism to pause, stop, or hide the auto-updates.
    3. If content flashes or blinks, confirm that this does not occur more than three times in one second.
      1. 2.2.2: Pause, Stop, Hide
      2. 2.3.1 Three Flashes or Below Threshold
  13. Check for media content.
    1. Confirm that media content can be fully controlled with a keyboard, not only with a mouse. It is particularly vital that content does not start automatically
    2. If any audio (background noise or video) does start automatically then it should stop after 3 seconds or include controls to pause or stop or turn down the audio.
    3. Confirm that captions are available for pre-recorded and they are accurate and in-sync with the content.
    4. An alternative for the media should be included such as a transcripts or audio descriptions are available these should be accurate, unless the media is an alternative to existing textual content.
      1. 1.2.2 Captions (Prerecorded)
      2. 1.2.3 Audio Description or Media Alternative (Prerecorded)
      3. 2.2.2: Pause, Stop, Hide
  14. Run a more detailed test using the assessment tool in the Microsoft accessibility insights browser plugin.
Back to top.

More about screen reader issues

Back to top.

Testing with screen reader

Note: Accessibility tests could result in a site that passes with flying colours, but only testing with users who have impairments will prove if it is a good experience.

Beginner guides to accessibility testing and development

Back to top.

More detailed Accessibility Testing guides / plans

Back to top.

Browser Extensions to assist testing

Back to top.

Bookmarklets to assist testing

Back to top.

Commandline tools

Back to top.

Continuous integration

Back to top.

Build

Frontend development

Back to top.

Semantic HTML

Back to top.

GitHub

Back to top.

Linters

Back to top.

React / JS

Back to top.

Angular

Back to top.

For Visual Studio Code

Back to top.

Atom

Back to top.

Javascript frameworks

Back to top.

Bootstrap

Back to top.

Integration with testing frameworks

Back to top.

Cypress

Back to top.

Selenium

Back to top.

Jasmine / QUnit

Back to top.

Design

Back to top.

Mobile

Back to top.

Requirements

Release

Definition of Done

Dashboards

Back to top.

Legislation

Getting buy-in

Back to top.

Pathways to implementing accessibility

Back to top.

Training

Back to top.

Books

Back to top.

Communities and mailing lists

Back to top.

Learn more

Back to top.