E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 8 (In chronological order)

From: allyssa jessicon
Date: Thu, Dec 08 2022 4:35AM
Subject: WCAG On input with Auto radio button content update
No previous message | Next message →

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

From: Graham Armfield
Date: Thu, Dec 08 2022 5:28AM
Subject: Re: WCAG On input with Auto radio button content update
← Previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Thu, Dec 08 2022 5:38AM
Subject: Re: WCAG On input with Auto radio button content update
← Previous message | Next message →

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

From: Brooks Newton
Date: Thu, Dec 08 2022 7:45PM
Subject: Re: WCAG On input with Auto radio button content update
← Previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Fri, Dec 09 2022 5:50AM
Subject: Re: WCAG On input with Auto radio button content update
← Previous message | Next message →

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

From: Brooks Newton
Date: Fri, Dec 09 2022 7:44AM
Subject: Re: WCAG On input with Auto radio button content update
← Previous message | Next message →

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

From: Brooks Newton
Date: Fri, Dec 09 2022 7:48AM
Subject: Re: WCAG On input with Auto radio button content update
← Previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Fri, Dec 09 2022 9:36AM
Subject: Re: WCAG On input with Auto radio button content update
← Previous message | No next message

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