Shelter’s Accessibility Guidance & Best Practices

Owned by Craig Melcher (Deactivated)
Last updated: Jul 16, 2021
7 min read

Introduction to Web Accessibility and WCAG 2.1  

Web accessibility is the inclusive practice of ensuring there are no barriers that prevent interaction with, or access to, websites on the World Wide Web by people with disabilities. When sites are correctly designed, developed and edited, generally all users have equal access to information and functionality.1 

Web accessibility encompasses all disabilities that affect access to the web, including: 

  • auditory 

  • cognitive 

  • neurological 

  • physical 

  • speech 

  • visual 

Why is web accessibility important? 

In the UK, 1 in 5 people have a disability. It’s estimated there are 13.9 million disabled people in the UK, which is over 20% of the population.1 

To put that into perspective, 20% of Shelter England’s website users from 1 June 2019 to 1 June 2020 equates to over 1 million.  

More than 80% of people with impairments have decided not to trust a service provider that has barriers, poor web accessibility being one of the top reasons.

Case studies have shown that improving the accessibility of your digital services aligns with business goals and benefits your brand. The NHS underwent a massive digital overhaul to its platforms in 2016 to improve accessibility, which resulted in the average daily users increasing from 15,000 to 26,000.2 

Not only do Shelter England and Shelter Scotland provide housing advice for users with disabilities and health conditions, but it is imperative that our digital products are accessible for all Shelter supporters, volunteers, donors, and campaigners as well. 

The accessibility of all UK websites is covered by the Equality Act 2010. This protects all individuals from unfair treatment and promotes a fair and more equal society.

Site owners are required to make ‘reasonable adjustments’ to make their sites accessible for people with disabilities. There is currently no legal precedent for what would constitute a reasonable adjustment. However, given that the UK Government has adopted WCAG 2.1 level AA as a suitable standard for public sector sites, any site which meets these guidelines would have a very strong defence against legal action.  

From the 23rd September 2019 new accessibility regulations have come into force. These days, public sector websites will need to meet certain accessibility standards and publish a statement saying they have been met. Existing websites had until 23rd September 2020 to comply. All apps will have until 23rd June 2021 to comply. 

It is not very clear who these regulations cover, but according to GOV.UK public sector bodies include: 

  • central government and local government organisations 

  • some charities and other non-government organisations 

But the following organisations are exempt: 

  • non-government organisations like charities - unless they are mostly financed by public funding, provide services that are essential to the public, or aimed at people with a disability 

  • schools or nurseries - except for the content people need in order to use their services, for example a form that lets you outline school meal preferences 

  • public sector broadcasters and their subsidiaries 

This information is from the Web Usability blog ‘What is the law on accessibility?’ 

More information is also available on the government website. 

To meet government accessibility requirements, digital services must: 

Summary of WCAG 2.1  

WCAG stands for Web Content Accessibility Guidelines. The Web Content Accessibility Guidelines have been in existence since 1999, when the first version ‘WCAG 1.0’ was published. WCAG 1.0 included just 14 guidelines and was created by World Wide Web Consortium (W3C). The latest version of the guidelines WCAG 2.1 was published in June 2018 and includes 78 success criteria. The success criteria is rated from A to AAA (AAA being the highest).  

 The Web Content Accessibility Guidelines is grounded on four principles:  

  1. Perceivable – Information and user interface components must be presentable to users in ways they can perceive. 

  2. Operable – User interface components and navigation must be operable. 

  3. Understandable – Information and the operation of user interface must be understandable. 

  4. Robust – Content must be robust enough that it can be interpreted by by a wide variety of user agents, including assistive technologies. 

 

Shortened WCAG 2.1 

1.1 Text Alternatives - 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. 

1.2 Time-based Media - Provide alternatives for time-based media. 

1.3 Adaptable - Create content that can be presented in different ways (for example simpler layout) without losing information or structure. 

1.4 Distinguishable - Make it easier for users to see and hear content including separating foreground from background. 

2.1 Keyboard Accessible – Make all functionality available from a keyboard. 

2.2 Enough Time – Provide users enough time to read and use content. 

2.3 Seizures and Physical Reactions – Do not design content in a way that is known to cause seizures or physical reactions. 

2.4 Navigable – Provide ways to help users navigate, find content, and determine where they are.  

2.5 Input Modalities - Make it easier for users to operate functionality through various inputs beyond keyboard. 

3.1 Readable – Make text content readable and understandable.  

3.2 Predictable - Make Web pages appear and operate in predictable ways. 

3.3 Input Assistance – Help users avoid and correct mistakes. 

4.1 Compatible - Maximize compatibility with current and future user agents, including assistive technologies. 

The entirety of Web Content Accessibility Guidelines (WCAG) 2.1 can be viewed here: https://www.w3.org/TR/WCAG21 

Roadmap to improving accessibility  

As an organisation, we strive to ensure that the digital products and services we produce are accessible to anyone who requires them. Shelter's Web Accessibility Statement emphasises our commitment towards complying to WCAG 2.1 ‘AA’ standards. Shelter’s site currently exceeds WCAG 2.1 single 'A', but more is needed to be done to improve accessibility and usability in order to conform to ‘AA’ standards. 

