Blog

WCAG Success Criteria for Non-Visual Navigation using Screen Readers

non-visual-navigation-testing

Table of Contents

SUMMARY

When testing with your screen reader, use the same keyboard navigation strategies that you used in the previous section (TAB, ENTER, SPACE, and ARROW KEYS). This time, listen to how  the  screen  reader interprets the page as you navigate with the keyboard.

WCAG SUCCESS CRITERIA & CHECKLIST FOR KEYBOARD USERS

LAYOUT TABLES

Layout tables are not recommended for accessibility. CSS should be used rather than tables to layout information.

  • ☐ N/A (There are no layout tables)
  • Tables are not used purely for positioning content
    ☐ Yes ☐ No
  • If tables are used for layout, they do not have designated header rows
    ☐ Yes ☐ No
  • If tables are used for layout, the reading order of the cells makes sense when linearized
    ☐ Yes ☐ No
  • If tables are used for layout, they allow end user customization and text scaling
    ☐ Yes ☐ No
  • Tables are not nested or filled with spanned or ‘spacer’ cells
    ☐ Yes ☐ No
  • When the user is in a specific cell in a table, the screen reader should tell row name & column name
    ☐ Yes ☐ No

DATA TABLES

  • ☐ N/A (There are no data tables)
  • Data tables have designated header and/or column rows
    ☐ Yes ☐ No
  • Tables have captions (short text descriptions)
    ☐ Yes ☐ No
  • Tables are not nested or filled with spanned or ‘spacer’ cells
    ☐ Yes ☐ No
  • Row or column headers are associated with the appropriate Scope attribute
    ☐ Yes ☐ No

FRAMES        

  • ☐ N/A (There are no frames)

If Frames are found (not recommended for accessibility):

  • Each frame has a descriptive title attribute value
    ☐ Yes ☐ No
  • When you refresh a page, it stays on the current frame
    ☐ Yes ☐ No
  • While listening with screen reader, you can navigate between frames
    ☐ Yes ☐ No
  • While listening with screen reader, you can tell what the purpose of each frame is
    ☐ Yes ☐ No

CAPTCHA      

If CAPTCHA is used, it must be fully accessible and simple to use.

  • ☐ N/A (There is no CAPTCHA)
  • CAPTCHA is fully accessible by keyboard
    ☐ Yes ☐ No
  • CAPTCHA is fully accessible to screen reading software
    ☐ Yes ☐ No
  • Audio CAPTCHA is fully accessible by screen readers, including a pause that allows the screen reader to finish before the audio begins
    ☐ Yes ☐ No
  • Audio CAPTCHA has an alternative for users with hearing impairments
    ☐ Yes ☐ No

SCREEN READERS-LIST OF TOOLS:

NVDA KEYBOARD SHORTCUTS:

  • Navigate Headings → H ; SHIFT+H
  • Navigate interactive elements → Tab and SHIFT+Tab ; Spacebar ; Enter ; Arrow keys
  • Read content → Caps Lock OR Insert + Down arrow
  • Elements list → Caps Lock OR Insert + F7
  • Control key → Stop reading temporarily

For screen reader usage shortcuts, visit

WINDOWS OS

https://dequeuniversity.com/screenreaders/narrator-keyboard-shortcuts

https://dequeuniversity.com/screenreaders/nvda-keyboard-shortcuts

https://dequeuniversity.com/screenreaders/jaws-keyboard-shortcuts

https://dequeuniversity.com/screenreaders/jaws-word

MAC OS

https://dequeuniversity.com/screenreaders/voiceover-keyboard-shortcuts

https://dequeuniversity.com/mac/keyboard-access-mac

https://dequeuniversity.com/mac/windows-screen-readers

MOBILE

https://dequeuniversity.com/screenreaders/talkback-shortcuts

https://dequeuniversity.com/screenreaders/voiceover-ios-shortcuts

Document these issues when screen reader testing:

  • Focusable elements isn’t announced correctly
  • Dynamic content isn’t announced correctly
  • Form instructions and error feedback aren’t announced correctly
  • Custom widgets are not navigable and not announced correctly. Custom widgets often require ARIA to be accessible. Checking with a screen reader makes sure everything is working properly.