docs(a11y): add accessibility guidelines page

[dancormier]

I think our documentation could benefit from a standalone accessibility-focused page. Consider this a big ol' work in progress atm.

TODO

• [ ] Complete "Overview" section
• [ ] Complete "Accessibility testing" section
• [ ] Complete "Structural markup" section
• [ ] Complete "Using WAI-ARIA" section
  • [ ] Change this heading to be more friendly to those not familiar with the world of a11y
• [ ] Complete "Color contrast" section
• [ ] Complete "Additonal resources" section
• [ ] Consider cross-linking opportunities
• [ ] Consider level of detail per section necessary

cc @CGuindon @shainanigans

[netlify[bot]]

✅ Deploy Preview for stacks ready!

Name	Link
🔨 Latest commit	6e24ddc072e3a623e62fdca1f7e9828aa5e947fa
🔍 Latest deploy log	https://app.netlify.com/sites/stacks/deploys/62ffbfe9413f88000879e46f
😎 Deploy Preview	https://deploy-preview-1047--stacks.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[shainanigans]

Looks good @dancormier !

If you're having a section on color contrast, would it also make sense to cover some other broad accessibility categories of things to look out for? For example:

• Screen reader accessibility
• Focus and keyboard navigation / interactive components
• Language (don't use directional instructions because screen readers don't behave that way, don't use action-descriptive language like "click" or "hover" because it excludes keyboard users, etc)

Some of these ideas I've stolen from Boostrap's and Material's guides if you want to check them out and haven't already :)

Will structural markup also include semantic elements, or is that a different category?

[dancormier]

Looks good @dancormier !

Thank you! And thanks for giving it a look!

If you're having a section on color contrast, would it also make sense to cover some other broad accessibility categories of things to look out for? For example:

* Screen reader accessibility

Can you give me a rough idea of what we'd mention in this section?

* Focus and keyboard navigation / interactive components

Yes, this section should be added. Good call!

* Language (don't use directional instructions because screen readers don't behave that way, don't use action-descriptive language like "click" or "hover" because it excludes keyboard users, etc)

I can go either way on language guidelines being included in this page. I'm trying to keep this page scoped to the technical approaches to accessibility but I see it worth while to mention language somewhere. Maybe as a "Content" section?

Some of these ideas I've stolen from Boostrap's and Material's guides if you want to check them out and haven't already :)

I've poked into a few other design systems' accessibility-focused pages but only really skimmed them. There's for sure more opportunity to lift some inspiration.

Will structural markup also include semantic elements, or is that a different category?

Yeah, "structural markup" is probably the wrong heading label. I imagine it'll be a section broadly outlining how markup should be written for the greatest accessibility.

[shainanigans]

Screen reader accessibility

Maybe some of this doesn't make sense for Stacks documentation, but I'm not sure where else we might want to put it.

• Aria roles like aria-hidden, aria-expanded, aria-live... possibly more that aren't coming to mind :) Unless this is already covered by your WAI-ARIA section?
• How the order of elements in DOM is how a screen reader reads content (regardless of CSS styling to make it different)
• Link to the screen reader visibility class
• Writing good aria labels or screen reader text (this could be the language part I mentioned)
• Hiding visually hidden elements from screen readers too
• Heading order, with links to the classes to visually change the style of headings as needed

[dancormier]

Closing in favor of https://github.com/StackExchange/Stacks/pull/1670