Day 48: Accessible Single Page Applications

Still looking over the WAS Body of Knowledge section about creating accessible single-page applications (SPAs), I took my research a step further beyond the items they listed (aria-live and focus management), and started exploring on my own about what else I needed to pay attention to when it came to making SPAs accessible.

Things I accomplished


What I learned today

  • SPAs are not exempt from best practices used on static webpages or full applications. Document structure, native elements, and keyboard navigability are key to creating accessible SPAs.
  • The page title should change with each new view.
  • tabindex=”-1″ lets scripts bring focus to an element, but not let a user tab to it.

Day 47: ARIA Live Regions, Part 2

Yesterday during my Part 1 learning, I watched videos that gave me a great idea of how live regions worked. Today I looked over documentation to see what W3C had to say about it.

Things I accomplished

Read the WAI-ARIA documented parts on:

What I learned today

  • The politeness value of aria-live is just a strong suggestion to user agents and AT, but may be overridden by user agents, AT, or the user.
  • Some ARIA roles (i.e. log, status) already have default aria-live politeness levels (implicit value for role) when aria-live is not set.
  • aria-relevant indicates what notifications the user agent will trigger when the accessibility tree within a live region is modified.
  • aria-relevant values include:
    • additions
    • additions text
    • all
    • removals
    • text
  • aria-busy is a state, not a property.
  • aria-busy exists to indicate an element is being modified and that AT may want to wait until the modifications are complete before showing them to the user.

Day 46: ARIA Live Regions, Part 1

Today I started digging into ARIA live regions to better understand how they can be useful in making SPAs (single-page applications) more accessible to screen reader users. This is a topic that will take some research because I’m not familiar with using most of those attributes. YouTube was a great place for me to start because I knew I’d find a few examples of how they work along with helpful screen reader demos.

Things I accomplished


Tried the ARIA Live Region Test (by Terrill Thompson) with VoiceOver on Safari.

What I learned today

  • The aria-live attribute is useful to update a screen reader user about changing content. It only reads the changed content.
  • The aria-atomic attribute can be set as true on the same element as the aria-live element in order to read the entire contents within that element, in order to give context.
  • aria-live possible values:
    • off (default)
    • polite (waits for user to finish what they’re doing)
    • assertive (interrupts user)
  • Other ARIA live regions include aria-busy and aria-relevant.

So much to learn, so little time! I’ll be spending more time on the topic and intricacies of live regions tomorrow, as well. As always, I am ever so grateful for those who have taken time to experiment and share their screen reader test findings with the rest of us.