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

Clarify li element role allowances #410

Merged
merged 16 commits into from
May 31, 2023
Merged

Conversation

scottaohara
Copy link
Member

@scottaohara 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 scottaohara added the needs implementation commitment Cannot merge into spec until implementations in conformance checkers has been confirmed. label Mar 27, 2022
@scottaohara scottaohara changed the title Update index.html Revise li element allowances Mar 27, 2022
@scottaohara scottaohara marked this pull request as ready for review March 27, 2022 22:45
@scottaohara
Copy link
Member Author

cc @stevefaulkner @patrickhlauke please review

@scottaohara scottaohara added the needs changelog entry once 2 implementations land, we can merge and note it in our changelog. label Apr 4, 2022
@scottaohara scottaohara changed the title Revise li element allowances Clarify li element role allowances Apr 6, 2022
@stevefaulkner
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>

@mitchellevan
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>

@mitchellevan
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)

@scottaohara
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.

@mitchellevan
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 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 scottaohara removed the needs changelog entry once 2 implementations land, we can merge and note it in our changelog. label May 31, 2023
@scottaohara scottaohara merged commit f7ed5ff into gh-pages May 31, 2023
@scottaohara 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Be more percise with allowed roles on the li element
4 participants