E-mail List Archives

Search E-mail List Archives for

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

From: Jim Allan
Date: Mon, Dec 04 2023 2:58PM
Subject: ARIA role changing browser behavior
No previous message | Next message →

Hi all
I was testing a webpage that had an input that was readonly, but visually
functioned like a dropdown (some kind of react control - I am not a
scripter). the items in the 'dropdown' were 5 divs with several 'class'
values and tabindex=-1. the input control was a disaster and did not
function properly.
I hacked around in the Inspect tool. I removed the 'readonly' and added a
role="listbox" to the <input> and suddenly the input functioned perfectly
from the keyboard with a screenreader.
It has always been my understanding that aria roles change what the screen
reader calls something but does not affect the functioning. I am perplexed.
Could there be something in the JS that is looking for role="listbox" and
doing different things? Or is something else going on?
Anyone else experienced this?
I can't share the code as its a dev site.
Seeking understanding...
Jim

--
TSBVI Need assistance? Click this link for help: MOJO HELP DESK
<https://tsbvi.mojohelpdesk.com/mytickets/create#/ticket-form-selection>

Jim Allan, Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 fax: 512.206.9452 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964

From: Jeremy Echols
Date: Mon, Dec 04 2023 3:26PM
Subject: Re: ARIA role changing browser behavior
← Previous message | Next message →

Impossible to be certain without seeing the code, but your supposition is certainly plausible at least. When I have a control that I know has to behave a certain way, I like to latch onto ARIA attributes so that I can be reasonably certain that if the control looks to be working for sighted users, it is probably working for screen readers.

You can actually see things like this in the W3C ARIA examples. For instance, a disclosure menu widget's JS is set up to "attach" itself to any button with aria-expanded and aria-controls attributes: https://www.w3.org/WAI/content-assets/wai-aria-practices/patterns/disclosure/examples/js/disclosureMenu.js

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Jim Allan
Sent: Monday, December 4, 2023 13:58
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] ARIA role changing browser behavior

Hi all
I was testing a webpage that had an input that was readonly, but visually functioned like a dropdown (some kind of react control - I am not a scripter). the items in the 'dropdown' were 5 divs with several 'class'
values and tabindex=-1. the input control was a disaster and did not function properly.
I hacked around in the Inspect tool. I removed the 'readonly' and added a role="listbox" to the <input> and suddenly the input functioned perfectly from the keyboard with a screenreader.
It has always been my understanding that aria roles change what the screen reader calls something but does not affect the functioning. I am perplexed.
Could there be something in the JS that is looking for role="listbox" and doing different things? Or is something else going on?
Anyone else experienced this?
I can't share the code as its a dev site.
Seeking understanding...
Jim

--
TSBVI Need assistance? Click this link for help: MOJO HELP DESK <https://urldefense.com/v3/__https://tsbvi.mojohelpdesk.com/mytickets/create*/ticket-form-selection__;Iw!!C5qS4YX3!C2V98Q8QK0-OKIj__eVOrLFghOrA0tY9qyc14gqWEVZkEeCck00lD0NXq5gn1DQa7NZsVef0hHDHqK7o1tA3mw$ >

Jim Allan, Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 fax: 512.206.9452 https://urldefense.com/v3/__http://www.tsbvi.edu/__;!!C5qS4YX3!C2V98Q8QK0-OKIj__eVOrLFghOrA0tY9qyc14gqWEVZkEeCck00lD0NXq5gn1DQa7NZsVef0hHDHqK6128g1GA$
"We shape our tools and thereafter our tools shape us." McLuhan, 1964

From: Birkir R. Gunnarsson
Date: Mon, Dec 04 2023 4:12PM
Subject: Re: ARIA role changing browser behavior
← Previous message | Next message →

Did the keyboard behavior also changed when you updated the ARIA role
or did it only affect the screen reader announcement of the widget?
If the keyboard behavior (with or without screen reader running)
changed, that's certinly a departure from the classic principal of
"ARIA affects presentation but not functionality".
That being said, individaul browser vendors may decide to handle ARIA
roles in certain ways, even attach default keyboard behaviors to them,
there's nothing that forbids them from doing that.
Is this change confined to a single browser or can you reproduce it in
multiple browsers?

