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 9, 2022 7:44AM

All great points, Birkir.

One of the ways I think aria-controls could be used is to provide visual
clues to users with some disabilities that expose the relationships between
interactive elements and the content they control on the page. So, instead
of a text or audible announcement upon landing on an aria-controls enabled
element, users might get a visual overlay that connects the dots between an
on page trigger (let's say a button) and a section of the page that is
impacted by a button, let's say. Maybe the controlled content is updated
immediately when the button is pressed, maybe there's significant delay
that makes aria-live .

Here's a case in point that's rooted in my personal reality: I'm a
caregiver for an 82 year old man who can see at long and mid distances
pretty well, but can't see the computer screen very well at all. That
forces him to slide up in his seat from time-to-time and get a little
closer to the screen. He doesn't use a screen magnifier, he just leans in
a little closer to focus to the screen when he wants to get a closer look
at a button he isn't familiar with.

This same person, my dad, also has Parkinson's disease, which for him,
causes a lag between thoughts and movements he makes, and sometimes causes
lag in cognition that makes it difficult for him to recognize the
cause/effect relationship of pressing a button and the resulting impact of
that button press on other parts of the screen.

Both of these disabilities, separately and together, make it so he could be
benefitted by a visual cue that connects buttons with the content they
control on the page.

Maybe a browser and/or assistive technology could supply a user
configurable option to display a visual overlay when he Tabs to (focuses
on) or mouses over (hovers on) a button that has aria-controls applied to
it in the underlying HTML of the page.

These adjacent possibilities for supporting different disabilities via
aria-controls markup make the concept worthy of further exploration.

One man's trash could be another man's treasure.

Later,

Brooks



On Fri, Dec 9, 2022 at 6:50 AM Birkir R. Gunnarsson <
<EMAIL REMOVED> > wrote:

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