Accessibility has come a long way since the launch of the Web Accessibility Initiative back in 1997. There is a wealth of information out there to help you make the right decisions. However, somewhere along the way that advice has been misinterpreted to create several myths around best practice.
These accessibility myths are being implemented on websites today which at best have no benefit to web accessibility and at worst may be damaging it.
Here are my most common web accessibility myths for coders and content designers.
Black text on white is the most accessible
Testing how accessible the colours on a website is fairly straightforward. You can use a colour contrast ratio checker like the one from WebAim.
The contrast ratio checker tells you if the contrast passes the Web Content Accessibility Guidelines also know as WCAG 2.0.
For example black text on a black background has no contrast. It has a colour contrast ratio of 1:1 and would obviously fail accessibility guidelines. At the other end of the scale white text on a black background has the highest contrast possible with a ratio of 21:1.
It sounds a bit counterintuitive but having the highest contrast ratio, pure black text (#000000) on a pure white background (#FFFFFF), isn’t the best for accessibility.
Many dyslexic users are sensitive to the brightness the high contrast colours cause. This can make words swirl or blur together.
To avoid this, use an off-white colour for your background and a dark grey for your text. You can read more about colour choices in this 2012 study “Optimal colours to improve readability for people with dyslexia“.
All images should have alt text
The blind or visually impaired use a special bit of software called a screen reader which reads text on a computer screen.
The alt attribute provides alternative text (alt text) for an image. It is this information which is read by a screen reader to help a blind user.
The code below is an example of an alt attribute, with the alt text “example text”.
<img src="example-123.jpg" alt="example text">
And this video shows a screen reader in action
Some developers add alt text on all their images thinking this will help with accessibility. But this practice may actually hinder a screen reader user. Adding alt text is all about context. The alt text for the same image may vary or require no alt text depending on the information surrounding it.
What alt attribute would you give to this image?
- image of dog
- Keith, the Jack Russell Terrier is the world champion tennis ball catcher for the third year running
- alt text of nothing ie alt=””
- A small dog running across a grassy field, mouth open, ready to catch a tennis ball
- Close up of Keith, the Jack Russell Terrier, trying to catch a tennis ball
Best practice is to only add alt text if it helps a screen reader user. For example you don’t need to add alt text if the image is decorative or all the information expressed in the image has already been explained within the body of the page. We don’t want to waste the time of a screen reader user but equally we don’t want to hide anything from them.
Out of the five options it is probably easier to say which options you would never use. Option one, ‘image of dog’ is a poor choice. It doesn’t describe the image and it uses the word ‘image’ which isn’t required as the screen reader will normally announce it as an image. Option two provides a lot of detail but none of it is relevant to the image. From the picture you can’t tell Keith the dog is a champion ball catcher.
Options three, four or five could all be used depending on content surrounding the image. You might for example use an alt text of nothing if the image had a nearby caption or a heading which accurately described the image.
You can find out more examples on when and when not to use alt attributes from Webaim.
Whether you add or don’t add alt text will be based on your judgement. However you should always add the alt attribute even if it is blank. By adding a blank alt attribute the screen reader ignores the image. A blank alt attribute would look like this.
<img src="example-123.jpg" alt="">
If you forget to add an alt attribute, a screen reader might read the file name of the image to the user instead of ignoring the image. In the example below the screen reader would announce the image as “example hyphen one two three dot J-P-G” which provides no benefit to the user.
All links should have a title attribute
The title attribute is one of the oldest HTML attributes dating back to 1995. Over 20 years later it is now more or less useless but some developers still have a misguided notion that the title attribute will help with accessibility.
What is the title attribute?
The title attribute is a tooltip you see when you hover over a link.
And in code form it looks like this.
<a href="http://example.com" title="This is some example title text">Example</a>
Jakob Nielsen, accessibility guru, supported the use of the title attribute back in 1998 and continues to say it has merit in a 2016 post “Using the title attribute to help users predict where they are going. Old school thinking and continued support from the well respected Jakob has meant the title attribute is still used – and that thinking needs to change.
Nielsen’s defence of the title attribute says it can be used “to provides additional details for mouse users”. But to be accessible you should make content available for all users – not just some.
W3C HTML5 recommendations state. “Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner.”
For example screen readers, used by blind users to navigate the web, normally don’t read the title attribute. If you had a link called ‘click here’ and you added the title text ‘this link goes to the BBC website’ the blind user would be none the wiser to the destination of the link as the only bit of information the screen reader will announce is ‘click here’.
The title is also useless on a mobile as the user can’t hover over a link and if you think it might have some search engine optimisation benefit – it doesn’t.
In 2015 WordPress (the most used Content Management System in the world), removed the ability to add a title attribute because of accessibility concerns.
The screenshot below shows how in WordPress 4.1 you could add the title attribute when creating a link
The screenshot below shows in WordPress 4.2 and all subsequent versions the title attribute field has been removed
You should never use the title attribute. Instead just make sure your links are descriptive – never use ‘click here’ or ‘find out more’. Instead provide a clear indication of what the user will see when they click on the link. Descriptive links also help sighted users who can glance down a page and easily see the link they want.
All buttons should have the <button> attribute
What would you say this is…
Most people would say this is a button. Visually you would be correct but technically you could be wrong.
A real button
When the button performs an action on the front or back end of the website such as submitting form data you would use the <button> attribute. The <button> attribute helps a screen reader know what it’s purpose is.
The imposter button
If you click a button and it just goes to another web page, it isn’t really a button. This is what marketers would describe as a call to action (CTA). It is basically a link on the page which is styled to look a bit different to give it greater visual prominence.
This imposter button should never use the markup <button> or role=button as it isn’t a proper button.
For example on the New York Times website it has a link to subscribe to the newspaper.
The button looks like this
And the code for the button is this
<a href=" http://www.nytimes.com/subscriptions/Multiproduct/lp8XKUR.html?action=click&pgtype=Homepage&module=subscriptionCTA&region=top-stories-below&campaignId=67LLR"> <button id="subscribe-button-bottom" class="button">Subscribe Now</button> </a>
As you can see they have used the <button> attribute when they shouldn’t. The ‘subscribe now’ button is just a link to another page that looks different. In fact they have another button promoting the same subscription which is just a normal link styled to look like a button.
This inconsistency and miss use of the <button> attribute can create confusion for screen readers.
- Black text on a white background isn’t the best for accessibility
- It is ok to have no alt text as long as you add the alt attribute alt=””
- Don’t use the title attribute
- Don’t use the <button> attribute when the button just opens up a new webpage
Do you have any accessibility coding myths or have a different perspective on my thoughts?Please comment below.