RE: Change in ARIA 1.1 breaks checkbox/radio with embedded field

Hi Aaron,
I recall that in one of the UAIG meetings we discussed this and determined that if an element is focusable it needs to ignore the presentational aspect if present. This is why it states the following in the spec:

“If an element with a role of presentation is focusable, or otherwise interactive, user agents MUST ignore the normal effect of the role and expose the
element with implicit native semantics, in order to ensure that the element is both
understandable
and
operable.”

http://www.w3.org/TR/wai-aria-1.1/#presentation


The above is a note, but I don’t know why this is not stated in the AAM where it should be, so this may be an issue worth following up on.

Still though, it seems like a bad design practice to do the following:

<div role=”checkbox” aria-label=”foo” tabindex=”0” aria-checked=”true”>
<div role=”radio” aria-label=”bar” tabindex=”0” aria-checked=”false”></div>
</div>

The issue here is discoverability. The only way to make something like this discoverable is to make role=”checkbox” a composite widget, as with everything else like radio, option, button, and all others.

So how do you intuitively activate something like this on screen readers that support offscreen virtual models, such as by arrowing to it in a Virtual Buffer then pressing Enter on it? Which would be activated, the checkbox or the radio?

The same is true for touch screen devices, what happens when you tap the control, which is activated and how do you distinguish one from the other intuitively?



Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com
415.624.2709 (o)
www.LevelAccess.com

From: Aaron Leventhal [mailto:aleventhal@google.com]
Sent: Wednesday, July 05, 2017 10:33 AM
To: Matt King <a11ythinker@gmail.com>; Schnabel, Stefan <stefan.schnabel@sap.com>; ARIA Working Group <public-aria@w3.org>
Subject: Re: Change in ARIA 1.1 breaks checkbox/radio with embedded field

To clarify, I'm concerned that enforcing childrenPresentational on too many roles may break cases like that. Perhaps we should clarify that children are presentational unless they happy to be focusable. We shouldn't remove stuff from the object tree that need to be able to report focus.

Aaron

On Wed, Jul 5, 2017 at 1:31 PM Aaron Leventhal <aleventhal@google.com<mailto:aleventhal@google.com>> wrote:
You're right, as long as it's done this way it doesn't break in ARIA 1.1.

However, I would have thought that the labels and textfield could have been children of the checkbox.

Aaron



On Wed, Jul 5, 2017 at 1:26 PM Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>> wrote:
Aaron, yes, it works great. I think this is a good example of how to make it work well.

what does aria 1.1 do to break this?

It looks to me like the span with the checkbox role is a sibling of the span with the input, i.e., the text input is not nested inside the checkbox.

This could be a good example for the APG, perhaps in the naming section as it demos a couple of important concepts.

Matt

From: Aaron Leventhal [mailto:aleventhal@google.com<mailto:aleventhal@google.com>]
Sent: Wednesday, July 5, 2017 9:14 AM

To: Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>; Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>; ARIA Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: Re: Change in ARIA 1.1 breaks checkbox/radio with embedded field

I've a working example (tested in Firefox + NVDA) -- Chrome stable's name calculation hasn't caught up completely yet.

When the checkbox is focused, the visible text, which includes the field value, is spoken for the name.

When the embedded textfield is focused, the aria-labelledby is spoken for it. This label is tied only to the textfield and is not spoken as part of the checkbox label -- it takes advantage of the rule that aria-labelledby is not recursive.

Aaron



On Wed, Jul 5, 2017 at 9:37 AM Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>> wrote:
>>> When the checkbox is focused the text field value will be part of the label.

Thanks clarifying this. Is this valid for all platforms that textfield value can serve as a relatable “label”? Would come in handy in best practices…


-          Stefan

From: Aaron Leventhal [mailto:aleventhal@google.com<mailto:aleventhal@google.com>]
Sent: Mittwoch, 5. Juli 2017 15:21
To: Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>; Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>; ARIA Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: Re: Change in ARIA 1.1 breaks checkbox/radio with embedded field

I've seen it be made accessible in an acceptable manner before. Perhaps it's not perfect, but these UI's exist and are not an error:
- Use an aria-labelledby on the textfield that is spoken when the textfield is focused. The textbox aria-labelledby will not be part of the checkbox name because use of aria-labelledby is not recursive according to the accessible name calculation.
- Next, ensure the textfield and static text before and after it are are all labelling the checkbox/radio. When the checkbox is focused the text field value will be part of the label.

