WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG On input with Auto radio button content update

for

From: Brooks Newton
Date: Dec 8, 2022 7:45PM

In response to Heydon's article on aria-controls
<https://heydonworks.com/article/aria-controls-is-poop/>, I wonder if it's
aria-controls as it is currently implemented in JAWS that's not-so-good?

When I look up the definition of aria-controls in the ARIA 1.2
specification, it says that the property "identifies the element (or
elements) whose contents or presence are controlled by the current element"
and says nothing about navigating to the controlled element or reading its
contents in their entirety. If I'm misreading this, or if I'm missing some
other interaction definition that's baked into a standard somewhere, let me
know. I'm out of my lane here, I know - but I'm honestly trying to express
some ideas I think are worthy of consideration.

This is really a question for all on this thread about aria-controls should
work:

Would it be better, or at least more useful, to give users a quick overview
of what's being controlled without navigating away from the control itself
(such as with the announcement of a Tab control in a Tab Panel widget)?
Just a quick teaser of the content that's being controlled, maybe a heading
from each controlled element that's announced?

I'm a fan Heydon's work - it's top talent reading, for sure. But, I do
have a couple of thoughts about some of the fundamental premises Heydon
includes in his article and ultimate conclusion that might be of interest
to some on this thread.

For example, he says we think of aria-controls as giving users the ability
to "flit between the moving parts of a web application..." But, honestly,
isn't that expectation set because that's the way one screen reader
manufacturer chose to interpret the behavior of aria-controls?

Also, he talks about how cumbersome it is for users to hear "press the JAWS
key plus Alt and M to move to the controlled element" and says that the
announcement is "Verbose and clumsy." But won't that always be the problem
whenever we introduce new interactivity that goes beyond what users have
traditionally used? That's a problem for AT users and non-AT users alike,
when it comes to any new style ARIA widget.

With new content interaction methods comes the responsibility for content
authors to communicate those new interaction instructions to users. The
verbosity of the aria-controls announcement is certainly a prime candidate
for configuration by the user in the AT. There's nothing special about
aria-controls, in terms of the conundrum of how to unobtrusively instruct
users on new ways of interacting with content. So I don't count that as a
legitimate knock against this property.

Who knows when new browser adoption of this property will come about? Who
knows if it will be handled in a way that's consistent across assistive
technology and user agents (the line is not so clear between the two)?
Wouldn't it be great if we could all (users, developers, software makers
and standards folks) work together to figure out a solution that works well
for all, instead of trashing the concept because of a less than perfect
first attempt by JAWS?

I think it would be great if we could have a new standard HTML approach
that would work for all users, rather than type-casting accessibility fixes
as enhancements that are only available to AT users/buyers. For example,
we could work out an agreement with browser manufacturers (or at least one
who is willing) to interpret links with role="tab" so that they
automatically expose the identification of controlled elements in the
presence of appropriate aria-controls or standard HTML equivalent markup on
the same anchor tag? Make that info available to anyone who wants it.
There are a lot more people than blind folks who could benefit from a short
summary that is programmatically associated with a control.

As to the question of "How in the hell do I move back?" How about using
the "Back" button using all of the rules that browsers currently employ to
determine how long it's in effect. That's if we go for the super-cool HTML
works-for-everyone route.

If aria-controls has to stay as it is for the time being, an AT-only
feature, how about asking all AT manufacturers to build a list of
interactive elements that are currently in the Tab order of the page that
have the aria-controls property applied to them, and let users read and
navigate back to the controlling element that way?

Last thought: Is there any value in hoping for progressive enhancement
associated with this property that makes it worth including in widgets such
as Tab Panels today - especially if content authors provide redundant focus
control for all users using JavaScript?

Heck, I don't know man exactly how it will all go. But, isn't it worth a
try to salvage this ARIA concept, or better yet, expand it for use to users
who haven't traditionally used AT to interact with new-style widgets?

Use aria-controls now? Use only with redundant focus control.
Give up on developing a better interaction model for aria-controls? No way.

Over And Out,

Brooks



On Thu, Dec 8, 2022 at 6:38 AM Birkir R. Gunnarsson <
<EMAIL REMOVED> > wrote:

> This fails WCAG 3.2.2.
> Automatically moving focus when you change the setting of a control
> (i.e. select a radio button), falls under the 3.2.2 definition of
> "change of context".
>
> Also one could argue this fails content order, (if the content that
> gets updated comes, in content order, before the controls used to
> update it).
>
> If you placed the radio buttons before the content and did not move
> focus to the content when you select them, this would be passable,
> better yet if there is a "go to updated content" button after the
> radio buttons.
> Yes, aria-controls should've solved this situation (not the movement
> of focus but being able to navigate from a control to the content
> affected by that control) but, in the words of a famous accessibility
> rock star "aria-controls is poop":
> https://heydonworks.com/article/aria-controls-is-poop/
>
>
> On 12/8/22, Graham Armfield < <EMAIL REMOVED> > wrote:
> > One of the first things I would worry about would be keyboard
> > accessibility.
> >
> > Keyboard users will typically move through the radio buttons with left,
> > right or up, down keystrokes. Moving focus automatically to new/updated
> > content after each keystroke would be a real problem.
> >
> > So I think that would be a fail.
> >
> > Regards
> > Graham Armfield
> >
> > On Thu, 8 Dec 2022, 11:35 am allyssa jessicon, <
> <EMAIL REMOVED> >
> > wrote:
> >
> >> "I am back with another question.
> >>
> >> This is related to WCAG 3.2.2 On Input. The scenario is as follows -
> >>
> >> If there are some radio buttons at the right side of a page, take it
> >> as Sort low to high, A to Z, Sort by popularity etc. When user
> >> activates the radio button the page content is getting updated based
> >> on the radio button user activated and this is happens on the left
> >> side of the page. Focus is setting to the Main content after each
> >> radio button activation.
> >>
> >> Below are my questions -
> >> Does this fail WCAG 3.2.2 On Input? If not, changing setting of the
> >> radio button and the content which gets updated is an expected
> >> behaviour? in that case wouldn't be the focus expected to set on the
> >> triggered element itself (the radio buttons)
> >>
> >> Awaiting great responses."
> >> > >> > >> > >> > >>
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >