Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

need role for label #876

Closed
jnurthen opened this issue Jan 9, 2019 · 12 comments
Closed

need role for label #876

jnurthen opened this issue Jan 9, 2019 · 12 comments
Assignees
Milestone

Comments

@jnurthen
Copy link
Member

jnurthen commented Jan 9, 2019

per plans for role parity need a role for equivalent to <label> in HTML

@css-meeting-bot
Copy link
Member

css-meeting-bot commented Feb 14, 2019

The ARIA Working Group just discussed Issue 876.

The full IRC log of that discussion <jongund> https://raw.githack.com/jongund/aria/issue876-role-label/index.html#label
<MarkMcCarthy> jongund: this should be updated code. I went through roles related to encapsulation based on HTML5
<jamesn> github: https://github.com//issues/876
<MarkMcCarthy> ... I changed the language a little bit, but the big issue is defining what the list of roles would be and how to get an acc name to them
<MarkMcCarthy> ... there's 30-40 different roles, take a look
<MarkMcCarthy> mck: i still think there needs to be a way to represent this for tables, something equivalent like encapsulation
<MarkMcCarthy> ... especially with all the tools that parse our spec
<MarkMcCarthy> jongund: i agree
<jamesn> q+
<MarkMcCarthy> jongund: there should be something in the table for roles that can be labelled through encapsulation
<MarkMcCarthy> jamesn: this is way more than I expected based on last time
<MarkMcCarthy> jongund: i thought it'd be a small list too, but then you have to look at the principles and what HTML does
<MarkMcCarthy> jamesn: things like a document or an alert...
<MarkMcCarthy> mck: or buttons, maybe there are some things to throw out
<MarkMcCarthy> jongund: I'm happy to take some things out if necessary
<MarkMcCarthy> mck: anything that's a structure has to fall out of here
<MarkMcCarthy> jamesn: some things should have further discussion, but let's start with a smaller list first and add more later
<MarkMcCarthy> ... a small list going into production first would be better
<MarkMcCarthy> mck: is an aria-button like an input type or element? semantically it's equivalent to both?
<MarkMcCarthy> carmacleod: yeah, it's weird
<MarkMcCarthy> jamesn: let's take out button and add it back if we want to
<MarkMcCarthy> mck: combobox is weird, since it's complex
<MarkMcCarthy> carmacleod: but it needs a label
<MarkMcCarthy> jongund: the question here is what makes sense from an authoring standpoint
<jamesn> q?
<jamesn> ack me
<carmacleod> List of labelable elements in html: http://w3c.github.io/html/sec-forms.html#labelable-element
<MarkMcCarthy> jongund: one of the things this does is let people have a visible label. so it's probably more useful for combobox than checkbox
<MarkMcCarthy> jongund: I don't have to worry about IDs, or aria-labels or -labelledby
<MarkMcCarthy> jamesn: I'm happy to hear either way on combobox
<MarkMcCarthy> ... let's go through a smaller list next week?
<MarkMcCarthy> JamesCraig: I think it's fine for any form control, but if we decide to keep structures it's possible to have some implementer impcat
<MarkMcCarthy> s/impcat/impact
<MarkMcCarthy> jamesn: that sounds like a good comment. I'd like to limit to form elements and add other useful things later
<CurtBellew> I'd like to understand why "list" wouldn't be on this list
<MarkMcCarthy> jongund: i'll whittle down the list and we can discuss next week
<MarkMcCarthy> CurtBellew: I can wait til next week. I've had a question on that for a while but happy to wait
<MarkMcCarthy> JamesCraig: one more thing, where would encapsulation stop?
<MarkMcCarthy> ... that's something we need to consider
<MarkMcCarthy> ... i.e. can i walk up the ancsestor chain, do i encounter anything that'd conflict?
<MarkMcCarthy> jongund: that'd be in ACCNAME I think
<MarkMcCarthy> ... but you're right, that has to be defined
<MarkMcCarthy> zakim, take up item 3
<Zakim> agendum 3. "ARIA Spec could be more flexible when elements with “nameFrom:author” are left unlabeled by the author" taken up [from jamesn]

@css-meeting-bot
Copy link
Member

The ARIA Working Group just discussed Label role.

