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
>
> -----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&utm_campaign=sig-email&utm_content=webmail
> >
> Virus-free.
> www.avg.com
> <
> http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_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-patt
> > 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
> > > > > > > > > > > > > > > archives at http://webaim.org/discussion/archives
> > > > > > > > > >
> > > >
> > > >
> > > > --
> > > > 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&utm_campaign=sig-email&utm_content=webmail
> >
> Virus-free.
> www.avg.com
> <
> http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> <#m_8169591751787689673_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > at http://webaim.org/discussion/archives
> > > > > >