100 tweets on accessibility

June 20th, 2017 · ~7 minutes

This list was originally posted on Twitter but with Twitter’s future being uncertain, I thought I would bring it here:

Don’t shame users in error messages. It can be seen as playful but also possibly condescending and off putting.
Be careful with text on images, no matter how cool it looks. It can be done correctly but it’s very hard.
Hover effects are nice, but remember that not all users have a mouse/trackpad. Make sure content can be accessible otherwise.
Pa11y is a fantastic tool to automate the basics of accessibility testing.
The hidden attribute can be used to hide an element visually and from screen readers.
A low hanging fruit to figure out if a content flow makes sense is to disable CSS and to see if it looks meaningful.
Connected radio inputs should be gathered within a fieldset, with a legend serving as label for the group.
Be careful with infinite animations, even subtle ones. People with Attention Deficit Hyperactivity Disorder could find them distracting.
Make sure not to present paragraphs that are too long. Some users tend to get lost quickly with huge blocks of text.
Don’t disable zooming. Some people need it to comfortably read your content. Some unusual situations require users to zoom.
About 7 users out of 10 would leave a site when found difficult to use (figure from CAP16).
The autistic spectrum is very wide and a lot of people are affected. Designing straight-forward UI helps tremendously.
Non-decorative images should have alt text. It is read out by screen-readers to provide information about the image content.
If you can provide a night mode, do it. A lof of users prefer browsing in night mode, no matter their vision.
Feel free to change the default browser outline, but make sure to clearly indicate which element has the focus.
A good way to test if your controls are forgiving enough is to use your mouse/trackpad with your other hand.
Fancy layouts are tricky because they can obscure the way content flows. Content hierarchy is very important to do right.
A recent research from @captainsafia shows that non-captioned videos is one of the main accessibility problems faced on the web.
Screen readers do not have to be scary. You can get started using one by trying ChromeVox for Chrome which is very straight-forward.
Having a “skip-to-content” link at the very top of the page helps screen-reader users not to go through your entire header.
About 40 million persons worldwide are blind. Roughly 250 million persons suffer from low-vision (figures from WHO).
Performance is accessibility. People in large regions of the world do not have access to fast internet.
Proper content flow and keyboard navigation also helps power users who want to do things fast and efficiently.
Think about main call-to-actions’ position on screen. Not everybody has a long fingers thumb. Not everybody has two hands available.
Avoid justifying text, especially in large amount, as it makes it harder to read or even confusing for some people.
Use HTML landmarks to help people navigate your document (HTML5 structural elements & role attribute).
Don’t autoplay videos, seriously. If you do, mute them. Videos auto-playing with sound go from annoying to damaging.
“CSS only” solutions—while clever—usually overlook the accessibility aspect of a feature, making them sub-optimal.
Parallax scrolling and heavy animations can cause nausea or sickness. Go easy on them or make it possible to disable them.
Parallax scrolling and heavy animations can cause nausea or sickness. Go easy on them or make it possible to disable them.
The Chrome team maintains an accessibility audit for the Chrome DevTools. Use it, it’s great.
Use clear language. Tone and even humour are important of course, but in the end, copy should be understandable by everyone.
You’ll never have a perfect experience for absolutely everybody, and that’s okay. It doesn’t have to be perfect. Do your best.
Accessibility on the web is a lot about caring about users and not being a bigot. That’s the first step, keep being a great human being! ✨
High color contrast not only helps people suffering from color-blindness but also users browser under sunlight.
As @heydonworks says, accessibility is not about doing more work. It’s about doing the right work. Ideally from the ground up.
Never convey information through color only. Colors definitely bear meaning, but they should be a secondary communication channel.
White space is free. Don’t be afraid to use it.
I like light fonts as much as the next person, but they can be extremely hard to read. Keep them for headlines and large text.
Dialog windows should be closable by clicking outside of them or pressing ESC. It saves people from aiming at the tiny cross.
A good way to ensure sufficient color contrast between two colors is this checker from @leaverou.
Don’t forget the lang attribute on the html element, and on any element in a different language than the rest of the document.
Not all users have to have the same experience on your website. But they should all have access to your content.
Hiding an element while keeping it accessible isn’t super straight-forward. @ffoodd_fr found a bulletproof solution.
Building an accessible product is not a one shot thing. It takes time and care along the lifetime of the project.
Highly animated content should be introduced with a warning to protect people suffering from epilepsy.
The prefers-reduced-motion media query (if supported) comes from OS settings. Here is more info about this media query.
Decorative images should have an empty alt attribute (alt=""). Here is a good decision tree.
The usability of floating labels is debatable. Lack of space, confusing animation, poor contrast, only working for inputs, cropped label…
The tab sequence should be trapped within a dialog window. The inert attribute will soon natively provides that behaviour.
Some people use screen magnifiers to browse the web. Designing for them isn’t too hard, here are good guidelines for screen magnifiers.
Video captions are not only useful for deaf/HoH but also people browsing content in loud areas or without sound (e.g. public transports).
When using “−” as in “minus”, use the − (or −) rather than a dash. Same for × in place of “x”.
JavaScript is not the enemy of accessibility. Actually some patterns can only be made truly accessible with JavaScript.
Using personas can help working with accessibility in mind, as well as encouraging QA to test for it.
Video captions also benefit non-native speakers. Despite my decent English, I watch Netflix with English captions all the time.
I don’t understand why Firefox still runs with this comically thin dotted outline. I can barely notice it.
Roughly 360 million persons worldwide suffer from hearing loss (figures from WHO).
The lack of spacing between lines of text (line-height) usually causes quite important readability issues. Easy to fix though!
It seems uncommon for users to zoom out. Which means, fonts are usually too small on the web. Don’t be afraid to go big(ger)!
Use the <main> element to define your main content section. It should be unique and should not contain layout chunks (header/footer…).
A good way to ensure keyboard navigation is to unplug your mouse or disable your trackpad when testing.
The document outline (hierarchy of headlines) matters. It’s used by certain programs to navigate within a document. Take care of it.
When you feel like bitching about Microsoft and their browser, remember that Edge is by far the most accessible one (see browsers accessibility comparison).
A survey from 2016 shows that one person out of 10 suffers from some sort of color-blindness (could be red/green, blue/yellow or complete).
Don’t use a tabindex value greater than 0. It messes up with the tab order and can be very confusing.
WebAIM’s hierarchy for motivation to accessibility is: Inspire → Enlighten → Reward → Require → Punish → Guilt.
Vocal UI solve a lot of issues but also introduce some. Mute (temporary or permanently) people, and people with a stammer can struggle.
PDF is quite an inaccessible format, and here is a fantastic reminder why PDF are tough to do right.
As @sundress says, web accessibility is not an edge case.
If you are getting started with VoiceOver, this is a fantastic VoiceOver cheatsheet.
All form controls should have an associated label. This is important for screen-reader users to know how to interact with a form.
CSS pseudo-elements’ content is read out loud by screen-readers so be sure it contains relevant information.
In a cross-functional team, everybody can contribute to a more accessible experience. Designers, devs, PM, QA… Everyone. :)
ARIA should not be used as a fix for poor HTML. Start with clean HTML, then enhance with ARIA if necessary.
a11y.css is a clever bookmarklet from @ffoodd_fr using CSS to detect possible accessibility problems.
In the US, 50% of people aged 75+, 25% of people aged 65-74 and 10% of people aged 21-64 suffer from some sort of disability.
Making content accessible and making sure it is should be considered during planning, not as an after-thought.
To know whether an image is decorative or not, ask yourself if content would still make sense would the image be removed.
Be careful with infinite scrolling as it can be problematic for keyboard users. Make it possible to replace it with pagination.
Video is not always the good media to convey content. Ideally, a text transcript should be provided so people can choose their way.
@Heydonworks maintains a collection of in-depth articles to build inclusive components.
Add tabindex=0 to scrollable regions so keyboard users can access them.
Icon fonts are quite bad for accessibility. Better to opt for SVG as it’s an accessible imagery format.
Provide a way to undo destructive actions so they can be (at least temporarily) reversible. Undo usually > confirm.
Many screen-reader users are running on Internet Explorer or Firefox on Windows. Some Safari on iOS.
Footnotes are not super straight-forward to implement correctly. That’s why I wrote about accessible footnotes a while ago.
Toggle buttons should have persistent label. Hat tip to @heydonworks for the example.
Some gestures like tap-and-hold or double clicking can be difficult to perform for users suffering from tremor or tendonitis.
Recent studies show that between 10 and 20% of the world population suffer from sort of disability (temporary or permanent).
Links opening in a new window should be indicated as such (obvious iconography, explanatory ::after pseudo-element…).
As @NeilMilliken says, most people with a disability weren’t born with it. As we age the likelihood increases that we’ll experience.
High contrast mode is not about design anymore but strict usability. You should aim for highest readability, not color aesthetics.
Avoid interactions that are timed based. Some people are slow. Some people take time. It should not be a stressful race to do something.
Comic Sans is actually a fantastic font face for people suffering from dyslexia. OpenDyslexic is a free open alternative.
Inserting zero-width space and invisible full-stops can make screen-readers speech nicer as shown by @simevidas.
Underlining links provides value to users failing at discerning contrast. I bet this is why it was designed this way in the first place.
This illustration from Microsoft is a good reminder that we’re all different, but we all should have access to the web equally.
Web accessibility is incredibly interesting. Don’t see it as a burden, see it as a challenge and embrace it!
That’s a hundred, I’m done for this session! Thank y’all for reading this far. Keep building cool stuff, you awesome people! 💖