Following Mel’s blog post about why making digital products accessible is a must, here we’re going to have a look at some of the techniques the Development team at Low&Behold use to implement those principles throughout each of our builds.
Building an accessible site starts in the design phase, making sure that colour contrasts are strong enough and tap areas are large enough, but assuming that these are already in place it becomes the developer’s job to make sure the website technically delivers its functionality for everyone.
Happily, creating semantically correct web pages goes a long way to achieving a good level of accessibility as well as being extremely friendly to search engines. By marking-up a web page using HTML elements such as <nav>, <section> and <article> we give structure to the HTML document making it easier to parse and provides context to assistive technology to the content being communicated.
Heading elements, H1 through to H6, set a hierarchy for the page content – good for SEO, but makes sure those accessing the content through different tech know what’s important on the page.
Our sites are checked prior to launch against W3C standards and regularly reviewed for quality using our unique Product Quality Framework to make sure that a site today is as good as it was on the day it launched.
Not all web users will access and navigate a web page without a mouse, if fact when considering all the different pointer technology available perhaps a mouse is one of the less used.
Making sure your site is navigable using only a keyboard is a fundamental requirement of an accessible web page.
A user needs to be able to visually see where focus is on the page, this can be achieved using the focus pseudo-class on elements which accept this state. The focus needs to traverse the page’s links in a logical way and not get hidden or trapped within elements which aren’t always shown, such as drop-down menus.
As standard we include bypass blocks, allowing keyboard users to jump down to primary content or navigation areas of the web page is a straight forward way to speed up user’s access to those sections.
Sometimes things go wrong on a web page, this might be due to user error when completing a form or something has failed server-side and when they do it’s important that the user knows this and what they can do to fix it.
When communicating these errors, it’s important that we not only use appropriate language explaining what’s happened but also to show what field or data has been the cause.
Our developers make sure error messages are visually clear in terms of UI and UX, as well as marking them up to create a relationship between the error and the form element which can be communicated by assistive technology.
We might supplement inline errors with a block higher up the page with anchor links down to the relevant area to save the user from needing to scroll to discover the issues.
Whilst a well-structured HTML document will go a long way to meeting your accessibility requirements, the content which appears on the page impacts how usable it is to those accessing it on assistive technology.
With many sites running on CMS, website owners have a responsibility to make sure the content being written can be accessed and understood by all. This might mean:
- Providing alternative text content for images
- Making sure text within links provide context to their destination
- Writing for the correct target audience
- Proving copy in alternative languages and formats
Though the WCAG Accessibility Guidelines are a list of recommendations the implementation can be incredibly nuanced depending on the target audience of a website.
There are many more techniques we employ during our builds to make accessible sites, this article gives just a flavour of the considerations our developers give to make sure that everyone that visits a website we’ve built can access the all the content, that it’s understandable and they can navigate around the site easily.