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>
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]
> *Sent:* Montag, 3. Juli 2017 18:37
> *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 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
> <stefan.schnabel@sap.com>]
> *Sent:* Monday, July 3, 2017 12:32 AM
> *To:* 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
>
>
>
> 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
> <aleventhal@google.com>]
> *Sent:* Freitag, 30. Juni 2017 21:11
> *To:* ARIA Working Group <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
>