Steve Sawczyn, former Solutions Architect at Deque Systems, demonstrates how he uses a screen reader to navigate the web. In celebration of Global Accessibility Awareness Day (GAAD), Steve provides developers, designers, business users or anyone new to digital accessibility a first-hand experience of how people who are visually impaired navigate the web.
In this recorded webinar you will:
- Experience a screen reader simulation first-hand
- Understand how a screen reader navigates a web page
- Hear how a screen reader announces the content on a page
- Discover common design barriers that trap or make the web inaccessible to persons using assistive technologies
- Learn an introduction to accessibility testing with screen readers
- Hear some excellent Q&A
We figured the disclosure widget pattern was the appropriate choice for the navigation. Basically, you have a
<button>which controls the visibility of an adjacent container. The toggle contains visually hidden text to mention what it's for, since its only visible content is the brand logo.
Then I thought about using
As much as I love
<summary>, they're also not perfect for a navigation, because clicking elsewhere or tabbing out of it does not close it.
aria-expanded) and a
aria-labelledby), so we can have more control over the behaviour—particularly when to close the menu. [...] Interesting point raised by Aurélien Levy on Twitter: When using
aria-expanded="true", the label should not mention "open" or "close" (or similar) as the state is already conveyed via the attribute.
Because landmarks such as
<nav>can be listed by assistive technologies, it's important that the
<nav>itself is not the element whose visibility is being toggled. Otherwise, it's undiscoverable when hidden, which is not good. Instead, the
<nav>should be the surrounding container, always visible, and contains the button to toggle a list's visibility.