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

Question regarding <aside> conditional mapping #512

Open
sivakusayan opened this issue Oct 30, 2023 · 6 comments
Open

Question regarding <aside> conditional mapping #512

sivakusayan opened this issue Oct 30, 2023 · 6 comments

Comments

@sivakusayan
Copy link

Blink got a bug report regarding the aside mapping a while back from an NVDA user. They were pointing out that the sidebar in this WordPress article wasn't exposed as a landmark.

This happens because the sidebar is an <aside> element nested inside both a <section> and an <article>, and has no accessible name. I want to call it an authoring error and say that Blink is technically to spec here, but two things make me hesitate:

  • It's been around 1.5 years since the original PR has been merged, and the Gecko/WebKit implementations don't seem to be done yet. If Blink keeps this behavior, it could be seen as an interop issue or feel buggy, since the average user/developer probably isn't aware that the AAM exists at all and is unfamiliar with this conditional mapping.
  • The structure of the WordPress article feels like a natural pattern many developers might take (well, aside from the single <section> element that doesn't really seem to be sectioning anything off...). If a developer writes something like the code below, they might expect it to just work with assistive technology since it's relatively semantic HTML.
<article>
    Some super cool article!
    <aside>Some sidebar with lots of cool stuff</aside>
</article>

Can I get advice on whether Blink should prioritize interoperability or conforming to the spec in this case? Again, I'm tempted to ask for the bug to be closed as expected behavior, but the thing that makes me hesitate is that a screen reader user brought up this issue, the HTML listed above feels very natural to write, and we don't have browser implementations yet.

@scottaohara
Copy link
Member

The issue is that the markup of that page is also demonstrative of why the PR/change was made. Use of the aside element within a section, within an article, within a main. I can see why one could consider this content as a complementary landmark - but its lack of name and the manner in which it is nested in the other structural elements is demonstrative of why the original HTML AAM issue was open, as use of an aside in this way is also commonly done and not meant to be treated as a landmark. Additionally, the markup of that page defies stricter versions of best practices that the PR even attempted to soften. E.g., prior to the ARIA spec update I made in w3c/aria#1779, many would have stated that the fact that the complementary is not a sibling to the main was not following the spec.

Rather, I would submit that what needs to be done here is the issue needs to be redirected at the Wordpress site, not the browser - the site which specifically notes, btw:

*Note that WordPress Playground is currently undergoing accessibility testing

If they want to keep this markup as is, then they need to give the aside an accessible name, and then it will be a complemanry landmark.

But per the point that it's been 2 years since the original PR was made, and a bit less since it was merged - there are bugs open against webkit and firefox to make this change.

cc @cookiecrook, @jcsteh

@sivakusayan
Copy link
Author

sivakusayan commented Oct 31, 2023

I appreciate the response - this almost got reverted and I wasn't exactly sure what to do here, so glad I asked first.

I still do worry that this is very niche behavior that not many people might know about, but a better way of distilling this information might be through MDN's <aside> article , which doesn't seem to be updated for this change (I can take a stab at that later).

@scottaohara
Copy link
Member

Agreed. The MDN article on role=complementary should be updated as well.

if you do work on updating the MDN docs, I'd be happy to review / assist if need be.

@cookiecrook
Copy link
Collaborator

@sivakusayan
Copy link
Author

I tweaked the WPT if either of you want to review.

webkit-commit-queue pushed a commit to joone/WebKit that referenced this issue Nov 10, 2023
https://bugs.webkit.org/show_bug.cgi?id=235065
rdar://problem/87391915

Reviewed by Tyler Wilcock.

This change assigns a generic ARIA role to <aside> elements when they are nested
within <aside>, <article>, <section>, or <nav> elements, aligning with the spec
(https://w3c.github.io/html-aam/#el-aside).
This follows the discussion in w3c/html-aam#512

Additionally, it introduces a check to return LandmarkComplementary when an <aside>
tag has an explicit accessible name.

* LayoutTests/imported/w3c/web-platform-tests/html-aam/roles-contextual-expected.txt:
* LayoutTests/imported/w3c/web-platform-tests/html-aam/roles-contextual.html:
* Source/WebCore/accessibility/AccessibilityNodeObject.cpp:
(WebCore::AccessibilityNodeObject::determineAccessibilityRoleFromNode const):

Canonical link: https://commits.webkit.org/270509@main
@joone
Copy link

joone commented Nov 13, 2023

I'm trying to fix this problem in Firefox: https://phabricator.services.mozilla.com/D193495

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

No branches or pull requests

4 participants