Web Accessibility Testing: Screen Readers Flashcards
When testing your code what should you look for?
- Elements should have complete start and end tags
- Elements should be nested according to their specifications
- Elements should not contain duplicate attributes
- Any IDs should be unique, except where the specifications allow these features.
What should you include in development test routine?
- Keyboard testing. Do all the functionalities work with just a keyboard only?
- Automated accessibility checks in the browser
- Zoom in and out with your browser.
What are some additional steps that can be taken when doing accessibility testing?
- Check the navigation and information order with a screen reader
- Try focusing and try activating links and buttons with voice recognition software
- Consider using automated checks before a commit, using a linter.
When doing keyboard testing what should you test for?
- Is the first tab a skip link to the main content, and does that work?
- Is the tab order sequential, logical, and as expected?
- Can you see where you are while tabbing through the website? Is there a clear visual change when you focus on a link, button or input?
- The menu: can you access the menu items, can you open a hamburger menu, tab around and close it again?
- Can you operate radio buttons, checkboxes, and dropdown selects in a form?
- Can you operate the next and previous buttons in a carousel?
- Can you open and close items in an accordion?
What keyboard testing should be done for a modal?
- If a modal opens, can you access links on it? Does the modal get keyboard focus, or does the focus stay on the page itself?
- Can you access the close button (often an X) and close the modal?
- Can you close the modal with the Escape key?
What are some automated testing tools?
WAVE, AXE, HTML_CodeSniffer, Lighthouse
https://www.w3.org/WAI/test-evaluate/tools/list/
What tests do you need to perform for zooming?
- The first one: open your site Chrome and set your window to a width of 1280 pixels and zoom in up to 400%.
- The second test is to zoom in for only text. Open your site in FireFox, set zoom to text only and zoom in up to 200%. Can you read the text and use the functionality?
What should you test for when you are doing screen reading testing?
- Check the content story: does it make sense reading from the top down?
- Check the headings list: does it represent the content and is all related content below the heading in the DOM?
- Check the link list: do links texts make sense?
- Check whether dynamic changes are announced.
Yes! Your frontend code is parsing. This means:
A. The syntax of the frontend code is error-free
B. The frontend code is fully accessible
A. The syntax of the frontend code is error-free
IDs of form controls should be unique on a web page.
A. True
B. False
A. True
The steps required for accessibility testing are:
A. Keyboard testing
B. Automated accessibility checks in the browser
C. Zooming in and out in your browser
D. All of the above
D. All of the above
When opening a modal (pop-up), the keyboard focus can be put on …
Check all that apply.
A. The close button
B. The first input field
C. The button for opening the modal
D. The top of the page
B. The first input field
What can you check with a screen reader?
Check all that apply.
A. Whether the spelling of my content is correct
B. Whether link texts make sense
C. Visual focus styles
D. Whether everything is understandable if you read from the top down
E. Feedback on dynamic changes
A. Whether the spelling of my content is correct
D. Whether everything is understandable if you read from the top down
E. Feedback on dynamic changes
What can you test with voice recognition software on a web page?
A. Whether links and buttons are focusable
B. Whether I can ask questions with my voice and get answers from the software
A. Whether links and buttons are focusable
With automated test tools I can find all accessibility issues on a web page.
A. True
B. False
B. False
What information does an accessibility API convey to screenreaders?
The operating system has an accessibility API which conveys information about the names, roles, values, and structure of web content, plus events that should be announced to users.
Who uses screen readers?
- Blind
Blind users typically listen to the audio output of screen readers. - Deafblind
People who have both visual and auditory disabilities may use a screen reader with a refreshable braille output device, to allow them to feel the braille characters with their fingers. - Low vision
People with low vision typically use screen magnification software to make it easier to read. For some people, the magnification is not enough, so they supplement the magnification with a screen reader. This allows them to both see and hear the web content. - Reading disabilities
People with reading disabilities may find it easier to listen to content read out loud to them, rather than read it with their eyes. - Cognitive disabilities
People with various kinds of cognitive disabilities may also find it easier to understand spoken words rather than written words. - Eyes-free or hands-free environments
People with or without disabilities may use screen readers when reading things in eyes-free or hands-free environments.
Why do you also need test with screen readers? What will automated testing tools
- Quality and accuracy: Inaccurate or poor-quality alt text is no better than missing alt text. Automated tools can only tell you whether an image has alt text. They cannot tell you whether the alt text is accurate or meaningful. The same is true of text labels for form elements, captions on tables, headers on data tables, and so on.
- Keyboard focus patterns: Automated tools cannot reliably determine where the keyboard focus should be at any given point in time. When a user clicks on a button, the focus should go to a logical destination — such as a dialog or error message — but it is impossible for an automated tool to know what the appropriate focus location is.
- Custom widgets: With custom widgets, like dialogs, carousels, and accordion menus, there is no way for an automated tool to detect all the possible ways of creating them incorrectly, especially when it comes to keyboard interaction patterns. At best, an automated tool might be able to identify when a widget is created correctly, by comparing the names, roles, values, and keyboard focus patterns of the widget with the ARIA 1.1 authoring practices opens in a new window[note] document. Even that is tricky.
What are the most common screen readers and browser pairs?
Desktop screen readers:
- JAWS with Chrome
- NVDA with Firefox
- NVDA with Chrome
- JAWS with IE
- VoiceOver with Safari (macOS)
- Narrator with Edge
Mobile screen readers:
- VoiceOver with Safari (iOS)
- TalkBack with Chrome (Android)
True or False: You can customize web content to screen reader users by detecting which screen reader they’re using.
False:
Which phone is currently the most popular among blind users?
A. Windows Phone
B. iPhone
C. Android Phone
D. Blackberry Phone
B. iPhone
True or False: Screen readers can output to either audio or Braille.
True
Which screen readers are available for Windows? (Select all that apply)
A. JAWS
B. VoiceOver
C. TalkBack
D. NVDA
E. Window-Eyes
F. C and D
G. A, D, and E
G. JAWs, NVDA, and WIndow-eyes
True or False: Testing with screen readers is recommended, but is not required, if automated accessibility tests are performed prior to launching web content.
False