Support for aria-controls

[LeonarddeR]

I'd have thought that an issue for this would already be here, but it doesn't seem to be the case.

Steps to reproduce:

Open the following in Firefox or Chrome: data:text/html, <button aria-controls="test">This button controls something</button><div id="test">something</div>

Actual behavior:

NVDA doesn't announce anything for the button or the something section beneath it.

Expected behavior:

NVDA should somehow announce that aria-controls is set on the button, referring to the something div.

System configuration:

NVDA Installed/portable/running from source:

Installed

NVDA version:

NVDA 2018.3.2

Windows version:

Windows 10 October update

Name and version of other software in use when reproducing the issue:

Firefox 63.0.3 Chrome 70.0.3538.110 Microsoft Edge

Additional details

In Chrome and Firefox, there is a relationship between the button and the div. On the button, the controllerFor relation refers to the div, and on the div, the controlledBy relation refers to the button.

Implementation ideas

In JAWS, when the button is focused, JAWS allows you to press jaws+alt+m to quickly jump to the controlled element. There are several disadvantages in this implementation:

1. It is pretty verbose
2. It doesn't allow you to jump back from the controlled element to the controlling element
3. I believe that it does not deal properly with an element controlling multiple other elements, which is allowed according to the spec.

I propose two separate gestures that allow to jump to controlled or controlling elements, respectively. If the number of elements is 1, NVDA should instantly jump to the particular element. If the number of elements is more then 1, I propose showing a context menu like shown when entering a keyboard input gesture in the input gestures dialog.

CC @MarcoZehe, @michaelDCurran, @bramd, @josephsl, @derekriemer, @jcsteEbh

[LeonarddeR]

@JulienCochuyt What do you think about this issue?

[JulienCochuyt]

@leonardder, I think your proposed UX is worthwhile. The two gestures could (should?) be somewhat logically linked, like adding shift to the first to obtain the second or using two related keys (neighbors, arrows, ...). Furthermore, the same gestures could be used to implement navigability to/from flowto regions (#4049). I doubt there could be a collision between the two concepts, but even then, the opening menu you propose would allow for choosing the desired navigation target.

Have you already thought on how to signal the availability of such navigation with speech and braille?

[LeonarddeR]

It looks like firefox only gives us the first target even though maxtargets is 0. See https://bugzilla.mozilla.org/show_bug.cgi?id=1574428

[Adriani90]

cc: @jcsteh

[MarcoZehe]

Moved it to the right component. Thanks for reporting @leonardder. :)

[LeonarddeR]

The Mozilla bug was fixed in nightly, thanks to the work by @jcsteh.

I have a prototype implementation in https://github.com/leonardder/nvda/tree/ariaControls

It currently does the following:

1. At the NVDAObject level, it implements the controllerFor and controlledBy properties
2. Add the virtual buffer level, it exposes unique IDs for controlledBy and controllerFor on VBuf nodes. Adding an additional relation to a node can be accomplished by adding just a single line.

I just removed the blocked label, but now realised this is blocked by #10098. Announcing these relations with sound is really preferred over some obnoxious text.

[Adriani90]

I am removing the blocked label since #10098 has been fixed by a coresponding PR.

[khsbory]

@leonardder @feerrenrut Hello, regarding aria-controls NVDA support, is this development in progress? Thank you.

[brennanyoung]

I just updated NVDA and there's no change yet. (Using test page from https://a11ysupport.io/tests/tech__aria__aria-controls ). This is a pretty important piece of ARIA, used in several of the APG patterns. Please prioritise up, now that it is no longer blocked.

[LeonarddeR]

I really need to dive into this again, but I have several projects that are of higher priority for me. I once started this as a POC for @BabbageCom, but since I'm no longer working there, it was slightly dropped.

[matuzo]

Almost a year has passed since the last comment. Are there any plans to implement functionality for aria-controls or is there any other update on the status? Thank you!

[LeonarddeR]

I have no plans myself currently, and if we'd implement it, we need to agree about user experience first.

[rperez030]

Regarding user experience, I'd like to propose that one gestures cicles between control and controling element. This would make jumping between a tab element and the corresponding tab panel, for example, a very seamless and intuitive process. How to convey that relationship to the user in the virtual buffer sounds trickier to me. cc @scottaohara and @smhigley

[scottaohara]

it's a weird one, aria-controls, since there are a lot of instances of its use where it could be considered superfluous to may any sort of user announcement - e.g., it's use for associating a combobox to its listbox popup, or a control that displays another element that is a sibling (or next focusable sibling) in the DOM.