Accessibility is everyone’s responsibility 

As awareness and knowledge of accessibility is increasing within the organisation, we want individuals to consider accessibility from the start of a project, but also to feel empowered and equipped to be able to raise existing accessibility issues. Accessibility is not the responsibility of one person. Everyone in the team is responsible for making our services accessible. 

It’s important that each person on the team understands how to avoid accidentally making things inaccessible. This includes developers, content designers and interaction designers. User researchers and testers can help find accessibility problems so the rest of the team can remove them. Product and delivery managers should understand accessibility too so they can ensure it’s considered from the start and built into the service efficiently.2 

How to flag existing accessibility issues and suggest improvements 

If you come across an existing accessibility issue or would like to suggest an improvement, then it is recommended to submit a Shelter Accessibility Form. This form has been created to be used by anyone in the organisation.  Once the form has been submitted, then a card will automatically be generated in the Accessibility Leankit Backlog.  

Accessibility Leankit Board 

A Planview Leankit Board has been specifically created for Accessibility. Once a card is added to the swimlane ‘Flagged issues’, it will then be triaged and assigned to the appropriate team to resolve. The hope is that we can have a central place to collate issues and view the roadmap of issues flagged. 

Red route usability: testing key user journeys internally 

Introduced in London in 1991, red routes are major roads on which vehicles are not permitted to stop. Their goal is to allow high traffic volumes to flow freely without obstruction. When applied to design, these red routes are the critical and frequent paths that users take to complete their tasks. This concept has been adopted to improve usability of digital products, where red routes are the critical tasks that deliver the most value to your users. These routes are the foundational user journeys that make your product valuable and typically capture 90% or more of your user’s actions.3 

Red routes are: 

  • Critical. Without these routes, your product would not deliver any value. 

  • End-to-end tasks with multiple steps or actions, not single events. For example, clicking a “Sign Up” button is an action, not a route. However, user registration from beginning to end would be a route. 

  • Frequently utilised.  

  • Built for scale. They are high volume user journeys that funnel a majority of your product traffic. 

  • Key value drivers. They drive your key business metrics. 

  • Objectively successful. You should be able to clearly define what success looks like. 

  • Tied to critical product metrics. Your red routes directly impact your bottom line and have a substantial impact on user experience. 

Here is an example of a red route matrix, showing which metrics to use based on user frequency and volume:

A matrix diagram showing the measurement needs for Red Route Analysis

Improving a website’s accessibility is usually a large-scale endeavour. Applying the red route method helps you:

  • prioritise user needs and facilitate alignment amongst stakeholders 

  • build and optimize product features that deliver the most value to our users and drive key metrics 

Key journeys to test internally using red route analysis:

  • Get help journey  

  • Donate journey  

  • Top housing advice journeys 

  • Search 

External accessibility audit 

Third party testing e.g. Scope (digitalservices@scope.org.uk) or RNIB (businesslink@rnib.org.uk) 

Standard rate: £567 a day (dependent on how many days ranges £400-£800) 

Here is a standard agency rate card

Writing for accessibility

Editorial skills play a big part in removing barriers for users with disabilities. They include writing in plain language, using accessibility best practice for headings, links, and non-text content, and much more. Read our guide to writing for accessibility.

Ongoing  

  • QA – General Criteria for Shelter web pages needs to be reviewed as it has not changed in over 2 years. e.g. alt text or null (empty) alt text, focus order preserves meaning and operability, headings follow logical structure, no text in images unless it’s a logo, keyboard navigation, are form fields/radio buttons labelled correctly.

  1. Image & copy content (As per copy attached unless mentioned by PM e.g. Word doc., Figma design) 

  2. Meta details for every new page developed (Meta content e.g. image, description, title etc. must be there with attached copy) 

  3. Forms fields (validation unless its mentioned) 

  4. GDPR consent statement as per agreed design (if it's required to captured consent) 

  5. Vanity URL (if its mentioned in copy doc.) 

  6. Cross Browser Testing (as per agreed criteria) 

  7. Responsive webpage (as per agreed criteria) 

  8. Response email functionality & content (if it's requires) 

  9. Form submission to HIP(Data base) ,Adestra (CRM) and iRaiser (Payment platform) 

10. Social sharing button text, size and color (e.g. Facebook & Twitter) 

11. A/B testing – variant 

12. Email client (Outlook, Gmail, Yahoo) -Newsletter design & layout (e.g. SDAS, NHAS) 

13. API testing– data submission (e.g. GDPR consent, form data) 

14. Exploratory testing 

15. Manual Functional testing 

16. Automation testing 

17. Look & feel (end user perspective e.g. image resolution, emotional attachment, visibility, preference etc.) 

18. Comment – every card should have comment when it moves along different lane, it helps others to understand the status and history of the user story and it also creates accountability. 

19. All 'Acceptance Criteria' which is mentioned on card 

 

  • Pattern library, reviewing accessibility of components 

Guidance for.... 

[Can we have a champion in each team to write accessibility guidance and share within COPs?]