Websites designed and built with the core concepts of web accessibility ensure that your website can be accessed, understood, and used by as many people as possible.  This includes members of diverse communities, like those with visual, auditory, mobility/dexterity, and cognitive disabilities.

So, how can you tell if your site is accessible? Well, the truest way to gauge your website’s performance is with a combination of real-world user testing, thorough auditing, and a detailed understanding of WCAG 2.0 guidelines. But until that point is reached, we’ve compiled a handful of step-by-step tests to help you conduct a manual assessment on the fly.

  • Keyboard only operation
  • Activate Assistive Tech
  • Visual Testing with a screen reader
    • Using JAWS on a webpage in Chrome, IE11
  • Image Testing
  • Font and background color testing
  • Enlarging Text
  • CSS Testing
  • Visual Aria Testing
  • Automated Testing
  • Next stesps

Keyboard only operation

  • Check focus (tab) order
  • check visual indication of keyboard focus (make more visual)
  • any keyboard traps?
  • does any hidden content get focus?
  • does anything which is mous-operable not get keyboard focus?
  • are there any custom controls or widgets which cannot be operated with keyboard-only use?

Activate Assistive Tech

  • activate the AT you are testing with before opening the program or browser
  • Open the program or the browser and website you are testing
    • Chrome, IE11/JAWS
    • NVDA/Firefox (pre quantum updates)
    • VoiceOver/Safari
  • Use the AT to access the feature or page to be tested
    • try not to use the mouse – no errors, but bad testing habits

Visual Testing with a screen reader

Using JAWS on a webpage in Chrome and IE11

  • use down arrow key to read through the page
    • order matches visual order
    • anything skipped
    • anything read which isn’t visible
  • Use tab key and shift-tab to read through the page
    • only controls receive focus
    • anything skipped
    • can every link button and custom control be operated
    • does the announced role match the result
      • does a link go somewhere or does it open a dialog
  • Shortcuts
    • Insert-F6 to see struct of headings
    • Insert-F7 to see a list of links (check for meaning in context or in list)
    • ‘L’ key to see order of lists
    • ‘F’ key to see order from form fields (Insert-F5)
    • ‘T’ key to see order of tables

Image Testing

  • Inspect all images for “alt” attributes
    • if no alt, usually will read file name
  • which images are purely decorative
  • remove colors (IE a11y tools) – is the message being indicated by color alone? (red for error)
    • determine if color is an indicator
    • both colorblind and screenreader
  • looking at the page is info indicated with styling (bold italic shading etc)

Font and background color testing

  • change text and background colors in browser, is everything that is informative still visible?
    • test high contrast modes
  • Exit responsive design view, reduce size to default and activate color contrast checker (level access tool)

Enlarging Text

  • Increase size to 200% open responsive design view (ctrl-shift-m in firefox), and sclae down to 1366×768 (most common screen size)
  • Does text wrap properly
  • wcag requires up to 200% ******
  • is any feature lost / hidden?
  • does text blur as it’s larger? – possibly yes bc it’s an image and not actual text

CSS Testing

Testing the Information provided and the CSS relationship
  • Remove CSS
    • in firefox go to view > page style > no style to remove css
    • view dom order on screen

Visual Aria Testing

  • If the product uses ARIA
    • Use the visual ARIA bookmarklet
  • Tab through all custom widgets, open menus, etc
  • Example Normal view vs Example ARIA bookmarklet view

Automated Testing

  • run automated web accessibility tests, using one of the number of different tools
  • cross-references those results with the ones from manual testing
  • remove duplication and check for false positives