You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 previousdiscussions, 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:
Implement a native <table> instead of <div>s to organize Squares
Turn the next player status <div> into an ARIA live region by adding aria-live="polite" and aria-atomic="true".
Insert the word "empty" as screen-reader-only inner text to buttons that have not been selected yet.
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.
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!
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.
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!
The text was updated successfully, but these errors were encountered:
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:
<table>
instead of<div>
s to organize Squares<div>
into an ARIA live region by addingaria-live="polite"
andaria-atomic="true"
.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
<table>
instead of<div>
s.<table>
structure<table>
structure.<table>
structure.<table>
structure.<button>
markup to include rendering an sr-only "empty" string when no state is set.External code samples
Next steps
If you see anything that I've missed, please let me know and I'll try to respond ASAP!
The text was updated successfully, but these errors were encountered: