- From: David MacDonald <david100@sympatico.ca>
- Date: Mon, 15 Apr 2019 14:18:25 -0400
- To: James Nurthen <nurthen@adobe.com>
- Cc: Bryan Garaventa <bryan.garaventa@levelaccess.com>, "Scott O'Hara" <sohara@paciellogroup.com>, ARIA Working Group <public-aria@w3.org>
- Message-ID: <CAAdDpDa7iCq0Pc5MyoyHgnYPdoR9qVPAvEHn10DTht6S=EnE+Q@mail.gmail.com>
I agree with James The role=heading is overriding the role of legend in that case, so there is no name for the Group. Cheers, David MacDonald *Can**Adapt* *Solutions Inc.* Tel: 613-806-9005 LinkedIn <http://www.linkedin.com/in/davidmacdonald100> twitter.com/davidmacd GitHub <https://github.com/DavidMacDonald> www.Can-Adapt.com <http://www.can-adapt.com/> * Adapting the web to all users* * Including those with disabilities* If you are not the intended recipient, please review our privacy policy <http://www.davidmacd.com/disclaimer.html> On Fri, Apr 12, 2019 at 8:45 PM James Nurthen <nurthen@adobe.com> wrote: > Bryan, > > For your example > <fieldset> > <legend role="heading" aria-level="3">Question 1 text?</legend> > <div> Grouping of 15 radio buttons as possible answers. </div> > </fieldset> > > The group would not have an accessible name. > In 1.2 group gets it’s accessible name from either author or legend. > It does not have an author accessible name. > It does not have a descendent legend role - as the role has been > overridden. > > Hence it does not have an accessible name. > > Regards, > James > > James Nurthen | Accessibility Engineer | Adobe | p. 415.832.2734 | > c. 415.987.1918 | nurthen@adobe.com > > > > On 4/12/19, 5:36 PM, "Bryan Garaventa" <bryan.garaventa@levelaccess.com> > wrote: > > Thanks, > I get that part, though it doesn't answer the primary question of > whether the given markup should result in an accessible name regardless, > since the ARIA spec supports this. > > I'm going to need ARIA WG agreement on this before I can build out a > prototype for it. > > Thanks again, > Bryan > > > Bryan Garaventa > Principal Accessibility Architect > Level Access, Inc. > Bryan.Garaventa@LevelAccess.com > 415.624.2709 (o) > www.LevelAccess.com > > -----Original Message----- > From: Scott O'Hara <sohara@paciellogroup.com> > Sent: Friday, April 12, 2019 4:03 PM > To: Bryan Garaventa <bryan.garaventa@levelaccess.com>; 'ARIA Working > Group' <public-aria@w3.org> > Subject: Re: AccName for fieldset and legend, plus role="group" and > role="legend" proposal and questions > > CAUTION: This email originated from outside of the organization. Do > not click links or open attachments unless you recognize the sender and > know the content is safe. > > > Hey Bryan, > > Per your last question, if going by the HTML 5.2 spec ( > https://www.w3.org/TR/html52/sec-forms.html#the-legend-element) the > client could add a heading within the legend, which then wouldn't go > against the HTML-ARIA spec that doesn't allow for the heading role to be > added to the legend element. > > e.g. > > <fieldset> > <legend> > <span role=heading aria-level=3>whatever</span> > </legend> > <div> with all the radios </div> > </fieldset> > > Quickly verifying with Chrome, Firefox and Safari that produces > "whatever" as the group name, while also exposing the heading. > > The WHATWG HTML spec does not presently note that headings can be > children of legends. Though, that'd make for a good future PR imo... > > > Per examples 1-4, I think that all makes sense to me. Going to think > harder about it over the weekend. But wanted to at least answer the last > question rather than put it off. > > Have a nice weekend > > Scott > > > > On 4/12/19, 6:40 PM, "Bryan Garaventa" < > bryan.garaventa@levelaccess.com> wrote: > > Hi, > I've been doing some work on the naming computation logic for the > legend role, and found some questions having to do with implicit mappings > that I need some input on. > > First, I just realized that I've been misspelling the "role > parity" project as "role parody", and have filed some likely amusing bugs > with this. So, if anyone points this out, this was totally intentional and > I knew exactly what I was doing. > > Here is the relevant AccName logic for this if it makes sense. > > 1. The fieldset element implicitly maps to role="group", so for > the purpose of AccName, both of these are the same. > > 2. The legend element will implicitly map to role="legend", so > both are the same, and will automatically set the name of either fieldset > or role="group" if this is present as the nearest ancestor. > > 3. If fieldsets or groups are nested, the name for one group will > only be set using the nearest legend within that container, or receive no > name if no legend is found within that specific container. > > Example 1: Name for role=group is "Legend" > > <div role="group"> > <div class="wrapper"> > <div role="legend">Legend</div> > </div> > </div> > > Example 2: Name for outer role=group is "", Name for inner > role=group is "Legend" > > <div role="group"> > <div class="wrapper"> > <div role="group"> > <div role="legend">Legend</div> > </div> > </div> > </div> > > 4. if Legends are nested, only the outer legend will be used to > compute the name for the nearest fieldset element or role="group" ancestor. > > Does this make sense? Am I missing anything, or does something > else make more sense? > > Secondly, there is some code I was looking at today with a client, > which is invalid according to the HTML-ARIA Spec, but it still has to have > a valid naming computation regardless, and it doesn't violate the ARIA spec > in any way. > > The code is this: > > <fieldset> > <legend role="heading" aria-level="3">Question 1 text?</legend> > <div> Grouping of 15 radio buttons as possible answers. </div> > </fieldset> > > So, what is the fieldset or role="group" name in this case? > > Thanks, > Bryan > > > Bryan Garaventa > Principal Accessibility Architect > Level Access, Inc. > Bryan.Garaventa@LevelAccess.com > 415.624.2709 (o) > www.LevelAccess.com > > > > > > > >
Received on Monday, 15 April 2019 18:19:01 UTC