The World Wide Web was built for everyone. That being said, it is not always accessible to everyone.
A large number of websites still have limitations that prevent people from experiencing them as intended. This blog will explore the what, why and how of accessibility to inform and educate how we can make the web a place where everyone is welcome.
What is Web Accessibility?
The W3C defines Web Accessibility as: –
Web accessibility refers to the inclusive practice of removing barriers that prevent interaction with, or access to websites, by people with disabilities
There is much more to it than that though. Consider the following quote: –
The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect
If we look at Web Accessibility as something we only need to implement for people with disabilities then it does not get the respect and attention it needs nor deserves. The web is for everyone and we should focus on making it a truly inclusive experience regardless of abilities.
The definition of disability is interesting in itself. Let’s explore that further.
Diversity of Abilities
The name of this section is quite appropriate. If we shift our focus on the abilities of different people rather than any disabilities they may have it allows us to create a better all round experience for everyone.
Let’s consider the following people: –
- A user on a busy train unable to use headphones
- A user with a broken arm
- An elderly user who hasn’t used computers
- A visually impaired user
These users all have something in common and that is that they could be impaired in someway or another when using the web. This may be, situational, temporary, Age related or Health related.
- A user who is impaired because of the situation they find themselves in. The user above on a train is unable to hear any content, so content that requires the use of ears would mean there experience is affected
- A user who is impaired temporarily perhaps due to injury. The user above with a broken arm may have limited limb movement, severely affecting their use of a mouse. Situational could also be seen as a temporary impairment.
- Age Related
- Many people develop age-related impairments. While they share the same functional requirements as others with disabilities, sometimes there are significant differences in the use of assistive technologies, the level of computer skills, or in the use of the Web in general
- Health Related
- Some people have health conditions that may affect their stamina, dexterity, or concentration. For instance, some may experience fatigue, pain, or other symptoms that could have an impact on their physical use of the computer
As you can see, there is a large variety of people we should be considering when building web applications and you might be thinking “why do I need to cater for everyone?”
Why Make Web Pages Accessible?
Firstly (and most importantly) it is the law. The Equality Act 2010 (EQA) replaced the Disability Discrimination Act 1995 and was introduced with the intention of dealing with disability discrimination.
The EQA was intended to bring further clarity to the previous act which was introduced when the internet was still young and nobody knew the speed at which it would grow. While the EQA does not explicitly refer to websites, the consensus has been that the reference to the “provision of service” applies to commercial web services.
In 2011 the Equality and Human Rights Commission published a code of practice for “Services, public functions and associations” under the EQA. In this code of practice they explicitly state that websites fall under the scope of the EQA saying: –
Websites provide access to services and goods, and may in themselves constitute a service, for example, where they are delivering information or entertainment to the public.
That being said the law isn’t the only reason you should choose to make websites accessible.
Semantic HTML is so important when it comes to making a website accessible. When talking about semantics it is important to start with affordances and what they are.
Affordance: The qualities or properties of an object that define its possible uses or make clear how it can or should be used
A good example I always like to use is a teapot. It has various affordances such as a handle that indicates to a user to pick it up. It also has a spout that instructs the user they can tip the teapot (while holding the handle) to pour something out of it. There is very little documentation or explanation required in how to use a tea pot as the design is intuitive enough that is can be deduced by looking at it.
When designing websites, decisions are make in terms of what elements look like buttons, links etc. Visually a user will know what a link looks or behaves like (for example when hovering their mouse over it etc).
The important thing here is we not only want to create this semantically rich User Interface for users, we also want to create a link for assistive technology that hooks into a web pages markup.
In its simplest terms if a website is created using generic markup elements and only visually styled, it would be incredibly difficult for any assistive technology to interact with it because none of the affordances native HTML offers has been built in. Even if a developer were to build in all the additional properties to their markup, it is increased work for similar results.
In short, JUST USE NATIVE HTML.
How Do You Do It?
A good starting point is WCAG 2.0 guidelines (Web Content Accessibility Group). There are 12 guidelines that can be split across four overarching principles. They are: –
- Information and user interface components must be presentable to users in ways they can perceive.
- User interface components and navigation must be operable.
- Information and the operation of user interface must be understandable.
- Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
There is also accompanying documentation in regards to how to meet the criteria set out by WCAG.
It is important to note however that while this documentation is important you should always be looking to apply these techniques where it is relevant.
A classic example I have often encountered is adding alternative text to images. While the guidelines state that this must be the case, there are times when images are used in a decorative manner. This means they are providing no additional text to the content on the page and as such the alternative text can be set to null. This will mean that any screen readers scanning the page will ignore these images as they are not relevant to providing context to the user.
Another source of documentation to instigate change is the WAI ARIA specification. This documentation is rich with the correct use of the varying ARIA (Accessible Rich Internet Applications) attributes that can be added to elements. It also provides the right circumstances in which you should use each one.
These approaches are quite text intensive and involve a lot of reading. (which funnily enough you have been doing with my blog for a while now!) As an alternative if you wish to dip your toes in the water to begin with, it can be considered good practice to put away your mouse/track-pad etc and use your only keyboard to navigate your website. Ask yourself these three questions: –
- Can you navigate around?
- Can you access all content?
- Can you achieve the primary task your website is designed for?
If you are answering no to some of these questions, then there are areas you need to look at and why this is happening.
Next thing to do is download and use a screen reader on your site. Two I recommend using are either NVDA for windows which can be downloaded in the link provided or VoiceOver for mac which can be built in.
The following two quick start guides on YouTube are really helpful for getting started with screen readers: –
Navigate around the various pages using the screen reader controls to identify any areas that may be lacking in terms of context for screen reader users.
One of the main problems I have come across is where button elements have no additional context applied to them. To a sighted user they would be able to identify that selecting a particular button would carry out a certain action but for somebody using a screen reader it would cause a confusing experience as the button semantically has no description associated with it.
A classic example of this is the “burger menu” icon that appears on mobile websites. To a sighted user they would intuitively know what this menu icon does and but we need to add in further affordances for screen reader users to tell them what this icon is affording to the user. There are a variety of ways you can achieve this, which is covered in the WAI-ARIA specification (linked above).
Overall, there is a wide variety of scenarios that can cause accessibility questions to pop up so I would suggest studying the WAI-ARIA specification along with the WCAG guidelines when creating a new user experience to ensure the experience can be enjoyed by all users.
In closing, accessibility is something that does not happen overnight. It should be baked in from the beginning and should be at the forefront of everyone’s minds, not just testers. I have (and am still having) the conversation to get this as part of my development teams considerations when creating new user stories. It is an education piece that takes place daily to get more people on board with the concept.
It is a lot to take in and can be daunting for people, thinking things are too far gone for it to be taken into consideration. While I have said this is something that should be at the forefront of any new development from the start, it is never too late to start asking the questions. Retro-fitting accessibility requirements is much harder but the effort is worth it in the long run as it allows us to stay true to the words of Tim Berners-Lee, “The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect”
- https://www.gov.uk/guidance/equality-act-2010-guidance#guidance-on-the-equality-act – Equality Act 2010 guidance
- https://www.equalityhumanrights.com/sites/default/files/servicescode_0.pdf – Equality and Human Rights Commision
- https://www.merriam-webster.com/dictionary/affordance – Definition of Affordance
- https://www.w3.org/TR/WCAG20/ – WCAG 2.0 guidelines
- https://www.w3.org/WAI/WCAG20/quickref/ – How to meet WCAG 2.0
- https://www.w3.org/WAI/intro/accessibility.php – Intro to accessiblity
- https://www.w3.org/TR/wai-aria-1.1/ – WAI-ARIA specification
- https://www.youtube.com/playlist?list=PLNYkxOF6rcICWx0C9LVWWVqvHlYJyqw7g – Playlist about how to implement accessibility