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 9:36AM

aria-live is also only useful if the content that is updated is short,
text-based and does not include interactive elements, like links or
buttons.
Basically the content has to be fit for an automatic announcement.
Totally agree with your idea of how aria-controls could be used
outside of the world of a screen reader user. In fact, there is a huge
unexplored world of possibilities to turn accessibility markup into
accessible experiences for different users.


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


--
Work hard. Have fun. Make history.