On 12/4/23, Jeremy Echols < = EMAIL ADDRESS REMOVED = > wrote:
> Impossible to be certain without seeing the code, but your supposition is
> certainly plausible at least. When I have a control that I know has to
> behave a certain way, I like to latch onto ARIA attributes so that I can be
> reasonably certain that if the control looks to be working for sighted
> users, it is probably working for screen readers.
>
> You can actually see things like this in the W3C ARIA examples. For
> instance, a disclosure menu widget's JS is set up to "attach" itself to any
> button with aria-expanded and aria-controls attributes:
> https://www.w3.org/WAI/content-assets/wai-aria-practices/patterns/disclosure/examples/js/disclosureMenu.js
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Jim
> Allan
> Sent: Monday, December 4, 2023 13:58
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Subject: [WebAIM] ARIA role changing browser behavior
>
> Hi all
> I was testing a webpage that had an input that was readonly, but visually
> functioned like a dropdown (some kind of react control - I am not a
> scripter). the items in the 'dropdown' were 5 divs with several 'class'
> values and tabindex=-1. the input control was a disaster and did not
> function properly.
> I hacked around in the Inspect tool. I removed the 'readonly' and added a
> role="listbox" to the <input> and suddenly the input functioned perfectly
> from the keyboard with a screenreader.
> It has always been my understanding that aria roles change what the screen
> reader calls something but does not affect the functioning. I am perplexed.
> Could there be something in the JS that is looking for role="listbox" and
> doing different things? Or is something else going on?
> Anyone else experienced this?
> I can't share the code as its a dev site.
> Seeking understanding...
> Jim
>
> --
> TSBVI Need assistance? Click this link for help: MOJO HELP DESK
> <https://urldefense.com/v3/__https://tsbvi.mojohelpdesk.com/mytickets/create*/ticket-form-selection__;Iw!!C5qS4YX3!C2V98Q8QK0-OKIj__eVOrLFghOrA0tY9qyc14gqWEVZkEeCck00lD0NXq5gn1DQa7NZsVef0hHDHqK7o1tA3mw$
>>
>
> Jim Allan, Accessibility Coordinator
> Texas School for the Blind and Visually Impaired
> 1100 W. 45th St., Austin, Texas 78756
> voice 512.206.9315 fax: 512.206.9452
> https://urldefense.com/v3/__http://www.tsbvi.edu/__;!!C5qS4YX3!C2V98Q8QK0-OKIj__eVOrLFghOrA0tY9qyc14gqWEVZkEeCck00lD0NXq5gn1DQa7NZsVef0hHDHqK6128g1GA$
>
> "We shape our tools and thereafter our tools shape us." McLuhan, 1964
> > > https://urldefense.com/v3/__http://list.webaim.org/__;!!C5qS4YX3!C2V98Q8QK0-OKIj__eVOrLFghOrA0tY9qyc14gqWEVZkEeCck00lD0NXq5gn1DQa7NZsVef0hHDHqK6d5ygxIg$
> List archives at
> https://urldefense.com/v3/__http://webaim.org/discussion/archives__;!!C5qS4YX3!C2V98Q8QK0-OKIj__eVOrLFghOrA0tY9qyc14gqWEVZkEeCck00lD0NXq5gn1DQa7NZsVef0hHDHqK6woq5vWQ$
> > > > > >


--
Work hard. Have fun. Make history.

From: Jim Allan
Date: Mon, Dec 04 2023 4:33PM
Subject: Re: ARIA role changing browser behavior
← Previous message | Next message →

Birkir
The control was announced as a list box after the role was added. when I
hit enter on a focused item, it was actually selected.
Previously, before adding the role, items were announced when focused but
the enter key did not select the focused item.
The browser in question is Edge.
Jim

On Mon, Dec 4, 2023, 5:12 PM Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> Did the keyboard behavior also changed when you updated the ARIA role
> or did it only affect the screen reader announcement of the widget?
> If the keyboard behavior (with or without screen reader running)
> changed, that's certinly a departure from the classic principal of
> "ARIA affects presentation but not functionality".
> That being said, individaul browser vendors may decide to handle ARIA
> roles in certain ways, even attach default keyboard behaviors to them,
> there's nothing that forbids them from doing that.
> Is this change confined to a single browser or can you reproduce it in
> multiple browsers?
>
> On 12/4/23, Jeremy Echols < = EMAIL ADDRESS REMOVED = > wrote:
> > Impossible to be certain without seeing the code, but your supposition is
> > certainly plausible at least. When I have a control that I know has to
> > behave a certain way, I like to latch onto ARIA attributes so that I can
> be
> > reasonably certain that if the control looks to be working for sighted
> > users, it is probably working for screen readers.
> >
> > You can actually see things like this in the W3C ARIA examples. For
> > instance, a disclosure menu widget's JS is set up to "attach" itself to
> any
> > button with aria-expanded and aria-controls attributes:
> >
> https://www.w3.org/WAI/content-assets/wai-aria-practices/patterns/disclosure/examples/js/disclosureMenu.js
> >
> > -----Original Message-----
> > From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> Jim
> > Allan
> > Sent: Monday, December 4, 2023 13:58
> > To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> > Subject: [WebAIM] ARIA role changing browser behavior
> >
> > Hi all
> > I was testing a webpage that had an input that was readonly, but visually
> > functioned like a dropdown (some kind of react control - I am not a
> > scripter). the items in the 'dropdown' were 5 divs with several 'class'
> > values and tabindex=-1. the input control was a disaster and did not
> > function properly.
> > I hacked around in the Inspect tool. I removed the 'readonly' and added a
> > role="listbox" to the <input> and suddenly the input functioned
> perfectly
> > from the keyboard with a screenreader.
> > It has always been my understanding that aria roles change what the
> screen
> > reader calls something but does not affect the functioning. I am
> perplexed.
> > Could there be something in the JS that is looking for role="listbox" and
> > doing different things? Or is something else going on?
> > Anyone else experienced this?
> > I can't share the code as its a dev site.
> > Seeking understanding...
> > Jim
> >
> > --
> > TSBVI Need assistance? Click this link for help: MOJO HELP DESK
> > <
> https://urldefense.com/v3/__https://tsbvi.mojohelpdesk.com/mytickets/create*/ticket-form-selection__;Iw!!C5qS4YX3!C2V98Q8QK0-OKIj__eVOrLFghOrA0tY9qyc14gqWEVZkEeCck00lD0NXq5gn1DQa7NZsVef0hHDHqK7o1tA3mw$
> >>
> >
> > Jim Allan, Accessibility Coordinator
> > Texas School for the Blind and Visually Impaired
> > 1100 W. 45th St., Austin, Texas 78756
> > voice 512.206.9315 fax: 512.206.9452
> >
> https://urldefense.com/v3/__http://www.tsbvi.edu/__;!!C5qS4YX3!C2V98Q8QK0-OKIj__eVOrLFghOrA0tY9qyc14gqWEVZkEeCck00lD0NXq5gn1DQa7NZsVef0hHDHqK6128g1GA$
> >
> > "We shape our tools and thereafter our tools shape us." McLuhan, 1964
> > > > > >
> https://urldefense.com/v3/__http://list.webaim.org/__;!!C5qS4YX3!C2V98Q8QK0-OKIj__eVOrLFghOrA0tY9qyc14gqWEVZkEeCck00lD0NXq5gn1DQa7NZsVef0hHDHqK6d5ygxIg$
> > List archives at
> >
> https://urldefense.com/v3/__http://webaim.org/discussion/archives__;!!C5qS4YX3!C2V98Q8QK0-OKIj__eVOrLFghOrA0tY9qyc14gqWEVZkEeCck00lD0NXq5gn1DQa7NZsVef0hHDHqK6woq5vWQ$
> > > > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >

From: Birkir R. Gunnarsson
Date: Mon, Dec 04 2023 5:17PM
Subject: Re: ARIA role changing browser behavior
← Previous message | Next message →

Are there any differences in the keyboard operation if the screen
reader is not running?

