WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Steve Green
Date: Jan 26, 2021 7:13PM

I agree with your point about automatically disappearing content being a WCAG non-conformance. Even if you apply an ARIA live region, it only benefits screen reader users. Screen magnifier users are very likely to miss the content completely.

When you refer to design systems, do you mean JavaScript frameworks like Angular or things like https://design-system.service.gov.uk/? The latter is highly accessible, but not comprehensive (although they are always adding to it). However, every JavaScript framework that has ever existed has been plagued with serious accessibility issues. Also, most of the third-party plug-ins for them are even worse. Perhaps the reason your question did not get many responses is because it's far too broad. Almost everything is bad in every framework - it's easier to list the things that don't need to be fixed.

Frankly, I find it appalling that almost no "professional" developers (let alone development managers) seem to be aware of this. Accessibility has been part of their job description for 20 years, so how can they not know about it?

That said, I still take a very soft approach when explaining it to them, precisely to avoid the antagonism you mention. I don't tell them that they have to do anything - testers shouldn't do that. I just tell them the way things are and the consequences of the various options they have, which includes not changing anything. If they want a VPAT or an accessibility statement (which all UK public sector websites must now have), I tell them that it will have to include every single non-conformance they choose not to address. They are not keen to be publicly embarrassed like that, so I find that they almost always do what needs to be done.

Steve Green
Managing Director
Test Partners Ltd


