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:48AM

Sorry, at the end of my first paragraph of the previous message I mean to
say " Maybe the controlled content is updated immediately when the button
is pressed, maybe there's a significant delay that makes aria-live an
ineffective tool to expose the logical connection between the button and
what it controls.

My bad.

On Fri, Dec 9, 2022 at 8:44 AM Brooks Newton < <EMAIL REMOVED> >
wrote:

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