Skip to content

Improvements for screen readers #205

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 1 commit into from
Mar 8, 2021
Merged

Improvements for screen readers #205

merged 1 commit into from
Mar 8, 2021

Conversation

aomarks
Copy link
Member

@aomarks aomarks commented Mar 8, 2021

Did a pass through the home page and docs with voiceover on Safari.

  • Disabled reading of decorative images.

  • Added labels for some images that were missing them.

  • Switched code snippets to <figure> elements. If there's a <figcaption>, as we now have on the homepage, it reads it nicely, otherwise it seems to read the same. Maybe we can add captions to our other code snippets if we have time. I think it should help with navigation though, (i.e. "skip this figure" command, vs a div where there's no semantic encapsulation).

Fixes #158

@github-actions
Copy link

github-actions bot commented Mar 8, 2021

A live preview of this PR will be available at the URL(s) below.
The latest URL will be appended to this comment on each push.
Each build usually takes around 7 minutes, and will 404 until finished.

https://pr205-3a1468e---lit-dev-bvxw3ycs6q-uw.a.run.app/

<div class="homeExample">
<h4>Hello World</h4>
<figure class="homeExample">
<figcaption>Hello World</figcaption>
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we allow both a heading and caption? The heading would be the title of the example, and the caption could be equivalent to the alt-text with longer content?

It looks like headings in figures are excluded from the outline algorithms (which screen readers might sort-of follow? afaik, nothing really implemented the HTML outline algorithm correctly) so I'm not sure if the heading should be inside or before the figure in that case.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah interesting, I guess we could put "Code example" in the <figcaption>, render if off screen somewhere so that it's not shown visually but still reads to screenreaders, and then keep the "Hello World" in a heading? Will play around with that for a followup.

Copy link
Contributor

Choose a reason for hiding this comment

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

For the most part, we don't have titles on our examples. Occasionally, we have a filename attached to an example.

Generally the code example is described in the accompanying text. We use alt-text to describe stuff that the screen reader can't read, but it can read the code example. I think the caption "Code example" gives the information that's conveyed by formatting to the sighted reader.

(I don't know how you'd do this, but an additional cool perk would be if we could provide an optional title/filename that gets integrated into the figcaption. i.e., so looking at the page you see "my-element.js" above the example, but the screen reader would say, "Code example: my-element.js")

I wouldn't spent more than about 10 minutes thinking about that, though. I think "Code example" is good. With the obvious caveat, I Am Not An A11y Expert.

@aomarks aomarks merged commit e6a3c5e into master Mar 8, 2021
@aomarks aomarks deleted the screenreader branch March 8, 2021 23:08
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.

Screenreader pass through (a11y)
3 participants