New regulations mean public sector organisations have a legal duty to make sure websites and apps meet accessibility requirements. From 23 September 2020, any public sector website in the UK published since September 2018 must be accessible.

Here at dxw, we build accessible services and websites because we want everyone to be able to use what we build, not just because of the legal requirements. Most of our work is done in the public sector so we use the Service Standard to help us think about accessibility from the very beginning of projects, and to help our clients understand all their users.

We’ve been working on an accessibility service for our GovPress clients, and we’re sharing our process and some recurring issues here, to help you make your website more accessible.

Taking stock

The first thing you need to do is to see where your website is working, and where it’s not. We use a combination of manual and automated testing, across different browsers and devices. You can put any website into tools like the WAVE web accessibility evaluation tool to get a list of issues, and that’s a great start. We also incorporate manual testing into our audits, so that we can get a deeper understanding of what’s going on for users of different assistive technologies, and we’d always recommend doing this.

We’ve done a few accessibility reviews for clients and there are 2 sets of common issues that we find: not designing or publishing for accessibility.

Designing for accessibility

Not designing for those who don’t use a mouse

People with disabilities will sometimes access and navigate the web in different ways, often using assistive technologies. This means that there’s a greater dependence on a website having clearly visible focus states and a logical page structure. Automated accessibility testing doesn’t always pick up on these issues so we check this manually, on both mobile and desktop. Especially as results can vary depending on how the website’s been put together.

Forms are an area where testing often reveals failures in being able to fully interact with a website and submit information. This ultimately prevents some users from being able to use and interact with a website or service. More on this below.

Not designing for other devices

Websites can often treat their layout and usability for mobile or touch screen devices as an afterthought. This is a significant accessibility problem for a large number of users who don’t use a laptop or a desktop. Whether intentionally or not, content is often hidden on mobiles, or the size of text, links, and buttons might be too small for a user to tap accurately. For instance, people with Parkinson’s may find it difficult to select the part of the page they want to click on. We also find that zooming into a page has been disabled.

Poor colour contrast

Colour contrast is a frequent issue. There must be sufficient contrast between text and its background that people with visual impairments are able to read it. This happens sometimes because of pre-defined brand guidelines, and frequently happens when text is overlaid on an image. The solutions to this can be really straightforward – whether it’s finding a different colour for the text, or not using images as backgrounds.

Inaccessible forms

Forms can be big hazard areas for not being fully accessible. This includes things like input fields, incorrectly labelled buttons, incorrect usage of input types, along with poor form validation feedback. Inaccessible CAPTCHA fields are a feature in many forms that aren’t accessible for a variety of users with mental and physical impairments. In CAPTCHA, users are often presented with obscure photographs or letters which fail accessibility tests and impose barriers on disabled users trying to submit a form.

Publishing accessible content

Inaccessible links

Content needs to be presented in a clear and understandable way. Using phrases like “click here” or “more information” when adding links means that there’s no information on what you’re asking your users to click through to. It also makes it harder for people using screen readers to navigate your website. Use descriptive text for your links, so that your users can understand what they’re clicking on.

Images without alternative text

Images can be an accessibility issue for websites because they don’t include alternative text to describe what’s in the image. Visually impaired users accessing sites on screen readers are not able to understand what an image is without this text. Most content management systems make it easy to manage images and have a field for publishers to include this important information.

Using images to display information

Using graphs, charts, or other visuals to display information can make it difficult for visually impaired users to view that information. If you don’t use descriptive alternative text or explain in writing what information is in the visual then you could be affecting the accessibility of your website.

Using PDFs

PDFs can make it harder for your users to access your content. We always help our clients to publish content in HTML by default, so that content is as accessible as it can be. It’s also because a lot of users don’t want to download PDFs, especially if they’re on mobile devices. However, a lot of organisations still use them to publish their content. It’s possible to create more accessible PDFs, and we’ve been helping our clients do this.

Embedding accessibility

Once you’ve done the work to check your website and fix issues, you’ll be in a good position to write and publish an accessibility statement. These statements provide information for your users on the accessibility standard your website complies with, how to make adjustments to your website to make it more accessible, which aspects of your website are not accessible, and who to contact to request information in a different format.

Publishing an accessibility statement is part of the legal requirements for public sector websites by September 2020. You can read the dxw accessibility statement on our website as an example of the type of information that should be included.

It’s really important to us that we help our clients understand their users – all users. There’s never a substitute for testing something with users, but we’ve walked through our manual testing with clients and demonstrated issues.

We also like anti-pattern thinking to spot issues. This is where we ask the question about how we can make things more difficult for users – reducing text sizes, making label content misleading, and making headers and body copy look the same visually. We’re running short training sessions with our clients to make sure that publishers are using good practices.

Tl;dr

If the new regulations will affect your website, here’s a list of what you can do:

  • take stock: find out how accessible your site is and what you need to fix to comply with accessibility regulations. We recommend using both automated tools and doing a manual audit on different devices and browsers
  • fix design issues: you may need development and design capability to do this. You also need to make sure you’re able to change them before 23 September
  • embed accessibility into your publishing: you can train your editors and publishers so that they can keep publishing accessible content
  • publish your accessibility statement for users: this needs to cover the aspects of your site that aren’t accessible, who to contact for an alternative format, and how compliant your site is with the legislation

dxw can help you make your sites more accessible and get ready for September. Get in touch with us at govpress@dxw.com to discuss how we can help.

Further reading

Understanding accessibility regulations on GOV.UK
Contents of the Accessibility Regulations, published 2018
Understanding accessibility requirements for public sector bodies
Accessibility for teams
The most common accessibility problems on the web from WebAIM, from their analysis of the top 1 million homepages

The post Helping the public sector make their websites more accessible appeared first on dxw.

Original source – dxw

Comments closed