-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Brooks Newton
Sent: 26 January 2021 20:09
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] WebAIM-Forum Digest, Vol 190, Issue 14

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
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> Brooks Newton
> Sent: Thursday, January 21, 2021 2:12 PM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] WebAIM-Forum Digest, Vol 190, Issue 14
>
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you recognize the sender
> and know the content is safe.
>
>
> Hi All,
>
> This post is related to my call for known accessibility hurdles in
> popular design systems. I haven't gotten any responses, so let me start.
>
> Here's a question for everyone: How do "sticky" interactive elements,
> such as a sticky button, or sticky headers/footers work for sighted
> keyboard users who browse without the aid of assistive technology (AT)?
>
> For what it's worth, the way I've seen sticky buttons featured in
> various design systems is where they are intended to be used as
> always-visible, quickly accessible mechanisms for users to activate
> important page controls. Sometimes sticky buttons are used to
> activate the primary function of the page. That's important stuff.
> And for a lot of users, having a sticky button always positioned in
> the same portion of the viewport works great! One reason content
> authors like sticky buttons is that they allow page designers to pile
> lots and lots of content into a single web page without making the
> primary button hard to discover and/or tedious to activate. I mean,
> sticky buttons are always right there on the screen for users to click or touch, aren't they?
>
> Well, sticky buttons work great with a mouse cursor or via touch.
> But, what happens when, for whatever reason, a user can't use a mouse
> or touch to press the sticky button? What if users have to interact
> with the page using a keyboard? Are keyboard users as close as a
> click, a touch, a Tab press away from the sticky button? The answer
> is no, not in the default implementations I've come across. Maybe you
> all have had better experiences. Tell me where I'm getting this wrong.
>
> Has anyone on this email list ever tried to Tab to a sticky button on
> a long page starting in the middle of the focus order? It's very frustrating.
> It's kind of like toying with a cat, except you are the cat. You start
> getting excited as you visually move keyboard focus through the Tab
> order of the page getting closer and closer to the sticky button
> that's, let's say, positioned at the bottom of the screen. Right when
> it looks like you are about to move focus to the sticky button, the
> button jumps down the screen as the page scrolls in the browser,
> putting the important button just out of keyboard focus reach. In
> most web page implementations, this frustrating experience continues
> until you, the keyboard user, reach the bottom of the page. And, the
> bottom of the page may be a long, long way away from where you start
> Tabbing. The way I've seen sticky buttons implemented most frequently
> is to insert the sticky button at the end of the DOM, after all of the
> other content on the visual page. So the button looks like it is
> always close by in the page focus order, when in actuality it is not close at all.
>
> Now, we could say that it is the content owner/author's duty to
> remediate the component by supplying a keyboard shortcut that would
> allow keyboard users to quickly move focus to and interact with the
> sticky button. But what keyboard shortcut should the page author use?
> She doesn't want to use a keyboard shortcut that is already reserved
> for the browser and/or assistive technology purposes. There are other
> issues page authors should think about when choosing keyboard
> shortcuts, such as the provisions in the WCAG 2.1 rule, SC 2.1.4
> Keyboard Shortcuts. This is getting tricky, needless to say. All of
> these considerations put a lot of pressure on each and every web site
> owner and author out in the wild to make substantive changes to a
> design system component they might have thought was already
> good-to-go, in terms of accessibility. What will the result be if we
> are all tasked with taking this on alone? Asking lone organizations
> to handle this task in isolation will likely yield a m ishmash of
> different implementations, different keyboard shortcuts - ultimately a
> nightmare for well-intentioned site owners/authors and their keyboard using customers who, frankly, deserve better.
>
> What do we do? Well, for one, we could adjust the current
> accessibility governance model by asking all parties to the user
> interaction to do their parts to make the content accessible. In
> other words, share that responsibility for making sticky buttons
> accessible to keyboard users with browser makers, AT makers, and standards organizations.
>
> Maybe browser manufacturers could get together with assistive
> technology manufacturers and choose one easily teachable keyboard
> shortcut so that all keyboard users will know exactly what shortcut to
> use to move focus to a sticky button, regardless of the site they are
> visiting. That would help wares manufacturers to not step on each
> others' toes, so to say, in picking reserved keyboard shortcuts.
> Standards organization(s) would have to work in conjunction with the
> wares manufacturers to create and adopt semantically meaningful HTML markup that would give user agents the "hook"
> they need to know specifically what content is sticky content on the page.
> This type of coordination would sure make life easier for content
> owners/authors, as well as keyboard users. This collaborative
> approach that emphasizes shared responsibilities would help in solving
> similar situations, like when keyboard focus is mostly hidden
> underneath a sticky header or sticky footer. Ever had that happen to
> you? I have. It's disorienting for keyboard users to only see a
> sliver of the visual focus indicator, if they can see it at all. If we
> had markup that would identify a sticky footer, the user agent would
> know how to render the page so that focused elements aren't hidden underneath author-defined sticky regions!
>
> How do we get the appropriate players to work together in a
> collaborative space where responsibilities are shared? That's hard to
> say. For some specific digital accessibility issues, keeping content
> owners/authors as the sole parties responsible for enabling digital access makes sense.
> That's the way the system is set up now. All of WCAG, for example, is
> on the site owner's/author's plate of responsibilities. But in my
> opinion, asking wares manufacturers and standards bodies to help out
> is the best approach to doing the organized heavy lifting required to
> make digital accessibility feasible for owners/authors to implement,
> and easy for users to understand and use.
>
> Sticky buttons and sticky regions are two examples that illustrate how
> working together in the spirit of shared responsibility makes the most
> sense to clear hurdles to access. There are many, many other
> accessibility scenarios where sharing responsibilities makes the best
> sense. I'm sure the readers of this post can help think of some and
> add to this conversation.
>
> Brooks Newton
>
>
>
> <
> http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&ut
> m_campaign=sig-email&utm_content=webmail
> >
> Virus-free.
> www.avg.com
> <
> http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&ut
> m_campaign=sig-email&utm_content=webmail
> >
> <#m_8169591751787689673_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Sun, Jan 17, 2021 at 5:01 PM sangi usha < <EMAIL REMOVED> > wrote:
>
> > Sure ,Hunt
> >
> > On Sun, Jan 17, 2021 at 4:03 AM
> > < <EMAIL REMOVED> >
> > wrote:
> >
> > > Send WebAIM-Forum mailing list submissions to
> > > <EMAIL REMOVED>
> > >
> > > To subscribe or unsubscribe via the World Wide Web, visit
> > > http://list.webaim.org/mailman/listinfo/webaim-forum
> > > or, via email, send a message with subject or body 'help' to
> > > <EMAIL REMOVED>
> > >
> > > You can reach the person managing the list at
> > > <EMAIL REMOVED>
> > >
> > > When replying, please edit your Subject line so it is more
> > > specific than "Re: Contents of WebAIM-Forum digest..."
> > > Today's Topics:
> > >
> > > 1. Re: Known accessibility hurdles with popular design systems
> > > (Brooks Newton)
> > >
> > >
> > >
> > > ---------- Forwarded message ----------
> > > From: Brooks Newton < <EMAIL REMOVED> >
> > > To: WebAIM Discussion List < <EMAIL REMOVED> >
> > > Cc:
> > > Bcc:
> > > Date: Fri, 15 Jan 2021 14:18:05 -0600
> > > Subject: Re: [WebAIM] Known accessibility hurdles with popular
> > > design systems Thanks for the link, Birkir. I've looked through
> > > some of those resources already, and will check out the others I
> > > haven't yet reviewed. Thank
> > you!
> > >
> > > I'm wondering if folks have found known accessibility issues in
> > > popular Design Systems, such as the ones listed in this 2019
> > > article
> > > "10 Best Design Systems for 2019 <
> > https://www.webdesignerdepot.com/2019/08/10-best-design-systems-for-
> > 20
> > 19/
> > > >
> > > ":
> > >
> > > - Material
> > > - Fluent
> > > - Shopify Polaris
> > > - Mailchimp
> > > - Atlassian
> > > - Apple
> > > - IBM Design Language
> > > - AirBnB
> > > - Uber
> > > - Lightning Design System
> > >
> > > I've worked with a number of production teams who automatically
> > > assume
> > that
> > > if it is a big name Design System and/or JS Framework, then it
> > > must
> > already
> > > be vetted and fully approved for accessible use by people with
> > > disabilities. Are there any accessibility specialists who are
> > > reading
> > this
> > > who have encountered the same assumptions on the part of their
> > > teammates who don't know much about accessibility? How do those
> > > assumptions match
> > up
> > > with the reality of your testing? Should this community work
> > > together to test what the out of the box design system and/or
> > > framework provides, in terms of WCAG compliance? What about
> > > providing comprehensive guidance to help unknowing but
> > > well-intended production teams get their brand name frameworks,
> > > pattern libraries and style guides remediated for accessibility?
> > > Should we consider other accessibility benchmarks that
> > may
> > > offer a more reliable measure of accessibility performance in fact
> > > versus in theory?
> > >
> > > It can be overwhelming, even frightening to take on the full brunt
> > > of the accessibility problems a site can have as a lone
> > > organization, or worse yet, as a lone accessibility specialist.
> > > In this forum and via other accessibility venues, I hear a lot of
> > > talk about in the weeds
> > accessibility
> > > issues that content authors are required to take on themselves in
> > > isolation. But, I don't hear nearly as much talk about putting
> > > our minds together and trying to assess and fix known platform
> > > accessibility issues at a more centralized and efficient spot -
> > > such as at the Design System
> > or
> > > JS Framework level. Why is that?
> > >
> > > Believe you me, I've got many ideas along these lines that have
> > > sprung
> > from
> > > my frustration at bailing water out of the proverbial
> > > accessibility boat while taking on massive leaks from centralized
> > > sources that are frankly, beyond the scope of what individual
> > > content authors and site owners are best positioned to tackle. Who
> > > is in the best position to tackle accessibility problems at a centralized location?
> > >
> > > Brooks Newton
> > >
> > >
> > > On Fri, Jan 15, 2021 at 10:40 AM Birkir R. Gunnarsson <
> > > <EMAIL REMOVED> > wrote:
> > >
> > > > check out
> > > >
> > >
> > https://www.webaxe.org/web-accessible-code-library-design-systems-pa
> > tt
> > erns/
> > > > It's a place to start.
> > > >
> > > >
> > > > On 1/12/21, Brooks Newton < <EMAIL REMOVED> > wrote:
> > > > > Hello All,
> > > > >
> > > > > Similar to my previous post, I've got a question for everyone.
> > > > > Does
> > > > anyone
> > > > > know of a collection of known accessibility hurdles associated
> > > > > with
> > the
> > > > > most popular design systems in use today by web site
> > > > > production
> > teams?
> > > > If
> > > > > there isn't any one authoritative collection, then maybe folks
> > > > > on
> > this
> > > > > discussion list can supply their own observations from
> > > > > implementing
> > and
> > > > > testing design systems in their own work. The observed
> > > > > hurdles can
> > be
> > > > > WCAG-related or outside of the formal WCAG umbrella.
> > > > >
> > > > > Wouldn't it be wonderful if site owners and content authors
> > > > > could
> > have
> > > a
> > > > > clear understanding of the baked-in accessibility problems
> > > > > they will inherit when they adopt a design system to support
> > > > > their
> > organization's
> > > > > needs?
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Brooks Newton
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > >
> > > >
> > > > --
> > > > Work hard. Have fun. Make history.
> > > > > > > > > > > > archives at http://webaim.org/discussion/archives
> > > > > > > >
> > >
> > > <
> > >
> > http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&
> > ut m_campaign=sig-email&utm_content=webmail
> > > >
> > > Virus-free.
> > > www.avg.com
> > > <
> > >
> > http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&
> > ut m_campaign=sig-email&utm_content=webmail
> > > >
> > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > >
> > > > > > > > > archives at http://webaim.org/discussion/archives
> > > > > >
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
> <
> http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&ut
> m_campaign=sig-email&utm_content=webmail
> >
> Virus-free.
> www.avg.com
> <
> http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&ut
> m_campaign=sig-email&utm_content=webmail
> >
> <#m_8169591751787689673_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >