WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Meaningful Sequende Question

for

From: Brooks Newton
Date: Dec 7, 2022 1:30PM


Hey Jeremy (or anyone else who wants to jump into the discussion),

So if ARIA markup was originally intended for AT alone to parse, but some
of the AT role has now been moved to browsers - how does that work in the
case of modal content? I got word on the WAI interest group list that
Assistive Technology (AT) companies are relying upon browsers for at least
some of the accessible code handling that previously was relegated to AT to
handle alone (accessible name calculation), or was that clarification made
in error?

From what I've been hearing recently on these experts lists, I thought
software manufacturers couldn't be forced to do anything they don't want to
do with regard to accessibility support. Is that your understanding? What
happens when folks aren't forced to do anything?

Here are some ideas. Tell me explicitly where I'm wrong and I'll do my best
to learn from your feedback:

- There's no active work going on with the User Agent Accessibility
Guidelines, is there? It's been 6 years since that work ceased. Why?
- There's no more SC 4.1.1. Parsing rule to have worry about in WCAG 2.2
that would point to a shared commitment between content authors, users and
software manufacturers.
- There's all of those pesky "exceptions" in WCAG that excuse known
inaccessible behaviors on the part of browsers, including:
- Disabled controls that fail color contrast requirements that
support access to users with low vision and/or color blindness.
- There's the placeholder attribute, that when implemented according
the default specification creates an inaccessible temporary visual label.
- The exception in WCAG that makes it OK to have low-contrast focus
indicators if it's the browser default styling.
- There's the new WCAG 2.2 rule SC 2.4.13 Focus Not Obscurred that gives
a "pass" for content where only a single pixel of what has focus scrolls
into a view (a shared weakness of a lack of proper markup and appropriate
rendering by user agents).
- There's the same old problem of browsers displaying title text on
mouse hover but not on keyboard focus.
- There's a WCAG 2.x SC 4.1.2 which allows critical accessibility
information to remain "under the hood" and not presented in any mode by the
browser to users with disabilities who don't use AT.

There are a lot more examples that I'm not going to list here. How'd those
exceptions get into the WCAG standard? I served on the WCAG working group
for 4 years and not once did I hear a disability advocate/expert advise the
group to provide exceptions for browsers. Don't get me wrong, I don't work
for the W3C and never have - so I'm not carrying water for them, I'm just
saying I don't have to guess about this point. I know from experience that
exceptions to WCAG don't support user access - they mostly shield software
manufacturers from having to innovate. Am I allowed to have that opinion?

It's all voluntary, right - terms of what browser manufacturers do or don't
do to support access to digital content? At least that's what I've been
hearing on the WAI interest group email list over the past month or so.
Except it's not voluntary for content owners to do whatever they want to
support access in countries, states, provinces, etc. that have adopted WCAG
as part of their laws, right?

Do software manufacturers have actively evolving obligations for supporting
accessibility that have been put forth by the W3C or any other trade
association or advocacy group recently? The User Agent Accessibility
Guidelines (UAAG) have been defunct since 2016, if I'm not mistaken. Why is
it defunct? How about accessibility rules for Authoring Tools? How are
they evolving? Would an updated UAAG specification have assigned greater
responsibility to user agents for handling more of the "heavy lifting"
required by developers to make modal content accessible? That depends on
whether there would be equal representation from the constituents who
define the user experience: content authors, users, software manufacturers
and the standards making body itself.

Who's in charge? Who is overseeing how all of the active participants in
the user experience work together to build and maintain accessible digital
user experiences? Who's making it easier for content authors to deliver
accessible content, and who is doing all they can to remove every last
shred of codified culpability associated with not directly supporting
access to digital content?

It's all very confusing. Maybe you can help clear things up.

Brooks


On Wed, Dec 7, 2022 at 12:48 PM Jeremy Echols < <EMAIL REMOVED> > wrote:

