Issue 875 need role for fieldeset/legend #911
Conversation
|
This issue was discussed in a meeting.
View the transcriptIssue 875 need role for fieldeset/legend<jamesn> #911 jamesn: so yes, we need to add something mck: this is a lot like label role in that it removes the need for aria-labelledby and would affect name calc for groups if it's present, right? jongund: yes jamesn: when we were thinking about this before, we said we would expand the caption role... mck: did we add a caption role? joanie: it covers HTML caption and figcaption <jamesn> https://github.com/w3c/aria/wiki/Plans-regarding-role-parity#specific-role Bryan: from a grouping perspective, it'd implicitly reference the caption jamesn: is there any reason we can't use caption for legend as well? Bryan: can't think of one mck: looking at current editors draft... <jamesn> caption <jamesn> On-screen descriptive text for a figure or table in the page. <jamesn> Authors SHOULD reference the element with role caption by setting aria-describedby on the figure or table. joanie: we need a nice way to connect the caption to the element it's describing, this will cause an accessible relationship to be formed mck: i thought that was implicit? joanie: i've seen captions that are longer than what you want for an accname mck: if the caption is sometimes providing the name (or description)... well this is a little off topic ... real issue is can we do this for group? if purpose is to provide a name, we have to revisit -describedby Stefan: currently, readers like JAWS seeing a form, these things are treated like regions. if we attempt something like this (groups), we may lose that ability to navigate by regions. joanie: Jon is working on a label role. while a caption is a longer thing, the text in a figcaption is shorter, and this is closer to what Stefan was saying. ... i'm wondering if legend could add to label jamesn: that makes sense, when you look at legend mapping, it maps to label in APIs. so having the legend relate to the fieldset makes a lot of sense jongund: accname calc would be different mck: captions go inside and labels go outside what they label jongund: right ... there's also certain behaviors expected Bryan: behaviorally, if legend is the description ... that information is tacked on to something. it's not the way you typically think of a name <Devarshi> Isn't Legend the 'group' label for the fieldset? jamesn: bringing this back, Jon currently has a legend role being defined. we have 3 potential options ... a legend role, a label, or a caption ... is that a fair summary? mck: if we reuse caption, do we need the relationship? jamesn: yes mck: I thought the point was that we didn't need to explicitly define? jamesn: so if you had caption... you need to have a relationship. mck: a caption labels its closest ancestor... right? jamesn: if we're doing it with aria, does it have to be a descendent relationship? mck: well if we're talking about role parity... this might be confusing for authors Bryan: aria-labelledby already works like that, Jon is saying the legend would be recognized by the group it's in ... but what if they put a group with a mixture of elements like radios etc? what gets the label? mck: so we'd have to make it clear to use the same approach as in HTML ... it's possible to create conflicts. ... or at least might be redundant jamesn: why are we trying to mimic the HTML structure? isn't the point to allow role parity w/o enforcing the same structure? jongund: a lot of times, people are fixing stuff. most stuff out there is made out of divs and spans mck: the driver of HTML parity has been web components and virtual dom nodes etc. jamesn: so... why would we create something where a legend has to be a child of a group? rather than specifying what the relationship is? mck: the legend role isn't revealed from an a11y standpoint - it's a label. if you're pointing at it with -labelledby, then why make it a legend? jamesn: right? So why not make it a label mck: or any role? jongund: the main advantage of my proposal is an auth technique that doesn't require labels <jamesn> https://www.w3.org/TR/html-aam-1.0/#details-id-84 jongund: if aria is bigger than just html, this provides a group label with visible text in an easy way ... it simulates the features of an HTML5 legend element ... so if role=legend is on something and it's not descendent of a group, and not ref'd, it does nothing Bryan: i understand the value from parity perspective, but it's the same from an accname perspective mck: conceptually, the algorithm is similar. so if you have a fieldset, its browsers are already calculating it's accname from the legend? ... what jamesn was proposing was spec'ing out more flavors Bryan: but we don't have a legend role jamesn: which is what the PR is attempting to do ... straw poll: 3 options ... legend role, expand caption role, or use label role <mck> +1 for legend role jamesn: +1 for legend role? <jongund> +1 <jamesn> +1 <HarrisSchneiderman> +1 <melanierichards> +1 <jemma> +1 <mck> +1 for bryan on legend role too <Stefan> +1 <pkra> +1 <Devarshi> +1 jamesn: do i need to do the others? no i don't think so ... any other +1's? joanie: 0 for all ... i need to do some more thinking <Stefan> +1 for label as alternative jamesn: joanie, can you look at the PR and add some comments then? all else, put comments online on PR |
|
While I still don't understand why we cannot use the From an implementation-in-browsers standpoint, I don't think From an AT point of view, I also think |
|
@joanmarie Where it will make a difference is the in the accessible name calculation. The LEGEND role will be used to label groups as a descendant element, where LABEL will be used to label controls and widgets through encapsulation. If we used LABEL for both it could lead to unexpected accessibility problems when there were authoring errors and complicate accessible name calculation for browser developers. |
|
@jnurthen |
|
Regarding:
I find "Although this may... this is used in content" a bit vague. I assume the first "this" is "legend". I assume the second "this" is the "the legend". So what about:
Or something like that. |
|
@joanmarie I made the suggested edit on the definition of encapsulation |
|
note - I think we might want to expand legends applicability in future (not as part of this PR). I see no reason in the future we shouldn't be able to use legend to label any of the landmark or window roles. Again - this is not a comment for this PR. I'll open a new issue for this. |
|
resolves #875 |
|
@jnurthen I have cleaned up the conflicts with the label role, so this pull request should be ok for merging |
This issues is about fieldset parity, but the actual html5 fieldset element is handled easily be the group role. The main issue is the corresponding legend element. This pull request defines a legend role that can be used to provide an accessible name to a group role.
Preview | Diff