WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WebAIM-Forum Digest, Vol 190, Issue 14

for

From: Brooks Newton
Date: Jan 26, 2021 1:09PM

Great points, Jonathan. Are any of those extra instructions intended to
mitigate accessibility hurdles associated with sticky floating content
included in design system instructions? Any way for organizations who use
design system components to know that there's more accessibility work to do
than just using an out-of-the-box solution? That question is for anyone
who's reading this.

When production staff adopt a big name design system, I believe that many
assume all is ready to go, in terms of accessibility. I think we've
established that out-of-the-box accessibility is an arguable point for some
design system component types. NOTE: As an accessibility specialist, it is
very demoralizing to have to convince unknowing production staff and
managers that there are often significant remediation steps necessary to
bring big name design system components into compliance with WCAG, for
example. It sets up an antagonistic dynamic and makes it even harder for
us to do a very difficult job.

Here's another known accessibility issue (in my opinion), which I've found
in multiple big name design systems: automatically disappearing content.

In particular, I'm talking about notifications that appear on the screen
and disappear after a set period of time without a user actively dismissing
the content. I'm talking about things like snackbars, toasts, etc. that
don't give users the ability to turn off the message duration time limit,
or don't give users the ability to prolong the length of time the message
remains on the screen.

Again, tell me where I'm wrong here, but in my honest opinion I can't see
how this type of out-of-the-box component passes WCAG 2.0/2.1 SC 2.2.1
Timing Adjustable Level A. Maybe it is OK if you provide a personalization
option for not automatically dismissing content as part of the site's user
settings? But, that's not part of any out-of-the-box component I've seen.
And, I think the default setting in this scenario should be to make
messaging persistent unless a user actively chooses to make messaging
temporary. Let me know if anyone has an easy solution for this fundamental
accessibility problem. SC 2.2.1 is one of a limited number of success
criteria that seek to make content accessible to people with cognitive
disabilities, as well as other disabilities that make it hard for people to
read and/or interact with content given an arbitrary time limit.

Think about how critical it can be to have a message remain on the screen
to read in these unsettled times. Nerves are frazzled, stress is high,
attention is hard to focus. Maybe an organization decides to use a design
system to stand up an online COVID-19 vaccination portal quickly. Maybe
the page authors use a component with automatically disappearing content
that informs users that "Your scheduled vaccination appointment was not
reserved - try again in 30 seconds." What if a user with a disability
isn't able to read that automatically disappearing content quickly enough
and thinks that everything is all set for the appointment time they think
they have booked? Too bad, I guess. We can and should do better than that.

If you add a close button to a pop-up announcement that floats on a
different layer above the main page content, we've at least given the user
control over when to dismiss the announcement. But, in the process of
making the pop-up announcement remain on the screen until actively
dismissed, we've introduced the same types of keyboard issues I spoke about
in my previous post about sticky floating buttons. This brings me back to
my call for new HTML markup that content authors can use to designate
floating/sticky content, so that user agents and assistive technology have
the "hook" they need to give users immediate access to the content and
associated close button. It won't work for a standards body to create the
markup, add it to guidelines and hope that it is adopted by wares makers
and content authors alike. The effort must be collaborative and
coordinated.

Digital accessibility is difficult to understand, and even harder to design
and code into practice. In my opinion, it is harder than it has to be
because we have pushed the fixes required to remediate digital content down
the line to individual organizations and production line contributors.
Instead, we should try to address these key global issues further up the
chain where standards bodies and wares makers can have the greatest impact
for the greatest number of users. Anyone else have thoughts on this?
Again, let me know where I've gotten this wrong. Anyone have additional
known design system accessibility hurdles they like to discuss?

Brooks Newton





On Fri, Jan 22, 2021 at 2:52 PM Jonathan Avila < <EMAIL REMOVED> >
wrote:

> There are a few options in addition to using a keyboard shortcut. The
> functionality should likely also be available elsewhere on the page - such
> as at the top of the page. The sticky control might also be best as the
> last control on the page allowing the user to move to the address bar and
> then shift+tab to reach it. Other options include some sort of keyboard
> link at the top of the page that would expose hot keys and/or allow you to
> jump to the sticky control much like a skip link. On mobile sticky
> controls are often the default control of the app and some assistive
> technology has keystrokes to perform a default action.
>
> Really what we need is a way to access a list of page level actions from
> anywhere in the browser. That is a page could expose page level actions
> through an API that the user could access in the way that works best for
> them. The same thing could be implemented similar to how the adjustable
> rotor works for a specific control with multiple actions on iOS or Android.
>
> Jonathan
>
>