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

[html-aam PR 540] Clarify li element role mapping #2212

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

pkra
Copy link
Member

@pkra pkra commented May 23, 2024

Moved from w3c/html-aam#540

edit:
closes #2173
approving reviewers from migrated HTML AAM PR: @smhigley, @cookiecrook, @spectranaut

edit again:
pointing back to the original HTML AAM PR that this is one is clarifying - w3c/html-aam#476

scottaohara and others added 5 commits April 4, 2024 13:40
The intent of this text change is to clarify that a list item that is still a child of a list, but has intervening generic elements should still be exposed as a listitem.

e.g.,

```
<li>with no list ancestor = generic</li>

<ul>
  <div> <!-- invalid html, but SHOULD be ignored since generic  -->
    <li> since this has 'accessibility parent' of list, it should remain exposed as a list item </li>
  </div>
</ul>
```
Co-authored-by: Valerie Young <[email protected]>
@pkra pkra changed the base branch from monorepo_history--html-aam to main June 12, 2024 19:31
@pkra pkra changed the title [Monorepo] [html-aam PR 540] Clarify li element role mapping [html-aam PR 540] Clarify li element role mapping Jun 12, 2024
@scottaohara
Copy link
Member

scottaohara commented Dec 11, 2024

my manual test results - https://codepen.io/scottohara/pen/LEPRRNd
WPT - web-platform-tests/wpt#49643

scottaohara added a commit to web-platform-tests/wpt that referenced this pull request Dec 11, 2024
@cookiecrook cookiecrook self-requested a review December 12, 2024 23:58
Copy link
Contributor

@cookiecrook cookiecrook left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Though I have no problem with this minor editorial change) I recall a conversation (perhaps with @twilco, @nmlapre, and @jcsteh) that downgrading the orphaned roles had no user benefit, and had implementation cost, so the related WPT tests were rolled back or moved to tentative. I think that means this line should be removed from the spec, too.

@scottaohara
Copy link
Member

scottaohara commented Dec 13, 2024

@cookiecrook that convo definitely happened regarding the use of explicit aria roles that weren’t children of their required parents, but html’s li element contextual role was separate to that. Firefox has been treating an orphan li element as generic for 12 years now.

If Firefox is willing to undo this and then all browsers consistently expose the li element as a list item, even when not within a required ul, ol, menu or role=list parent - then it can become a screen reader’s decision on how to handle these author errors, or not. Maybe this is even the way Firefox can resolve the failing tests for <ul><div><li>not a list item in firefox</div></ul> and <ul aria-owns=f></ul><li id=f>not a list item in firefox

@jcsteh
Copy link

jcsteh commented Dec 17, 2024

I came across a case yesterday which would break if we removed the rule for orphaned <li> elements. This also led to the realisation that Chrome sometimes does this too.

data:text/html,<ul style="list-style: none;" role="tablist"><li><button role="tab">foo</button></li><li><button role="tab">bar

If the <li> elements got a role of listitem, this would break the posinset/setsize calculation for the tabs. What's interesting here is that in this case, Chrome excludes the <li> element from the tree. Conversely, if you do this:

data:text/html,<li>foo

Chrome exposes listitem. But if you do this:

data:text/html,<ul role="none"><li>foo

Chrome excludes the <li>. So now I don't know what to think. 😕

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

Successfully merging this pull request may close these issues.

Is the accessibility tree built on the DOM tree, or the flat tree (incl. shadow DOMs)?
4 participants