-
Notifications
You must be signed in to change notification settings - Fork 27
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
Comments
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:
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 |
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 |
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. |
I think this needs an update to the following WPT computedrole test: https://github.com/web-platform-tests/wpt/blob/master/html-aam/roles-contextual.html |
I tweaked the WPT if either of you want to review. |
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
I'm trying to fix this problem in Firefox: https://phabricator.services.mozilla.com/D193495 |
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:<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.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.
The text was updated successfully, but these errors were encountered: