WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG On input with Auto radio button content update

for

From: Birkir R. Gunnarsson
Date: Dec 9, 2022 5:50AM

Basically aria-controls is a way to express the relationship between
an interactive control (that can be activated or whose values can be
changed) and the content that is updated (added/inserted/changed) as a
result of that interaction.
If clicking a control takes you directly to the content you wouldn't need it.
If the change is minor, like an amount that gets updated, and if that
change is announced as a live region, you probably don't need it.
Nor do you really, if the content that is being changed comes
immediately after the control you interact with to change it.

But that leaves the question when is it useful and how can it be used.
That is mostly up to assistive technology vendors to play with,
provided the relationship is coded and exposed by a browser.
Since ARIA is almost exclusively used/supported by screen readers,
they would be candidates to pioneer the possibilities, but they
haven't done much of it.

I think pretty much the only things a screen reader can do is to let
users navigate from the control to the content that is controlled, or
move the controlled content to immediately after the control, or
automatically announce changes to that content, even if it isn't coded
as a live region (browser permitting).

Jaws did create a shortcut to get from the control to the content,
like Hayden points out.
It is announced every time you navigate to an element with an
aria-controls attribute.
It's necessary until users become aware of it, but can be turned off
in verbosity settings.
That announcement never bothered me much; in fact I applauded it. At
least Jaws was trying to do something with this property, I don't
think any other screen reader did so.
Generally speaking I think we need more collaboration and guidance
around new ARIA attributes, especially relational ones. Why are they
being added, why and how are they used? How do assistive technology
users benefit?
Some of the ARIA attributes suffer from lack of clarity or purpose,
and can easily lose value, even reducing the value of ARIA as a
standard.


On 12/8/22, Brooks Newton < <EMAIL REMOVED> > wrote:
> 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.
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.