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

I'm not sure we should get rid of the idea entirely -- I don't mind that we
say a button can only have presentational children. It seems outside of the
scope of a button to do anything else. However, for a
checkbox/radio/menuitem, I have seen embedded controls and it seems to be
something within reason.

Also, historical API legacy is still a factor as many users don't upgrade
their versions of JAWS. I'm worried we'd break stuff if we stopped
truncating text children for buttons -- we'd probably get double speech for
the label.

Aaron

On Wed, Jul 5, 2017 at 2:10 PM Matt King <a11ythinker@gmail.com> wrote:

> *If we were to go that far, I think it would be worth discussing
> completely removing the concept of presentational children. This whole
> concept is in place because of historical limitations imposed by platform
> accessibility APIs and the screen reader design choices that have been made
> as a result of such constraints.*
>
>
>
> *In the mean time, the constraints imposed by the children presentational
> rules are designed to force authors inside of the constraints imposed by
> screen reader designs.*
>
>
>
> *For now, I do not think the children presentational rules impose
> unrealistic constraints on authors. You can still make just about any UI
> you can conceive. The coding is not always as elegant as we would like
> though … for sure.*
>
>
>
> *Matt*
>
>
>
> *From:* Aaron Leventhal [mailto:aleventhal@google.com]
> *Sent:* Wednesday, July 5, 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>
> 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> 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]
> *Sent:* Wednesday, July 5, 2017 9:14 AM
>
>
> *To:* Schnabel, Stefan <stefan.schnabel@sap.com>; Matt King <
> a11ythinker@gmail.com>; ARIA Working Group <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>
> 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]
> *Sent:* Mittwoch, 5. Juli 2017 15:21
> *To:* Schnabel, Stefan <stefan.schnabel@sap.com>; Matt King <
> a11ythinker@gmail.com>; ARIA Working Group <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>
> 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
>
>