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

Hi Matt,

Thanks for the extensive explanations.

>> If you want to collaborate on making a functional example of this type of menu UI that aligns with the ARIA specification, perhaps that is something we could include in the APG.

Based on Aarons example of yesterday I can try something in code for a menu item with an input. These edge cases will bring the APG forward..

Regards
Stefan


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

Stefan wrote:

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

This is one of the most important things to understand about ARIA ... The words used to describe ARIA roles do not map to every interpretation of the same word used in other contexts.

The meaning of an ARIA role is defined strictly by the way it is represented in an accessibility API and to some extent by the interaction model expected for that mapping by consuming assistive technologies. We have normative definition of the former and are attempting to reach consensus on the essential elements of the latter in the practices document.

In other words, the conotation of the terms menu and menuitem are not relevant when it comes to ARIA; only the denotation matters.

BTW, in what I previously wrote, I should have said “we may not use the menuitem role. Instead of “will not.” I don’t know enough about the specific UI to make that call.

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

As Aaron demonstrated with the way he made the checkbox work, we can make patterns that do these things.
You just have to implement the ARIA in a way that will work.

> What lacks here is an menuitem extension concept that is promised for Aria 2.0.

I don't think we need ARIA 2.0 to make your UI work reliably with assistive technologies. I think we need to improve on the implementation, interpretation, and comsumption of ARIA 1.0/1.1.

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

ARIA does not prohibit the kinds of designs you are describing. ARIA is only prohibiting developers from coding the ARIA markup in any way they think makes sense to them personally. With a few tweaks to get better alignment with the spec, we can make it make sense to both the developer and the assistive technologies. And, once we have consensus on that alignment, if it still doesn’t work with assistive technologies, we have what we need to raise the issue with the assistive technology vendors.

If you want to collaborate on making a functional example of this type of menu UI that aligns with the ARIA specification, perhaps that is something we could include in the APG.

Matt

From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com]
Sent: Tuesday, July 4, 2017 3:12 AM
To: Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.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

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