Difference between revisions of "Accessibility 101"

From perpendicular angel knowledgebase
Jump to navigation Jump to search
Line 8: Line 8:
* [https://www.invisionapp.com/blog/designing-for-inclusivity/ Designing for Inclusivity: How and Why to Get Started] by Allison Shaw at the Invision Design Blog
* [https://www.invisionapp.com/blog/designing-for-inclusivity/ Designing for Inclusivity: How and Why to Get Started] by Allison Shaw at the Invision Design Blog
* [https://exclusive-design.vasilis.nl Exclusive Design] by Vasilis van Gemert is a thesis describing what design would be like if we designed not inclusively, but exclusively for people with disabilities. It's a long read, but covers a lot of ground about our current assumptions.  
* [https://exclusive-design.vasilis.nl Exclusive Design] by Vasilis van Gemert is a thesis describing what design would be like if we designed not inclusively, but exclusively for people with disabilities. It's a long read, but covers a lot of ground about our current assumptions.  
[https://medium.com/the-u-s-digital-service/mythbusters-guide-to-accessibility-92ccd88655c6#.b2qtwlpuf Mythbuster's Guide to Accessibility] by the US Digital Service outlines myths about accessibility that affect all technologists:
* Myth: Government accessibility is harder than it is in the private sector. Reality: Accessibility is the same inside and outside the government.
* Myth: Accessibility requires very specific implementations. Reality: Content is accessible when it can be used by users with a disability, period. There are many ways to achieve this. Following a particular implementation pattern is not necessary to achieve accessibility.
* Myth: It's possible to build something that's 100% accessible. Reality: no product is perfect by any metric.
* Myth: It's easy to treat accessibility as an afterthought. Reality: Designing for accessibility from the beginning is way easier.
* Myth: Implementing accessibility can only be done by 10x Rockstar Ninja Guru A-Player Front-End Engineers. Reality: Accessibility is straightforward for mid-level developers.
* Myth: Testing can be done without consulting assistive technologies or users with disabilities. Reality: The only way to ensure that users with a disability get a comparable experience is to test with them and the tools they use.
Myth: Text-only versions of your content are accessible. Reality: "Separate but equal" accommodations are a lose-lose.


==Design considerations==
==Design considerations==

Revision as of 12:45, 28 December 2019


These are the things you need to know to get started.

Mythbuster's Guide to Accessibility by the US Digital Service outlines myths about accessibility that affect all technologists:

  • Myth: Government accessibility is harder than it is in the private sector. Reality: Accessibility is the same inside and outside the government.
  • Myth: Accessibility requires very specific implementations. Reality: Content is accessible when it can be used by users with a disability, period. There are many ways to achieve this. Following a particular implementation pattern is not necessary to achieve accessibility.
  • Myth: It's possible to build something that's 100% accessible. Reality: no product is perfect by any metric.
  • Myth: It's easy to treat accessibility as an afterthought. Reality: Designing for accessibility from the beginning is way easier.
  • Myth: Implementing accessibility can only be done by 10x Rockstar Ninja Guru A-Player Front-End Engineers. Reality: Accessibility is straightforward for mid-level developers.
  • Myth: Testing can be done without consulting assistive technologies or users with disabilities. Reality: The only way to ensure that users with a disability get a comparable experience is to test with them and the tools they use.

Myth: Text-only versions of your content are accessible. Reality: "Separate but equal" accommodations are a lose-lose.


Design considerations

14 easy ways to make your website more accessible by Carl Cahill and Joss Cook cover:

  1. Remember alt text
  2. Consider animations carefully
  3. Think about other languages (especially around line heights)
  4. Keep the writing straightforward
  5. Use simple colors and shapes
  6. Empower the user
  7. Offer multiple options
  8. Offer customizations
  9. Think about tab order
  10. Don't forget about bots
  11. Get the right line length and amount of text
  12. Avoid anxiety-inducing prompts
  13. Add in verifications and checks
  14. Confirm the end of a user journey

It is not coincidental that these are all usability concerns as well.

Developer considerations

Common Accessibility Mistakes and How To Avoid Them by Ben Robertson outlines four of his own principles for developing accessible websites.

  1. Web Design is more than graphic design
  2. Be ASAP: As Semantic As Possible
  3. Websites should look good naked
  4. Talk to your computer (Use ARIA attributes)

It also outlines common accessibility mistakes:

  • Missing page titles
  • Poor heading structure
  • Link text should tell where or what a user is clicking on
  • Inputs missing a <label>
  • CSS Grid / Flexbox: visual reordering sets a mismatch between logical ordering and visual ordering
  • Missing or poor alt attributes for images
  • Removing focus outlines
  • Missing keyboard functionality
  • Hiding things the wrong way

Paint the Picture, Not the Frame: How Browsers Provide Everything Users Need by Eric Bailey on A List Apart outlines some major browser functionality that is sometimes recreated by developers, such as a scroll-to-top pattern, scrollbar designs, scrolling, highlighting, text resizing, high-contrast themes, moving the focus, the clipboard, and browser history, that really probably shouldn't be messed with unless you're going to be incredibly thorough and consider a wide array of inclusive use cases.