but some of the biggest user benefits here overlap now with work that's been done with aria-details - e.g., Leonard and Roberto's mention of cycling between the invoking element and its controlled element(s) via a hot key.

While this ARIA issue appears early on in this thread, as this issue was mentioned in the ARIA issue, specifically linking to it here again as a reminder to anyone who might want to go check out the back n' forth there and the additional developers dropping in looking for what's up with support for the attribute.

[rperez030]

Would it make sense to support the existing UX for aria-details to present These relationships when appropriate? for example, pressing NVDA +D on something with aria-controls would announce the associated elements in the summary details. and naviation key "A" can be used to move browse cursor between them. @leonardder the quick jump menu that you suggested earlier could also include the list of annotations for the element with browse cursor.

[Adriani90]

what is the use case for sighted people actually? How does this work in the wild? Does a sighted person see which is the controlling object and which is the controlled object?

I like the idea of the hotkey in the focus mode to jump between them. If I understand it correctly, The controlled object is just for review purposes while the controlling object is the one with an action associated. Thus, for efficiency purposes I propose to additionally implement the announcement of the changes in the controlled object via an allert or notification mechanism as soon as the action on the controlling object is being performed. so we don't have to jump back and forth between controlling and controlled objects. Let's say I press a button which adds a new row to a sibling table, NVDA reports "new row added" or something like that. This step must be performed by the web author.

In terms of announcement of the aria controls, I suggest following:

• Controlling object: NVDA says: x button or x combo box > controls list / table /region etc. same as it works now with Aria haspopup: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-haspopup

• Controlled object: NVDA says "controlled table with x rows and y columns; controlled list with x elements; controlled region etc. when entering and "leaving controlled "..."" when leaving it.

[Adriani90]

@rperez030 What is the use case for a controlling element referencing multiple controlled elements? Let's say for example a button which deletes every input in all associated form fields, if this is a case, NVDA could say "delete all button > controlls multiple edit fields" and when arrowing or tabbing to the edit fields, NVDA would say "controlled edit field".

[LeonarddeR]

I think it would help if we had something in the wild that proves an aria controls implementation to be useful.

[Adriani90]

I think such scenarios are probably common in financial context, i.e. liquidity planing tools.Von meinem iPhone gesendetAm 16.08.2023 um 19:05 schrieb Leonard de Ruijter @.***>: I think it would help if we had something in the wild that proves an aria controls implementation to be useful.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[scottaohara]

at a high level, visually this sort of thing is very apparent because a user interacts with an element and then some other element(s) on the page is updated in some way. that might be because the element was toggled from a visible to hidden state, or vice versa (and again the best use case here is when that toggled content isn't a sibling element to the invoking element in the DOM. for instance, maybe a non-modal dialog). Or, a series of radios or checkboxes filter associated content on the page - common on many search results/ecommerce pages.

Using the checkbox to filter search results example - right now someone could arguably easy navigate to the changed content - assuming the filtered results are contained in the main landmark of the page, or even if they consistently started with a heading or were within a list. But navigating back to the specific checkbox used would be a lot less onerous if someone could just use a keystroke similar to navigating to and from aria-details related content.

[Adriani90]

So in summary we have three areas to be considered:

1. Reporting of action performed like "filter has been applied; new row has been added etc." (i.e. via allert or notification) >> implementation by the web author
2. Navigation between controlling and controlled elements (in focus and browse mode) via key strokes >> hot key for focus mode implemented by web author; >> quick navigation key for browse mode implemented by NVDA developers
3. Reporting of the atribute "controled" and "controls" on the coresponding elements / areas when navigating through the website >> implementation by NVDA developers.

[scottaohara]

yes for considerations 2 and 3.

and regarding point 1 - yeah, ensuring that a live region announcement has priority if it is fired due to the activating of the controlling element. Or, even if there were optional settings to expose information (if available) about the controlled element. E.g., per the filter scenario - if the aria-controls attribute pointed to an element like a list with an accessible name, arguably that could be made available (if the user wanted to hear that much info). Or, if the controlling element invoked something that wasn't previously exposed in the accessibility tree (like a non-modal dialog or some other element where focus was not automatically moved to it, for some reason) - then there could be a case to make that again if the controlled element has a name/role that can be exposed, then that could be exposed to let the user know what has appeared / that they could use X command to navigate to it, if they so chose.

but, all the above is me just throwing out ideas. so, happy for those to be used, ignored, or treated as jumping off points for better features someone else can think up :)

[jmuheim]

I would love to see aria-controls support in NVDA, too. 👍