WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Jonathan Avila
Date: Jan 22, 2021 1:52PM

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>