Aaron



On Tue, Jul 4, 2017 at 6:11 AM Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>> wrote:
Hi Matt,

I’d like to comment to one point you made.

>>> We can make something that looks like a menu item with an edit work with ARIA, but we will not use the menuitem role.

It just not looks like, it IS an menuitem. And developers WILL do so since they see it as a semantic unit belonging together. This holds also true for Arons example, by the way.We simply have these and others in menu items occasionally as functional extension of this item being part in a menu structure. Treating it as alien addendum yield an Aria menu container full of aliens at the end. What lacks here is an menuitem extension concept that is promised for Aria 2.0.

Again, prohibiting things may help to get straight with ARIA but won’t solve the underlying issue.

Regards
Stefan


From: Matt King [mailto:a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>]
Sent: Montag, 3. Juli 2017 18:37
To: Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>; 'Aaron Leventhal' <aleventhal@google.com<mailto:aleventhal@google.com>>; 'ARIA Working Group' <public-aria@w3.org<mailto:public-aria@w3.org>>

Subject: RE: Change in ARIA 1.1 breaks checkbox/radio with embedded field

Stefan Schnabel wrote:

> We should be aware that people always mixup things in UI’s and call that “flexible”.
> At least the most common patterns should be supported

There is a difference between "mixing up the UI" and mixing up the corresponding ARIA. You can mix up UI any way you want and 9999 out of 10000 times I am sure we can get good ARIA to match it. But, mix up the ARIA and that is like lying to assistive technologies. It is like using color codes for red and expecting it to display as green.

To the extent we can't define a functional ARIA pattern to accurately describe a functional visual UI, we have a gap in ARIA.

> there are also menuitems with edit fields inside etc.

We can make something that looks like a menu item with an edit work with ARIA, but we will not use the menuitem role. This is the same reason that you will not use the color code for red when you want green.

> The list of examples may be continued easily,
> there are also many role=”option” type listbox items out in the wild
> that may contain interactive focusable subcontent.
> And yes, this may be an “author error”
> but it would be better to evolve the children concept towards something that acts more flexible here.

I 100% agree that we can do things to make coding easier. Just like many coding conveniences have been added to CSS over the years, reducing the need for a lot of complex javascript.

> Aria 1.1 Role=”grid” with two columns may be a substitute here
> but a bit overboard,
> in addition these cases are never “editable”
> which grid items are always potentially because of grid role definition..

Grid is much improved now, and the listbox type thingies are probably just as easy with grid as they would be with any other ARIA roles. We just have to do a little work to get screen readers on board. But, we would have to do that work regardless of which roles are used. In fact, because grid is already a composite widget that contains structural children, it is arguably easier for the screen reader developers to adjust to this model with grid than it would be with listbox because doing so with listbox would likely require changing platform accessibility APIs in rather significant ways.

Matt

From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com]
Sent: Monday, July 3, 2017 12:32 AM
To: Aaron Leventhal <aleventhal@google.com<mailto:aleventhal@google.com>>; ARIA Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: RE: Change in ARIA 1.1 breaks checkbox/radio with embedded field

We should be aware that people always mixup things in UI’s and call that “flexible”. At least the most common patterns should be supported, there are also menuitems with edit fields inside etc.

The list of examples may be continued easily, there are also many role=”option” type listbox items out in the wild that may contain interactive focusable subcontent. And yes, this may be an “author error” but it would be better to evolve the children concept towards something that acts more flexible here.

Aria 1.1 Role=”grid” with two columns may be a substitute here but a bit overboard, in addition these cases are never “editable” which grid items are always potentially because of grid role definition..


-          Stefan

From: Aaron Leventhal [mailto:aleventhal@google.com]
Sent: Freitag, 30. Juni 2017 21:11
To: ARIA Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: Change in ARIA 1.1 breaks checkbox/radio with embedded field


ARIA 1.1 says checkbox and radio have childrenPresentational: true, whereas ARIA 1.0 didn't.

Unfortunately, this will break the following use case:

[ ] Delete mail after ___ days

The ___ can be a textfield, combobox, etc. It's the reason that a value is part of the name computation. Unfortunately, when the parent checkbox/radio is childrenPresentational, we truncate the tree at that point and make it a leaf. So there is no object to fire events for when the embedded control gets focused.

<div role="checkbox">Delete mail after <input> days</div>

- Aaron