The full IRC log of that discussion <jamesn> topic: Label role
<melanierichards> jongund: I created 4 groups of widget roles and put it in the PR. I thought it would make it easier to see different options
<jamesn> github: https://github.com//issues/876
<melanierichards> jongund: 1st group (missed), 2nd is where native label is helpful, checkbox and radio, 3rd and 4th groups encapsulation not as useful
<melanierichards> jongund: main advantage from authoring standpoint is not having to add IDs in order to label things
<melanierichards> mck: the probability that there isn't other junk in there that you don't want included in the name...our original goal here was role parity and this might be an extension of functionality. Not sure if this is part of the slow, careful extension idea
<melanierichards> jamesn: I would say tree and treegrid would be part of that
<melanierichards> mck: tree, treegrid, grid should go to last group of widgets you have
<melanierichards> mck: I'm a little nervous about combobox still
<melanierichards> james: me too
<melanierichards> mck: listbox is a slam dunk, that's easy, same with spinbutton...combo, I feel it should be in 4th group
<melanierichards> jamesn: I'd like to see it in the first list but it may cause pain to put it there
<melanierichards> mck: yeah, I think we need to resolve the other open combobox naming issue first
<pkra> bye
<melanierichards> jamesn: are you ok with those changes and want to bring it next week?

@mbrookes
Copy link

mbrookes commented Apr 23, 2019

I looked at the associated PR that closes this issue, but I don't see HTML list items included in the list of html elements this applies to.

How does one provide a label that is part of the list structure, but distinct from the list items? Since only <li> is a valid child of a list, the logical solution would be: <li role="label">List section label</li> (following the <li role="separator" /> syntax), for example:

<ul aria-label="shopping list">
  <li role="label">Bakery</li>
  <li>Bread</li>
  <li>Croissants</li>
  <li role="label">Fruit</li>
  <li>Apples</li>
  <li>Grapes</li>
  <li>Bananas</li>
  [...]
</ul>

Here is a practical example of where this would be useful: https://material-ui.com/demos/lists/#pinned-subheader-list

If there is already a semantically correct and ARIA compliant / accessible way to achieve this, then apologies, and please let me know.

@jnurthen
Copy link
Member Author

@mbrookes looks like a group in a list to me http://w3c.github.io/aria/#list

@mbrookes
Copy link

@jnurthen Thanks, but I still don't see how one provides a syntactically correct visible label, whether items are grouped or not. Is there a practical example you could point me to? Thanks!

@jongund
Copy link
Contributor

jongund commented Apr 24, 2019

@mbrookes The example you providing is related to grouping labels, so there needs to be a grouping role:

<ul aria-label="shopping list">
  <li>Bakery
    <ul aria-label="Bakery">
      <li>Bread</li>
      <li>Croissants</li> 
    </ul>
  </li>
  <li>Fruit
     <ul aria-label="Fruit>
       <li>Apples</li>
       <li>Grapes</li>
       <li>Bananas</li>
     </ul>
  </li>
  [...]
</ul>

@mcking65
Copy link
Contributor

mcking65 commented Apr 25, 2019

@jongund commented:

@mbrookes The example you providing is related to grouping labels, so there needs to be a grouping role:

<ul aria-label="shopping list">
  <li>Bakery
    <ul aria-label="Bakery">
      <li>Bread</li>
      <li>Croissants</li> 
    </ul>
  </li>
  <li>Fruit
     <ul aria-label="Fruit>
       <li>Apples</li>
       <li>Grapes</li>
       <li>Bananas</li>
     </ul>
  </li>
  [...]
</ul>

@mbrookes, @jongund, while technically correct, I'm having a hard time picturing how it would help me as a user. If I'm reading the page sequentially, I'm going to hear the labeling item twice, first when I read the fruits list item, then again when I start reading the nested list of fruits. That would get pretty annoying, especially if the list items are more than a single word.

In circumstances where the user might jump from nested list to nested list, there is a possibility it could be helpful, but it's not clear to me it be worth the trade-off, especially since it would be almost as easy to jump from parent list item to parent list item.

At any rate, for a first go at the label role, this use case would not fit in our current scope of simple parity with HTML because the HTML label element does not support this type of useage.

@mbrookes
Copy link

So, am I understanding correctly that there is no syntactically correct way to label groups in lists in a way that that works both visually and with screen readers?

@jongund
Copy link
Contributor

jongund commented Apr 25, 2019

@mbrookes grouping labels need some type of semantic structure to indicate the grouping relationship. It seems like from your code example you want more of a heading than a group label (e.g. here is the next section of related to bakery and another on fruit, so that code would be:

<h2>Shopping list</h2>
<h3>Bakery</h3>
<ul>
   <li>Bread</li>
   <li>Croissants</li> 
</ul>
<h3>Fruit</h3>
<ul>
    <li>Apples</li>
    <li>Grapes</li>
    <li>Bananas</li>
</ul>
[...]

@mbrookes
Copy link

Please could you wrap the code sample in ```s. Thanks. :)

@jongund
Copy link
Contributor

jongund commented Apr 25, 2019

@mbrookes sorry, I fixed the sample

@mbrookes
Copy link

Thanks. In this example the list isn't a list though. It's two lists. 🤷‍♂️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants