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.

Sign up for GitHub

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

Jump to bottom

Needs to be a requirement for clearly labeled semantic landmarks #80

Open
rachaelbradley opened this issue May 20, 2024 · 3 comments
Open

Needs to be a requirement for clearly labeled semantic landmarks #80

rachaelbradley opened this issue May 20, 2024 · 3 comments
Labels
Guideline Subgroups: Distinguishable sections

Comments

@rachaelbradley
Copy link
Contributor

rachaelbradley commented May 20, 2024 •
edited
Loading

"Sections are visually and programmatically distinguishable” outcome is certainly relevant, as a screen reader user and accessibility tester, I also believe there needs to be a requirement for clearly labeled semantic landmarks which separate and contain distinct page content. Examples include Header, Main Navigation, Breadcrumb Navigation, Main content, Aside, Footer, etc…

Landmarks are well supported in most browsers, are easy to implement using modern programming languages such as HTML 5, ARIA, and Javascript, provide great benefits to assistive technology users, and are easy to test for."

Issue submitted via public-agwg-comments email. Respond to email with update when addressed.
@detlevhfischer
Copy link

detlevhfischer commented May 22, 2024 •
edited
Loading

there needs to be a requirement for clearly labeled semantic landmarks

"Programmatically distinguishable" already impies that where more than one instance of a landmark (say, nav) is used on the page, it should be able to differentiate these instances programmatically, which in practice means labelling them (e.g. with aria-label or aria-labelledby) - so I think this point is covered by / implict in the chosen wording. In other cases, where a landmark is used just once (say, main or footer) the role exposed would arguably be sufficient for programmatic distinction.

@scottaohara
Copy link
Member

i agree there should be a more overt requirement for landmarks, but similar to @detlevhfischer I'd stop short from saying all of them must be named, particularly when there are only single instances of these landmarks on a page.

additionally, i'd submit that any requirement for landmarks would need to acknowledge that not all pages 'need' landmarks (e.g., there are plenty of terms of service pages, or very simple web pages where there are no visually distinct header/footer sections (if they exist at all) and requiring all pages to be wrapped in a main element can be a bit heavy handed. for instance,

<html lang=en>
  <main>
   <h1>Hello world</h1>
   <p>There's a main element here so that you know this scant bit of content is the primary content of this web page.</p>
  </main>
</html>

note that i'm not suggesting the OP of this issue was saying the above should be a requirement - but i've had enough conversations with developers that get confused over accessibility checker best practices suggesting that all page content be wrapped in landmarks - misunderstanding that as a "requirement" - that I think it's important to definitively state when landmarks are necessary, vs not, and finally how overuse of landmarks can also be detrimental to their purpose.

@detlevhfischer
Copy link

detlevhfischer commented Jun 3, 2024 •
edited
Loading

I just noticed that the current list of outcomes seems to be missing the "bypass blocks" need of 2.4.1 (including skip links for sighted keyboard users), and created a new issue for bypass blocks which would be an interesting one to work through - or is the omission of "Bypass blocks" in WCAG 3 a conscious decision? (Or maybe I just didn't spot it...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Guideline Subgroups: Distinguishable sections
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@scottaohara @detlevhfischer @rachaelbradley