> ARIA attributes were never meant to do work, that's just not why they
> exist. Browsers do indeed implement these things, as I mentioned: the
> "dialog" element was built to address this exact problem, and has wide
> support. ARIA attributes are simply the stopgap so developers are able to
> build things that browsers can't yet, or shouldn't (such as a custom widget
> that only makes sense on a single site).
>
> It's not a "not my problem" issue - it's what the w3c explicitly stated
> about ARIA to begin with. It may behoove you to read W3C's explanation of
> ARIA rather than cast the blame on browsers who are in fact following the
> spec precisely.
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> Brooks Newton
> Sent: Wednesday, December 7, 2022 10:44
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Meaningful Sequende Question
>
> Hi Jeremy,
>
> I appreciate your explanation of the role of ARIA markup. I guess that
> works out pretty well for browser manufacturers not having to change any of
> their wares' behavior based on its presence. How does that work for
> developers and users with disabilities? Seems to me like this "not my
> problem" approach puts it all back on content owners, who undoubtedly will
> interpret what the right thing to do is a number of ways, including many
> that don't support access.
>
> Why not make aria-modal into a full-fledged HTML attribute or element
> then? Why not handle something as fundamental as focus constraint in modal
> content at more centralized source (user agents) for the benefit of
> consistency and predictability? Can anyone provide a use case where a
> content author marks up a container as modal, but doesn't want focus to be
> constrained to that container, unless the user affirmative takes action to
> dismiss the modal? If you can think of a case like this, wouldn't that be
> the exception and not the rule?
>
> Brooks
>
> On Wed, Dec 7, 2022 at 12:36 PM Jeremy Echols < <EMAIL REMOVED> > wrote:
>
> > And bear in mind this is about how assistive technologies handle the
> > attribute, not the user agent. So if assistive tech imposes a limit
> > which the unmodified browser doesn't, things can get pretty hairy.
> >
> > -----Original Message-----
> > From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> > Jeremy Echols
> > Sent: Wednesday, December 7, 2022 10:34
> > To: WebAIM Discussion List < <EMAIL REMOVED> >
> > Subject: Re: [WebAIM] Meaningful Sequende Question
> >
> > Correct, because it's not up to the assistive technologies to decide
> > how the app should work. The devs need to ensure modals are built
> > right (preferably using the "dialog" element or a polyfill). Assistive
> > technologies can choose to limit navigation if they want, but that can
> > break sites where devs are incorrectly using aria attributes. Which,
> > unfortunately, is quite common.
> >
> > The correct pattern for a developer *implementing* a modal will not be
> > the same as the requirements of how assistive technologies handle the
> attribute.
> >
> > -----Original Message-----
> > From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> > Steve Green
> > Sent: Wednesday, December 7, 2022 10:29
> > To: WebAIM Discussion List < <EMAIL REMOVED> >
> > Subject: Re: [WebAIM] Meaningful Sequende Question
> >
> > MDN aren't the authoritative source, but I assume they have close ties
> > with the Chrome developers, so they should be better informed than most.
> >
> > The definitive source is
> > https://urldefense.com/v3/__https://www.w3.org/TR/wai-aria-1.2/*aria-m
> > odal__;Iw!!C5qS4YX3!GuMVNHSBkaEzbZLo8QJI70NOcXPxC99Q7gSHSdnKF-fzWP6r5b
> > TY3RZGxVLJGcCkiF88dM_unt4Lx6H3XN-Mnbjrinv5nw$
> > , which says "Assistive technologies MAY limit navigation to the modal
> > element's contents." It doesn't even say SHOULD, let alone MUST, so I
> > expect there is little chance that this will be implemented by enough
> > browsers that authors can rely on it.
> >
> > Steve
> >
> >
> > -----Original Message-----
> > From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> > Brooks Newton
> > Sent: 07 December 2022 17:50
> > To: WebAIM Discussion List < <EMAIL REMOVED> >
> > Subject: Re: [WebAIM] Meaningful Sequende Question
> >
> > Thanks for that, Steve. Seems like a missed opportunity to empower
> > user agents to take on some of the "heavy lifting" developers have to
> > do to make content accessible. Is MDN the authoritative source for
> > questions about how markup should work in user agents? Anyone from
> > MDN on this thread?
> >
> > Brooks
> >
> > On Wed, Dec 7, 2022 at 11:35 AM Steve Green <
> > <EMAIL REMOVED> >
> > wrote:
> >
> > > According to the MDN website, the aria-modal="true" attribute is not
> > > supposed to do that. They say "Setting aria-modal="true" on dialog
> > > and alertdialog role containers indicates the presence of a "modal"
> > > element to users of assistive technology, but does not actually make
> > > the element modal. The features that make the element actually modal
> > > must be implemented by the developer."
> > >
> > >
> > > https://urldefense.com/v3/__https://developer.mozilla.org/en-US/docs
> > > /W
> > > eb/Accessibility/ARIA/Attrib__;!!C5qS4YX3!GuMVNHSBkaEzbZLo8QJI70NOcX
> > > Px
> > > C99Q7gSHSdnKF-fzWP6r5bTY3RZGxVLJGcCkiF88dM_unt4Lx6H3XN-MnbgZZ2ybMA$
> > > utes/aria-modal
> > >
> > > Steve Green
> > > Managing Director
> > > Test Partners Ltd
> > >
> > >
> > > -----Original Message-----
> > > From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf
> > > Of Brooks Newton
> > > Sent: 07 December 2022 17:28
> > > To: WebAIM Discussion List < <EMAIL REMOVED> >
> > > Subject: Re: [WebAIM] Meaningful Sequende Question
> > >
> > > Hi All,
> > >
> > > Does anyone have a list of browsers and versions that correctly
> > > parse aria-modal="true" so that the user's Tab sequence is properly
> > > constrained within the container marked up with aria-modal="true"
> > > with no additional custom focus management?
> > >
> > > The reason why I ask has everything to do with user outcomes. I
> > > understand that SC 1.3.2 Meaningful Sequence in WCAG 2.x is passed
> > > if the Tab sequence "can be programmatically determined." But just
> > > because it "can" doesn't mean that the proper Tab sequence "will" be
> > > set if the browser/user agent doesn't render the modal content using
> > > the content author's intended interaction pattern.
> > >
> > > Do content authors have any assurance that if they use the right
> > > page code to pass SC 1.3.2 the Tab sequence will achieve an
> > > accessible result for users with disabilities who use a keyboard or
> > > similar input
> > approach?
> > >
> > > Brooks
> > >
> > > On Tue, Dec 6, 2022 at 7:22 PM Birkir R. Gunnarsson <
> > > <EMAIL REMOVED> > wrote:
> > >
> > > > If the content is visually presented as a dialog, it should have a
> > > > dialog role. If it doesn't I'd fail it under WCAG 4.1.2 for not
> > > > presenting its role.
> > > > Also, if it isn't a dialog, what happens when you press tab with
> > > > focus on the last interactive element in the dialog, where does
> > > > the focus end up? Based on that it's possible that I might fail it
> > > > under 2.4.3, but failing it under 1.3.2 would be a bit creative.
> > > > I think there's a 95%+ chance the content is visually presented a
> > > > a dialog/overlay/popover, what have you, and then it needs the
> > > > dialog role (+ accessible name and aria-modal="true" if it is
> > > > modal) for a screen reader user.
> > > >
> > > >
> > > >
> > > > On 12/6/22, Jim Homme < <EMAIL REMOVED> > wrote:
> > > > > Hi,
> > > > > In the page under consideration, there is a link. When the user
> > > > > clicks
> > > > the
> > > > > link, content appears. Focus jumps to the content. In the HTML
> > > > > order, though, the content is below the footer of the page. When
> > > > > the user hits a Close button, focus jumps back to the link the
> > > > > user
> > > originally clicked.
> > > > The
> > > > > content below the page footer disappears. Question: would you
> > > > > fail the content below the page footer for logical reading order?
> > > > >
> > > > > Jim
> > > > >
> > > > > =========> > > > > Jim Homme
> > > > > Senior Digital Accessibility Consultant Bender Consulting
> > > > > Services
> > > > > 412-787-8567
> > > > > https://urldefense.com/v3/__https://www.benderconsult.com/__;!!C
> > > > > 5q
> > > > > S4YX3!GuMVNHSBkaEzbZLo8QJI70NOcXPxC99Q7gSHSdnKF-fzWP6r5bTY3RZGxV
> > > > > LJ GcCkiF88dM_unt4Lx6H3XN-Mnbijd7EKsw$
> > > > > Support the dreams of independence through employment for
> > > > > students with disabilities with your Amazon purchases.
> > > > > https://urldefense.com/v3/__https://smile.amazon.com/ch/83-09882
> > > > > 51
> > > > > __;!!C5qS4YX3!GuMVNHSBkaEzbZLo8QJI70NOcXPxC99Q7gSHSdnKF-fzWP6r5b
> > > > > TY 3RZGxVLJGcCkiF88dM_unt4Lx6H3XN-Mnbgzk-mASw$
> > > > >
> > > > > > > > > > > > > > > https://urldefense.com/v3/__http://list.webaim.org/__;!!C5qS4YX3
> > > > > !G
> > > > > uMVNHSBkaEzbZLo8QJI70NOcXPxC99Q7gSHSdnKF-fzWP6r5bTY3RZGxVLJGcCki
> > > > > F8 8dM_unt4Lx6H3XN-MnbihMsHJyQ$ List archives at
> > > > > https://urldefense.com/v3/__http://webaim.org/discussion/archive
> > > > > s_
> > > > > _;!!C5qS4YX3!GuMVNHSBkaEzbZLo8QJI70NOcXPxC99Q7gSHSdnKF-fzWP6r5bT
> > > > > Y3 RZGxVLJGcCkiF88dM_unt4Lx6H3XN-MnbhTxjMXXg$
> > > > > > > > > >
> > > >
> > > >
> > > > --
> > > > Work hard. Have fun. Make history.
> > > > > > > > > > > > https://urldefense.com/v3/__http://list.webaim.org/__;!!C5qS4YX3!G
> > > > uM
> > > > VNHSBkaEzbZLo8QJI70NOcXPxC99Q7gSHSdnKF-fzWP6r5bTY3RZGxVLJGcCkiF88d
> > > > M_ unt4Lx6H3XN-MnbihMsHJyQ$ List archives at
> > > > https://urldefense.com/v3/__http://webaim.org/discussion/archives_
> > > > _;
> > > > !!C5qS4YX3!GuMVNHSBkaEzbZLo8QJI70NOcXPxC99Q7gSHSdnKF-fzWP6r5bTY3RZ
> > > > Gx VLJGcCkiF88dM_unt4Lx6H3XN-MnbhTxjMXXg$
> > > > > > > >
> > > > > > > > > https://urldefense.com/v3/__http://list.webaim.org/__;!!C5qS4YX3!GuM
> > > VN
> > > HSBkaEzbZLo8QJI70NOcXPxC99Q7gSHSdnKF-fzWP6r5bTY3RZGxVLJGcCkiF88dM_un
> > > t4 Lx6H3XN-MnbihMsHJyQ$ List archives at
> > > https://urldefense.com/v3/__http://webaim.org/discussion/archives__;!!
> > > C5qS4YX3!GuMVNHSBkaEzbZLo8QJI70NOcXPxC99Q7gSHSdnKF-fzWP6r5bTY3RZGxVL
> > > JG
> > > cCkiF88dM_unt4Lx6H3XN-MnbhTxjMXXg$
> > > > > > > > > > > > https://urldefense.com/v3/__http://list.webaim.org/__;!!C5qS4YX3!GuM
> > > VN
> > > HSBkaEzbZLo8QJI70NOcXPxC99Q7gSHSdnKF-fzWP6r5bTY3RZGxVLJGcCkiF88dM_un
> > > t4 Lx6H3XN-MnbihMsHJyQ$ List archives at
> > > https://urldefense.com/v3/__http://webaim.org/discussion/archives__;!!
> > > C5qS4YX3!GuMVNHSBkaEzbZLo8QJI70NOcXPxC99Q7gSHSdnKF-fzWP6r5bTY3RZGxVL
> > > JG
> > > cCkiF88dM_unt4Lx6H3XN-MnbhTxjMXXg$
> > > > > >
> > > > > > https://urldefense.com/v3/__http://list.webaim.org/__;!!C5qS4YX3!GuMVN
> > HSBkaEzbZLo8QJI70NOcXPxC99Q7gSHSdnKF-fzWP6r5bTY3RZGxVLJGcCkiF88dM_unt4
> > Lx6H3XN-MnbihMsHJyQ$
> > List archives at
> > https://urldefense.com/v3/__http://webaim.org/discussion/archives__;!!
> > C5qS4YX3!GuMVNHSBkaEzbZLo8QJI70NOcXPxC99Q7gSHSdnKF-fzWP6r5bTY3RZGxVLJG
> > cCkiF88dM_unt4Lx6H3XN-MnbhTxjMXXg$
> > > > > > > > https://urldefense.com/v3/__http://list.webaim.org/__;!!C5qS4YX3!GuMVN
> > HSBkaEzbZLo8QJI70NOcXPxC99Q7gSHSdnKF-fzWP6r5bTY3RZGxVLJGcCkiF88dM_unt4
> > Lx6H3XN-MnbihMsHJyQ$
> > List archives at
> > https://urldefense.com/v3/__http://webaim.org/discussion/archives__;!!
> > C5qS4YX3!GuMVNHSBkaEzbZLo8QJI70NOcXPxC99Q7gSHSdnKF-fzWP6r5bTY3RZGxVLJG
> > cCkiF88dM_unt4Lx6H3XN-MnbhTxjMXXg$
> > > > > > > > https://urldefense.com/v3/__http://list.webaim.org/__;!!C5qS4YX3!EZfNd
> > NMFPBXWgMeEcHULeIh4JbhG2EKtiPQnfSLAxQbLXIz7R47mo33AYA_84BTLhGm53ka-Dx9
> > OC_xPuHlQGw$
> > List archives at
> > https://urldefense.com/v3/__http://webaim.org/discussion/archives__;!!
> > C5qS4YX3!EZfNdNMFPBXWgMeEcHULeIh4JbhG2EKtiPQnfSLAxQbLXIz7R47mo33AYA_84
> > BTLhGm53ka-Dx9OC_xMm9mOoA$ > > <EMAIL REMOVED>
> > > > > > https://urldefense.com/v3/__http://list.webaim.org/__;!!C5qS4YX3!ES_iM
> > QX5wDPiqnROX6hXXbgsATGTSZKVi_AKAPHnAEwroHAUmZ66dpMslzsd8ZTiiHiVXv1Xm1v
> > bY4coJnKWrv3jQayk$ List archives at
> > https://urldefense.com/v3/__http://webaim.org/discussion/archives__;!!
> > C5qS4YX3!ES_iMQX5wDPiqnROX6hXXbgsATGTSZKVi_AKAPHnAEwroHAUmZ66dpMslzsd8
> > ZTiiHiVXv1Xm1vbY4coJnKWrj0f5qdC$ > > <EMAIL REMOVED>
> >
> > > https://urldefense.com/v3/__http://list.webaim.org/__;!!C5qS4YX3!ES_iMQX5wDPiqnROX6hXXbgsATGTSZKVi_AKAPHnAEwroHAUmZ66dpMslzsd8ZTiiHiVXv1Xm1vbY4coJnKWrv3jQayk$
> List archives at
> https://urldefense.com/v3/__http://webaim.org/discussion/archives__;!!C5qS4YX3!ES_iMQX5wDPiqnROX6hXXbgsATGTSZKVi_AKAPHnAEwroHAUmZ66dpMslzsd8ZTiiHiVXv1Xm1vbY4coJnKWrj0f5qdC$
> > > > > >