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