Skip to content

Clarify li element role allowances #410

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

Merged
merged 16 commits into from
May 31, 2023
Merged

Conversation

Image for: Conversation
Copy link
Member

scottaohara commented Mar 27, 2022

Closes #351

This change is to clarify that if an li is a child of a ul, ol, or menu element, and those elements are exposed as a list, then no other role can be specified on the li.

However, if the parent of the li is no longer exposed as a list, or if someone were to write invalid markup and use an li outside of the expected list > listitem markup pattern, then any role should be allowed on the li (so long as the role is a role allowed by the li's parent element)

For instance,

<ul role=table>
  <li role=button>...</li>
</ul>

is not be allowed as a button cannot be a direct child of a table. However, but a role=row on the li would be allowed in this example.

and

<div>
  <li role=paragraph>...</li>
</div>

is invalid HTML, but as the li is not a child of a list element, it should be allowed to have any role.

test cases


Preview | Diff

scottaohara added the needs implementation commitment Cannot merge into spec until implementations in conformance checkers has been confirmed. label Mar 27, 2022
scottaohara changed the title Update index.html Mar 27, 2022
scottaohara marked this pull request as ready for review March 27, 2022 22:45
Copy link
Member Author

cc @stevefaulkner @patrickhlauke please review

scottaohara added the needs changelog entry once 2 implementations land, we can merge and note it in our changelog. label Apr 4, 2022
scottaohara changed the title Revise li element allowances Apr 6, 2022
Copy link
Collaborator

those elements are exposed as a list, then no other role can be specified on the li.

what about
<li role=separator> or <li role=none>

Copy link

what about <li role=separator> or <li role=none>

I support allowing role="none" on <li>. have seen this in the wild, and I don't think we should discourage it:

<ul>
  <li>Bats</li>
  <li class="purely-decorative" role="none"></li> <!-- this list item has no content -->
  <li>Cats</li>
</ul>

I lean against allowing role="separator" on <li>. Disallowing role="separator" would encourage this reasonable structure:

<ul>
  <li>Bats</li>
  <li><span role="separator"></span></li>
  <li>Cats</li>
</ul>
Copy link

Or if we want the rules to be more opinionated (in the software sense), say one of the following:

  • Allow role="none" on empty <li>, disallow otherwise
  • Say role="none" SHOULD NOT be on <li> (but valid reasons may exist)
Copy link
Member Author

scottaohara commented May 11, 2023

that seems reasonable on its surface, but would make the implementation of the rule more complicated. practically one could do aria-hidden=true on the li to achieve the same effect, and not have to have additional checks to the rule to determine not only if it was empty, but if it did have children that they only equated to white space, or themselves had alt="", or aria-hidden=true or role=none/presentation, as applicable to the element and its children, if any.

re:

I lean against allowing role="separator" on <li>.

if that were actually allowed by ARIA/HTML, then it would be a reasonable allowance. Separately I have tested the current reality of how that works with AT, and while it causes some minor breakages depending on the browser/at combo, I have requested that become an allowance in HTML, which would then make it allowed in ARIA, and subsequently this spec. Until then though, there will be no change here on that matter.

Copy link

that seems reasonable on its surface, but would make the implementation of the rule more complicated. practically one could do aria-hidden=true on the li to achieve the same effect

I'm convinced. Thanks for the clear explanation.

scottaohara added Meets 2 implementations req Indicates that a spec change has met the necessary 2 implementations needed to merge. and removed needs implementation commitment Cannot merge into spec until implementations in conformance checkers has been confirmed. labels May 15, 2023
scottaohara removed the needs changelog entry once 2 implementations land, we can merge and note it in our changelog. label May 31, 2023
scottaohara merged commit f7ed5ff into gh-pages May 31, 2023
scottaohara deleted the revise-li-role-allowances branch May 31, 2023 14:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Meets 2 implementations req Indicates that a spec change has met the necessary 2 implementations needed to merge.
4 participants