On 12/4/23, Jim Allan < = EMAIL ADDRESS REMOVED = > wrote:
> Birkir
> The control was announced as a list box after the role was added. when I
> hit enter on a focused item, it was actually selected.
> Previously, before adding the role, items were announced when focused but
> the enter key did not select the focused item.
> The browser in question is Edge.
> Jim
>
> On Mon, Dec 4, 2023, 5:12 PM Birkir R. Gunnarsson <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> Did the keyboard behavior also changed when you updated the ARIA role
>> or did it only affect the screen reader announcement of the widget?
>> If the keyboard behavior (with or without screen reader running)
>> changed, that's certinly a departure from the classic principal of
>> "ARIA affects presentation but not functionality".
>> That being said, individaul browser vendors may decide to handle ARIA
>> roles in certain ways, even attach default keyboard behaviors to them,
>> there's nothing that forbids them from doing that.
>> Is this change confined to a single browser or can you reproduce it in
>> multiple browsers?
>>
>> On 12/4/23, Jeremy Echols < = EMAIL ADDRESS REMOVED = > wrote:
>> > Impossible to be certain without seeing the code, but your supposition
>> > is
>> > certainly plausible at least. When I have a control that I know has to
>> > behave a certain way, I like to latch onto ARIA attributes so that I can
>> be
>> > reasonably certain that if the control looks to be working for sighted
>> > users, it is probably working for screen readers.
>> >
>> > You can actually see things like this in the W3C ARIA examples. For
>> > instance, a disclosure menu widget's JS is set up to "attach" itself to
>> any
>> > button with aria-expanded and aria-controls attributes:
>> >
>> https://www.w3.org/WAI/content-assets/wai-aria-practices/patterns/disclosure/examples/js/disclosureMenu.js
>> >
>> > -----Original Message-----
>> > From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
>> Jim
>> > Allan
>> > Sent: Monday, December 4, 2023 13:58
>> > To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>> > Subject: [WebAIM] ARIA role changing browser behavior
>> >
>> > Hi all
>> > I was testing a webpage that had an input that was readonly, but
>> > visually
>> > functioned like a dropdown (some kind of react control - I am not a
>> > scripter). the items in the 'dropdown' were 5 divs with several 'class'
>> > values and tabindex=-1. the input control was a disaster and did not
>> > function properly.
>> > I hacked around in the Inspect tool. I removed the 'readonly' and added
>> > a
>> > role="listbox" to the <input> and suddenly the input functioned
>> perfectly
>> > from the keyboard with a screenreader.
>> > It has always been my understanding that aria roles change what the
>> screen
>> > reader calls something but does not affect the functioning. I am
>> perplexed.
>> > Could there be something in the JS that is looking for role="listbox"
>> > and
>> > doing different things? Or is something else going on?
>> > Anyone else experienced this?
>> > I can't share the code as its a dev site.
>> > Seeking understanding...
>> > Jim
>> >
>> > --
>> > TSBVI Need assistance? Click this link for help: MOJO HELP DESK
>> > <
>> https://urldefense.com/v3/__https://tsbvi.mojohelpdesk.com/mytickets/create*/ticket-form-selection__;Iw!!C5qS4YX3!C2V98Q8QK0-OKIj__eVOrLFghOrA0tY9qyc14gqWEVZkEeCck00lD0NXq5gn1DQa7NZsVef0hHDHqK7o1tA3mw$
>> >>
>> >
>> > Jim Allan, Accessibility Coordinator
>> > Texas School for the Blind and Visually Impaired
>> > 1100 W. 45th St., Austin, Texas 78756
>> > voice 512.206.9315 fax: 512.206.9452
>> >
>> https://urldefense.com/v3/__http://www.tsbvi.edu/__;!!C5qS4YX3!C2V98Q8QK0-OKIj__eVOrLFghOrA0tY9qyc14gqWEVZkEeCck00lD0NXq5gn1DQa7NZsVef0hHDHqK6128g1GA$
>> >
>> > "We shape our tools and thereafter our tools shape us." McLuhan, 1964
>> > >> > >> >
>> https://urldefense.com/v3/__http://list.webaim.org/__;!!C5qS4YX3!C2V98Q8QK0-OKIj__eVOrLFghOrA0tY9qyc14gqWEVZkEeCck00lD0NXq5gn1DQa7NZsVef0hHDHqK6d5ygxIg$
>> > List archives at
>> >
>> https://urldefense.com/v3/__http://webaim.org/discussion/archives__;!!C5qS4YX3!C2V98Q8QK0-OKIj__eVOrLFghOrA0tY9qyc14gqWEVZkEeCck00lD0NXq5gn1DQa7NZsVef0hHDHqK6woq5vWQ$
>> > >> > >> > >> > >> > >> >
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.

From: Patrick H. Lauke
Date: Mon, Dec 04 2023 6:02PM
Subject: Re: ARIA role changing browser behavior
← Previous message | Next message →

Screen readers also take a hint from the role about which key presses
should be passed on to the browser. In addition, screen readers will
also simulate/fake actual mouse events and clicks as a result of a
keypress, depending on the role they see, just to make sure that badly
coded pages work correctly.

So yes, adding a role can, in effect, change the way screen readers
behave, which in turn can "fix" certain behaviours.

Note however that this doesn't change how the browser itself behaves
when no SRs are running. i.e. if something is broken for keyboard users
without SRs, then adding a role won't change that.

P
--
Patrick H. Lauke

* https://www.splintered.co.uk/
* https://github.com/patrickhlauke
* https://flickr.com/photos/redux/
* https://mastodon.social/@patrick_h_lauke

From: Mark Magennis
Date: Tue, Dec 05 2023 2:12AM
Subject: Re: ARIA role changing browser behavior
← Previous message | No next message

As far as I can tell, screen readers often use heuristics to guess what a control might be in cases where it is non-standard or seems to be incorrectly coded. One example is if you add tabindex (with any value) to a list or list item (whether coded as a ul or role="list"), JAWS will announce it as a listbox and enter forms mode when you tab or arrow to it (assuming you have auto forms mode on in your JAWS settings). It seems like JAWS is assuming it is meant to be a listbox and changing its behavior accordingly. I've seen similar behavior due to adding role="button" to a <button> with aria-haspopup.
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of Jim Allan < = EMAIL ADDRESS REMOVED = >
Sent: Monday 4 December 2023 21:58
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [EXTERNAL] [WebAIM] ARIA role changing browser behavior

Hi all
I was testing a webpage that had an input that was readonly, but visually
functioned like a dropdown (some kind of react control - I am not a
scripter). the items in the 'dropdown' were 5 divs with several 'class'
values and tabindex=-1. the input control was a disaster and did not
function properly.
I hacked around in the Inspect tool. I removed the 'readonly' and added a
role="listbox" to the <input> and suddenly the input functioned perfectly
from the keyboard with a screenreader.
It has always been my understanding that aria roles change what the screen
reader calls something but does not affect the functioning. I am perplexed.
Could there be something in the JS that is looking for role="listbox" and
doing different things? Or is something else going on?
Anyone else experienced this?
I can't share the code as its a dev site.
Seeking understanding...
Jim

--
TSBVI Need assistance? Click this link for help: MOJO HELP DESK
<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftsbvi.mojohelpdesk.com%2Fmytickets%2Fcreate%23%2Fticket-form-selection&data%7C01%7CMark.Magennis%40skillsoft.com%7Cb9538696eaa146881d3a08dbf514287e%7C50361608aa23494da2332fd14d6a03f4%7C0%7C0%7C638373239164039709%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OGkCRLDvo2hL1mpTIvM%2FDpmvt9UZvV%2FZC6f0fzlathA%3D&reserved=0<https://tsbvi.mojohelpdesk.com/mytickets/create#/ticket-form-selection>>

Jim Allan, Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 fax: 512.206.9452 https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.tsbvi.edu%2F&data%7C01%7CMark.Magennis%40skillsoft.com%7Cb9538696eaa146881d3a08dbf514287e%7C50361608aa23494da2332fd14d6a03f4%7C0%7C0%7C638373239164039709%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata£K6UiTbIv0op567wrowUyKKRioFarMXF447m%2B8hGYg%3D&reserved=0<http://www.tsbvi.edu/>;
"We shape our tools and thereafter our tools shape us." McLuhan, 1964