Web Accessibility Guide

Ethical and Legal Guidelines for NGOs and Social Entrepreneurs

Access to a free and open Internet is one of the defining social justice issues of our time – and it’s equally important that the right to information and exchange is extended to all people, regardless of ability.

The UN Convention on the Rights of Persons with Disabilities recognises access to information and communications technologies, including the web, as a basic human right.

Legislative frameworks exist to protect that right in many countries, including Germany, the UK and the US. The laws typically apply with greater force to government organisations and organisations that receive state funding.

Unfortunately, while we all want to do the right thing and be as inclusive as possible in our communications, it can be hard to find practical examples of how to make websites and applications accessible. It’s even more difficult if you are overseeing development of a website, but you don’t have a technical background yourself.

This article gives you a quick overview of what is meant by website accessibility, the technical and legal frameworks that exist, and practical steps you can take in planning a website project to improve access for everyone. No, it’s not page turning, riveting stuff, but it deserves our attention.

What do we mean by website accessibility?

Generally web accessibility (or “Barrierfreiheit” in German) is taken to mean that a website should be useable for people with a range of different disabilities. This can include people with visual, auditory, cognitive or motor impairments. We tend to think of these groups as being served by specific assistive technologies or defined approaches. Some of these include:

Visual

Screen reader software, such as VoiceOver
High contrast, simple and highly legible designs

Auditory

Subtitles or alternate text for videos or audio

Cognitive

Alternative content using simple text and images – this is formally legislated as “Leichte Sprache” in Germany

Motor

Keyboard navigation
Adequately sized tap targets (links and buttons) on tablets and phones

However, thinking effectively about accessibility is about more than identifying certain disabilities and making sure the appropriate assistive technology functions adequately. It should also involve thinking carefully about the audience for your website, and considering any possible difficulties they could encounter in using the site.

Think about age, education and cultural differences in your audience. Will an elderly person with an older computer be able to access all the information on your site as effectively as someone using the latest smartphone? What about people who don’t speak the site’s language as their native language? Depending on your organisation and the website you are developing, internet bandwidth may also be an accessibility issue. Although worldwide access to the internet is improving rapidly, sites filled with large images are going to be slow to download in many parts of the world.

When we speak about website accessibility in a broader sense, these are the kinds of issues that should be addressed.

Technical Guidelines

The W3C, the organisation primarily responsible for setting standards for internet technologies, has several working groups devoted to developing guidelines and best practices for website accessibility. The two most important documents are the WCAG and WAI-ARIA.

Web Content Accessibility Guidelines (WCAG)

The WCAG 2.0 is a set of recommendations for making web content more accessible. Overall, the WCAG document declares that websites should be perceivable, operable, understandable and robust.

Perceivable

The website should present content in different ways, for example by providing text alternatives for images and video.

Operable

It should be easy for users to navigate and interact with the site, whether they are using a mouse, keyboard, touch screen or other technology.

Understandable

Web pages should behave in predictable ways and provide adequate user feedback, such as error messages when a form was improperly filled out.

Robust

The website should be compatible with current and future user agents – that is, designed according to open standards, and not to work with specific proprietary technologies.

The document is made up of testable statements that are not technology specific. Some examples of these statements include:

“Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.”

“Make all functionality available from a keyboard.”

These statements have generally been mapped to technical implementations in HTML and CSS, such as making sure the “alt” attribute on image elements is filled with a description of the image.

The specification is divided into 3 priority levels (A to AAA). A is an absolute minimum for accessibility. WCAG 2.0 forms the basis for most relevant legislation and guidelines, including the UK, EU, and Germany.

Unfortunately, while WCAG is rich in scope and has an excellent definition of the broad underpinnings of accessibility, it is widely perceived as having a narrow and onerous technical focus that discourages many developers and organisations from even making a start on improving their website accessibility. Where it has acted as a legal requirement, it has forced some projects into spending large amounts of time trying to do the coding equivalent of crossing every ‘t’ and dotting every ‘i’, rather than investing time in specific improvements that will have the most impact on end users.

This is a real shame because in fact, it’s possible to make quite simple improvements to many websites that dramatically increase their accessibility.

Accessible Rich Internet Applications (WAI-ARIA)

WAI-ARIA is a second set of specifications that was developed as a response to the increasing complexity of web applications. As websites are no longer comprised of static documents, assistive technologies (such as screen readers) need to be informed of the role of various elements in the document (e.g. navigation, search, filters) and of their state (e.g. new content has been loaded, a user feedback message has appeared).

The WAI-ARIA is still relatively new and developers are still working out how best to apply it in practice. Also, support for the new specifications by assistive technologies such as VoiceOver and Jaws (screen reader programs) is still inconsistent.

However, the area of landmark roles is one which can be put into practice straight away. These are very small additions to the code of a website that are used to specify to a screen reader the purpose of various parts of a web page – for example, navigation, main content, or additional content such as a sidebar. This can greatly assist users in getting more quickly to the content they want, rather than having to listen to a long list of navigation links being read out at the start of every page.

Even if you already have a website, it’s well worth asking your developers to implement this change for you as it’s a quick and easy way to improve the accessibility of your website.

Website Accessibility Legislation

German Legislation – BITV 2.0

BITV 2.0 is composed of two parts, Anlage 1 and Anlage 2. It mainly applies to government organisations and to some organisations that receive government funding.

