WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: ARIA role changing browser behavior

for

From: Jim Allan
Date: Dec 4, 2023 4:33PM

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