Skip to content

Improve accessibility of Tutorial code samples #2826

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

Open
31 tasks
jasonwebb opened this issue Mar 11, 2020 · 0 comments
Open
31 tasks

Improve accessibility of Tutorial code samples #2826

jasonwebb opened this issue Mar 11, 2020 · 0 comments

Comments

@jasonwebb
Copy link

This issue is being split out of #78 so that its specific action items can be discussed and tracked without cluttering the more general site-wide accessibility discussion.

Huge shout-out to @frastlin for raising this issue, and to @roblevintennis and others for stepping up to prototype and thoroughly discuss this. I'm really just here to polish and integrate their work into the live site!

Currently, the Tic-Tac-Toe example that readers are guided through on the Tutorial page is difficult or impossible to use by people using screen readers and other assistive technologies.

In previous discussions, some low-impact, high-value accessibility improvements have been identified that would not only provide value for the impacted end-users, but would also start readers (who may also be new developers) off on the right foot by promoting semantic, native markup and simple accessibility best practices as a normal part of the development process.

These changes wouldn't require significant (if any) rewriting of the existing narrative content, and may not even require explicit explanation at all (similar to the current markup). At a high level, there are really only three changes that need to be made:

  1. Implement a native <table> instead of <div>s to organize Squares
  2. Turn the next player status <div> into an ARIA live region by adding aria-live="polite" and aria-atomic="true".
  3. Insert the word "empty" as screen-reader-only inner text to buttons that have not been selected yet.

These changes can be seen in this prototype "Final Result" CodePen here: https://codepen.io/jasonwebb/pen/eYNdbpp?editors=0101

The <table> structure should be pretty self-explanatory, but for the player status live region I wonder if it might be nice to have a very short "tip" box saying something like, "ARIA live regions have their content read out by screen readers whenever it changes so that people using screen readers know whose turn is next!"

To implement these changes, a few adjustments need to be made to some of the step-by-step code samples, which are either on the page directly or hosted externally on CodePen.

I feel like its fine to prototype these new code samples using anybody's CodePen account, but when it comes time for a PR they should probably be handed off to an official ReactJS (or maintainer) account for posterity.

Here are each of the instances I could find throughout the page:

On-page code samples

  • Update on-page code samples to use <table> instead of <div>s.
    • Replace screenshot under Developer Tools section to reflect updated <table> structure
    • Update on-page code sample at the very end of the Lifting State Up section to use <table> structure.
    • Update on-page code sample at the very end of the Taking Turns section to use <table> structure.
    • Update on-page code sample in the Lifting State Up, Again section to use <table> structure.
  • Update on-page code samples for the <button> markup to include rendering an sr-only "empty" string when no state is set.
  • Update the "status" div to be an ARIA live region

External code samples

Next steps

  1. I'll create a fork of the repo on my Github account (done) to try to unify the work to a common location.
    • Open to other ideas! IIRC, we can't work directly on the master repo without permissions, so a forked repo is (I think) the way to go. Happy to be wrong though!
  2. As tasks are actioned by contributors, I can add their username next to the list items above so we all know what is already being worked on.
    • Just drop a comment on this thread to let me know which task(s) you'd like to "own" and I'll add your name.
  3. When the tasks above are completed and accounted for in a unified branch somewhere, a PR will be opened on the master repo to propose integration.

If you see anything that I've missed, please let me know and I'll try to respond ASAP!

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

1 participant