Countdown element accessibility

Beta
#1

Current the countdown html has no aria attributes to tell screenreaders what to do. Personally, I’d just set aria-live to off on the whole thing, but other users may want certain numbers read out. (just not the seconds, for the love of god).

This can obviously be done with custom JS, but most users dont have that skill level.

ADA compliance is essentially mandatory for all USA based business websites these days, so going the extra mile to make Pro ADA compliant would be a big plus.

#2

Hey @michaelbourne,

Thanks for writing in! I can certainly understand the need for this. I’m more familiar with using various aria roles on interactive elements like toggles, modals, dropdowns and the like, but I’m not as familiar with aria-live. From looking at MDN on this, it seems there are a few options:

  • aria-live="off" (as you mentioned)
  • aria-live="polite"
  • aria-live="assertive"

From what I’m reading, it seems that if we set aria-live="polite" on the timer itself and don’t set aria-atomic="true",
that should keep it from reading off every second change, and I believe it would be every minute. Do you happen to know of any live countdown libraries that are implementing this well that I could take a look at? I Googled around for a bit, but wasn’t finding much other than a few incomplete examples.

#3

Also, would you prefer to have some type of option to toggle between aria-live="off" and aria-live="polite"?

#4

Hey @kory!

I thought about it a bit, and I think the toggle between off and polite would work best, but I would have the Theme be sure the seconds weren’t included in polite. That would cover most use case scenarios, and people can use JS if they really need seconds.

With atomic, that dictates whether the changed value is read out, or the whole text. I think whole text would make more sense.

Thinking about it, I think role="timer" aria-live="polite" aria-atomic="true" would work best, with an additional aria-hidden="true" on seconds.

I’m unaware of any good live examples. It may take some trial and error with a screenreader yourself to determine what makes the most sense.

WCAG can be a bit of a pain, since there’s no good standard for all these edge cases…

#5

Thanks for the additional info Michael! We’ll post an update here once we’ve had a chance to rework some of this.

#6

@michaelbourne,

I’ve just come back from vacation, so this is my first chance to dive back into things today. I’ve been researching this a bit and testing things out with macOS’ built-in screen reader, and have some findings as well as some options we can choose from that I was hoping to get a little more insight from you.

We can’t use the direct output for the countdown itself in the ARIA text since we wrap every digit in a <span> tag. This forces the screen reader to read each digit individually, rather than as a group (i.e. “1, 8 days” instead of “18 days”). Because of this, I’ve come to the conclusion that the best way to implement this is to output a secondary hidden <span> that will include a pure string to be read properly.

As for that separate element and the string included, there are a few ways we can handle it:

  1. (Most Simple) — Have a checkbox in the builder to turn enable “ARIA support,” which simply outputs the hidden string. The string would be localized and only editable that way. It would be something like “Countdown ends in: ${{format}}” where ${{format}} is always replaced with the current time in DD:HH:MM format. From my testing, the screenreader doesn’t read out “5 days, 18 hours…”, but instead just says the numbers. A couple examples I found seemed to use this format only, so I’m guessing it works as a convention in that space, and with the contextual copy beforehand, it helps to convey the meaning. This is the easiest solution and gives people the ability to turn it on and off for accessibility, but the ARIA string is not immediately editable unless you want to do it via localization. Changing the “Countdown ends in:” part of that string via localization would always be a global edit for the site, so you wouldn’t be able to make this contextual such as “Webinar starts in: ${{format}}” on one page and “${{format}} until lunch” on another page.
  2. (More Control) — The next option would be having a checkbox to enable “ARIA support,” which would also reveal an input with something like “Countdown ends in: ${{format}}” inside the input. This would allow you to edit the ARIA text of each Countdown Element on your site and make them more contextual as you need for different scenarios. In this iteration, the date format would always be output as DD:HH:MM.
  3. (Even More Control) — The final option would be similar to the 2nd, but enabling the checkbox would reveal an input with something like “Countdown ends in ${{d}}, ${{h}}, and ${{m}}.” This effectively allows you to format the ARIA string exactly as you want, omitting certain intervals that you don’t always need (such as seconds), and it would also allow you make it slightly more human readable with situations like “…DD, HH, and MM…” and the like. The one downside to this technique is that we wouldn’t be able to dynamically remove empty parts of the string, so at some point it might say something like “Countdown ends in 0 days, 0 hours, and 32 minutes,” which I think is fine considering the improved readability (and the fact that it wouldn’t be firing every second), but it’s just something to consider.

What are your thoughts on these scenarios? Do you just want the dead-simple option to turn things on like Scenario #1, or do you like the added flexibility of Scenario #2 or Scenario #3? Let me know your thoughts when you have a chance.

#7

Hey Kory,

I think #2 works best for accessibility, but #3 would be a great selling point to designers, since many countdowns will be for something more specific than a “countdown”, like a buy now CTA etc.

If #3 is doable for this release, I’d vote for it.

#8

Thanks for letting us know! I know Kory’s working on the Testimonial changes now, and will be circling back to make these adjustments.