Skip to content

Fix: Accessibility roles and aria labels #2304

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

Merged
merged 11 commits into from
Nov 29, 2023
Merged

Conversation

jhildenbiddle
Copy link
Member

@jhildenbiddle jhildenbiddle commented Nov 15, 2023

Summary

Improves site accessibility by assigning proper roles and aria attributes to elements by implementing all non-breaking recommendations from #2295.

Note: You may have to unmute the videos below to hear VoiceOver audio.

Before

  • Landmark elements are not properly identified
  • Search results not identified
2295-before.mp4

After

  • Landmark elements are properly identified
  • Search results are identified
2295-after.mp4

Related issue, if any:

#2295

What kind of change does this PR introduce?

Accessibility
Fix
Feature

Does this PR introduce a breaking change?

No

Tested in the following browsers:

  • Chrome
  • Firefox
  • Safari
  • Edge

Copy link

vercel bot commented Nov 15, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
docsify-preview ✅ Ready (Inspect) Visit Preview 💬 Add feedback Nov 17, 2023 1:28pm

Copy link
Member

@trusktr trusktr left a comment

Choose a reason for hiding this comment

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

The changes look good for non-ecosystem-breaking changes. Are there any other elements that could possibly need aria labels?

@jhildenbiddle
Copy link
Member Author

jhildenbiddle commented Nov 29, 2023

Are there any other elements that could possibly need aria labels?

See #2254.

There is another issue I'd like to resolve, but I don't think it will be possible without a breaking change...

The hyphens used in our sidebar navigation are rendered as ::before pseudo content. As far as screen readers are concerned, this is content that should be read just like any other content on the screen. For example:

Quick start
- Initialize
- Writing content
- Preview your site
- Manual initialization
- Loading dialog

The result is that links are announced as follows using macOS VoiceOver:

"Link. Quick start",
"Hyphen. Link. Initialize",
"Hyphen. Link. Writing Content."
"Hyphen. Link. Preview your site."

Ideally, the hyphen would don't be announced.

I don't think this is a big deal though, especially if we intend to update our UI in the relatively near future. My preference is to merge these changes without introducing breaking changes and address the hyphen issue when we tackle UI updates.

@jhildenbiddle jhildenbiddle merged commit da43bd7 into develop Nov 29, 2023
@jhildenbiddle jhildenbiddle deleted the 2295-element-roles branch November 29, 2023 18:33
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

Successfully merging this pull request may close these issues.

Accessibility: Assign proper element roles using semantic HTML or role attributes
3 participants