WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: ARIA role changing browser behavior

for

From: Birkir R. Gunnarsson
Date: Dec 4, 2023 4:12PM

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 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 REMOVED> > On Behalf Of Jim
> Allan
> Sent: Monday, December 4, 2023 13:58
> To: WebAIM Discussion List < <EMAIL 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.