Anlage 1

Technical specification that draws heavily on the WCAG standards, and covering requirements like providing alternate descriptions for images and title attributes on links; keyboard navigation; and user feedback.
Divided into Priorität 1 (less onerous) and Priorität 2 (more onerous).
Free online self assessments are available, or you can pay for an audit.

Anlage 2

Specifies the minimum amount of site content that should be made available in simple text and sign language.
To fulfill these requirements you will need to work with certified professionals.

Best Practices

Planning

Planning is the most important stage in any major project, and developing accessible websites is no exception. At this stage you need to clarify what the “core tasks” or main user goals of your site will be. These could include:

Accessing information
Registering for events
Making contact with your staff

Refining these goals will not only help you develop a more accessible website but assist you in clearer decision making throughout the project, as you prioritise which features are really important.

One you have your goals in mind, consider the nature of your audience. This will vary depending on your audience, but you should develop a number of different user profiles who would be typical users of your site. Some of these user profiles should include people with special requirements such as keyboard navigation, larger screen text and so on.

You should then identify how you would enable your various potential users to complete all the site’s core goals. For example, if the goal of the site is to have users register to attend local community events, you will need to make sure that the registration form can be filled out using only a keyboard, with no mouse.

It’s desirable but less important to consider how you will make content that’s not related to the core tasks accessible – realistically we all need to work within time and budget constraints. Effective planning allows us to allocate limited resources to have maximum impact.

Development

Once you have your goals and user profiles in place, it’s time to start working with technical professionals.

It’s really important to work with a development team that is sympathetic to your accessibility requirements. It doesn’t mean that they have to have a huge portfolio of similar works; but they should be willing to familiarise themselves with the relevant technical and legal documents and make appropriate modifications to their code.

You should also ask them to implement some specific technical requirements:

Ability to add alternate text to all images
Keyboard navigation, including a logical tab index
WAI-ARIA landmark roles
Skip navigation link

I have made an accessibility how-to guide for developers with code samples that covers all these topics.

Depending on the specific legal requirements of your project (and your budget), you may also need to implement sign language and/or simple text content. For this you will need to contact properly registered professionals who can guide you through what you need to do.

Testing

Testing is a key and too often overlooked phase of website development. You should allow at least 25% of your project’s timeframe for testing. Think of this as an opportunity to further strengthen and develop your website – don’t panic as soon as you find the first problem!

I like to break testing down into two parts: functionality testing and task-based testing (these are sometimes called white box and black box testing).

Functionality Testing

Functionality testing is the process of meticulously going through the website in various browsers (in combination with assistive technologies) and making sure all the required elements work – links can be clicked, content accessed, navigation navigated and so on. This could be done by the development team, or you could do some of it in-house to reduce costs. In any case, I recommend you at least have a short play around with navigating the internet using only a keyboard, or using a screen reader technology such as VoiceOver, if only to give you an idea of just how frustrating the experience can be.

Technology to test in this fashion includes:

Windows: JAWS – in combination with Chrome, Firefox and Internet Explorer
Mac: VoiceOver with Safari (press cmd + F5 in Safari to get started)
Tablets and phones: VoiceOver, any other screen reader technologies

Task-Based Testing

Task-based testing ties your whole project together by linking back to the core tasks and goals that you identified during planning. In task-based testing, you assemble a group of testers (preferably matching the user profiles you identified earlier) who will assess your site “from the outside” – that is, they should approach it with a fresh point of view and not be part of the development or management team.

This can be a tricky and confronting process, so the key is to create a friendly and low-stress atmosphere. Testers can feel that it’s their abilities that are being put to the test, rather than the website! To overcome this, praise error detection, and encourage people to speak up if they have problems – even offer a small prize for every bug that’s found.

Set goal-based tasks for your testers, such as:

make a booking;
find a contact number; or
research a piece of information.

Then elicit feedback on whether or not your testers were successful in completing the tasks, if not then determine why not and how the process could be improved. You can also ask for more general feedback and critique at the end of the session.

Following this methodology allows you to keep the discussion focused on whether the website is fulfilling its purpose, and prevents it from breaking down into critiques of design decisions that are highly subjective and vary from person to person.

Setting up the tests using a Google form to capture structured feedback is a really useful tool, especially for remote testers.

Conclusion

I hope you were able to take away some useful information from this article and find the topic of improving web accessibility a little less mystifying.

I really believe that access to a free and open internet is one of the defining social justice issues of our time – and it’s important that the right to information and exchange is extended to all people, regardless of ability.

Fortunately, a little careful thought, some planning and small tweaks to website code can lead to dramatic improvements in user experience for people who are reliant on assistive technologies.

If you have questions or want to share your experiences, please do so below or on your own blogs and websites, so we can grow the knowledge base of best practices available to us all.

Resources

About the Author

Melanie Thewlis

Melanie Thewlis is a co-founder of Little Web Giants, an online marketing and web development consultancy based in Berlin and Melbourne. She has a diverse range of professional experience working with not for profit organisations, including Friends of the Earth, UK Tar Sands Network, Stiftung Bürgermut, Humboldt University, Stadtbienen e.V. and Melbourne Montessori School. Melanie provides regular free of charge consulting sessions to the non-profit sector at Betterplace Stammtisch and Social Media Sprechstunde events.

Originally published September 25, 2016

Social Business