There are a lot of misconceptions about making websites accessible, but with some simple thinking you can easily make your site more accessible.
Accessibilty is just for blind people
This is a pretty large myth about making the web accessible, it still gets thrown around the office a lot.
Accessibility is just for blind people, how hard can it be?. Visual impairment does cover a large area of accessibility, think users with low vision; color blindness; screen magnifiers; high-contrast; and screen reader users. Remember to consider dyslexic, keyboard-only, movement impaired and deaf users as well and your site and approach to accessibility1 will improve.
Icons are great for quick visual communication and call-to-actions, but can quickly become inaccessible. Ask yourself
is the action still conveyed if the icon is removed? If the answer is no, then there is a high potential for users to completely miss something you intended for them to do.
Sprites and icon-fonts are great for developers, but don’t easily make themselves accessible. As a general rule only use an image with
alt text if the action cannot be done without the icon present.
In the above three buttons:
- Insta-fail. The button and it’s intended action are only known to sighted users. As a trivial note the icon’s meaning could also be ambiguous or have a different context to some users or cultures
- Much better as the icon is accompanied by some helper text available to screen readers. Might even pass WCAG 2.0
- Awesome! The button has communicated its action to all, with the icon adding to the visual UX
Read more…read more what? Ensure links have relevant context by placing them inside
p tags or adding hidden text. Most screen readers or browser plugins can pull up all links on a page. Imagine reading
read more ten or so times on a home page without any context, how are you meant to know what each link actually does?
That’s better, context for our links! Again a tiny bit of markup goes a long way.
Lazy keyboard-only support
Hands down the simplest thing to add to your site is
:focus states. My lazy-no-design-needed rule is make the focus state the same as the hover state.
I have a snippet in sublime that triggers on
hocus, outputting both
:focus selectors for me like so, you will never need to think of focus states again.
The above assumes I am already nested with an
a, button or
input selector and adds so much visual clarity to the site that keyboard-only users should never have any doubt on what link they are on again.
<a href="#"/>. Even worse is
<span onclick="toggle(this)"/>, the 90’s called and they want their dialups back. While it can be made accessible, a lot of the time it’s simply the wrong element used for the wrong purpose. A better way to think of interactivity is:
- if the action navigates to a new page, it should be a link
- if the action finalises something, it should be a submit button
<button> button text </button>, not
<input type="button"/>) are fantastic for client side events and a fairly overlooked element when it comes to accessibility. They natively offer:
- event actions such as hover, focus and click
- tab focus
- space, enter or click presses
- nested HTML
- pseudo elements
div with a click handler, just use a button!
The above comes in handy for creating a
.trigger() to be called elsewhere on the object without causing errors.
HTML is meant to describe text, so use it for its intended use! Screen readers have some cool features such as telling you how long a list is, or the ability to skip to headings on the page. A wise man once taught me that structure comes first, then the visual styles. Removing the CSS from a page should still make it readable.
If you can keep in mind these small steps then accessibility can become second nature and part of good development practices. Treat having both hover and focus states the same as a background-color fallback for a gradient, and your sites will be instantly more accessible.
I have written the word
accessibility, and its variants, more than 20 times in this post, yet managed to spell it wrong every. single. time. ↩