WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Brooks Newton
Date: Jan 21, 2021 12:11PM

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 mishmash 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-2019/
> > >
> > ":
> >
> > - 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-patterns/
> > > 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.
> > > > > > > > > > > > > > >
> >
> > <
> >
> 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
> > >
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
> > > > > > > > > >
> > > > >

<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>