Web Accessibility: What? Why? How?

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

Tim Berners-Lee, W3C Director and inventor of the World Wide Web

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: –

  1. A user on a busy train unable to use headphones
  2. A user with a broken arm
  3. An elderly user who hasn’t used computers
  4. 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.

Situational
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
Temporary
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

Merriam-webster.com definition

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: –

Perceivable
Information and user interface components must be presentable to users in ways they can perceive.
Operable
User interface components and navigation must be operable.
Understandable
Information and the operation of user interface must be understandable.
Robust
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: –

  1. Can you navigate around?
  2. Can you access all content?
  3. 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: –

  1. NVDA – How to use it
  2. VoiceOver – How to use it

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.

Closing Thoughts

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”

References

  1. https://www.gov.uk/guidance/equality-act-2010-guidance#guidance-on-the-equality-act – Equality Act 2010 guidance
  2. https://www.equalityhumanrights.com/sites/default/files/servicescode_0.pdf – Equality and Human Rights Commision
  3. https://www.merriam-webster.com/dictionary/affordance – Definition of Affordance
  4. https://www.w3.org/TR/WCAG20/ – WCAG 2.0 guidelines
  5. https://www.w3.org/WAI/WCAG20/quickref/ – How to meet WCAG 2.0
  6. https://www.w3.org/WAI/intro/accessibility.php – Intro to accessiblity
  7. https://www.w3.org/TR/wai-aria-1.1/ – WAI-ARIA specification
  8. https://www.youtube.com/playlist?list=PLNYkxOF6rcICWx0C9LVWWVqvHlYJyqw7g – Playlist about how to implement accessibility
Advertisements

4 thoughts on “Web Accessibility: What? Why? How?

  1. All good stuff, of course; but beware getting too set in your ideas about “disabled” users. I know you set out to be as inclusive as possible about this – and kudos for that! – but the issue goes even further than you suspect.

    For example – “elderly users who have not used computers”. Well, it won’t be too long before you’ll have to consider “elderly users who HAVE used computers”! The first generation is serious business IT users are approaching their 60s, and I should know because I’m one of them! My experience is that this can be an issue when excessively “clever” UI designers do things that aren’t intuitive to people who’ve been using computers since the days of Windows 3.0 (or even before). I had an encounter with a supermarket customer service terminal a little while ago whose operation was completely counter-intuitive – so much so that I branded it “unusable” when I wrote to the supermarket’s CEO to complain.

    Deteriorating health – or, in the case of your hypothetical user with the broken arm, improving health! – will mean that it’s going to be hard to design a website/UI that is all things to all people. I think you are very right to talk about using the ability to retro-fit as a route to improving accessibility. All too often you see sites in public-facing situations which haven’t been upgraded in years; they look old-fashioned and their performance is pretty poor, too. It leads to reputational damage before the user even attempts to interact with the system.

    You are also right to emphasise the range of different abilities that need to be accommodated. I worked for an organisation once where one of the influential managers had red/green colour-blindness. His input to designing our first website was very helpful; but it meant that the organisation then locked itself into retaining that site for much longer than it should have done, resulting in the site ending up looking very tired. It also meant that it was very good for accommodating visual impairment, but other issues went unaddressed.

    In short, then, no matter how good you think your front page/website/UI design is, it will always present a challenge to some users at some time or other, and continual improvement should be the objective. That in itself will represent a challenge to many organisations, who will see “website refresh” as a project with a set finishing date, after which the website will be expected to remain static for some time and not have any money spent on improving it. That’s going to be a difficult pill to get some managements to swallow.

    1. Thanks for your feedback! 🙂 It really is helpful/useful.

      I genuinely hadn’t considered your point about elderly users who are familiar with computers before and it is an interesting point going forwards. As time goes on we should just be considering that as people get older they may not need these counter-intuitive designs that UI/UX designers come up with. This is where user testing could really come into play and be super beneficial. If we have a hypothesis for a design we should put it in front of our user base and ask for honest feedback. A/B testing also plays a part in that as well.

      I wrote this coming from the angle of working for a company that is retrofitting their accessibility requirements and people are feeling totally overwhelmed at what to look for/what to do. It has been a steep learning curve for me and in many ways I have found there is more than one way to skin a cat so to speak when it comes down to creating accessible solutions which has caused much debate within my team.

      Definitely agree with your continual improvement point, people are so focused on getting things right first time that it is bound to fail.

      1. You may be interested in this, which I’ve just seen. It’s from an interview between my old mate David Langford and the BCS. Dave is notoriously deaf:

        Q: BCS is keen to promote social inclusion through IT. Do you think the IT industry is doing enough to develop assistive technologies?

        A: Too much, from a purely personal viewpoint. I have poor hearing, and for years enjoyed the bliss of easy communication when the web was 100 per cent visual. Then, to put me in my place again and restore the status quo of straining to hear, they introduced podcasts and unsubtitled AV clips. Still, it’s only fair that blind net users should get their turn.

      2. It is truly difficult to cater for everyone. Thankfully all of our content is visual meaning things like video and audio content are out of scope. I know people who have worked at the BBC and I quizzed them on some of their content not having subtitles and short story was the way they create media clips meant the overhead to add things like subtitles or audio descriptions makes things more difficult. Kind of ties into your point about gradual improvement I guess.

        Best endeavors is what I think we should be striving for and in some cases I do not even think that happens.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s