Skip to content

Accessibility: screen reader introduction, and accessible <nav>s

  • 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.

    For when JavaScript is not available, we originally intended to have an anchor link sending to the footer, since most if not all pages are linked from there as well.

    Then I thought about using <details> and <summary> since we have pretty loose browser support expectations. It gives us a disclosure widget without needing any JavaScript, which is pretty great. We just had to tweak the styles a little to hide the default arrow and make it a bit more integrated. [...]

  • As much as I love <details> and <summary>, they're also not perfect for a navigation, because clicking elsewhere or tabbing out of it does not close it.

    That's why when JavaScript is available, we replace them with a <button> (with aria-controls and aria-expanded) and a <div> with (aria-hidden and 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.