Accessibility for Everyone

Building Solutions for Real People

We are bombarded by advertising in traditional media and increasingly on the web, showing young, healthy models and actors, laughing and smiling. They are not real people. Real people face challenges: they squint to read; they fumble with their TV remotes; they are baffled by technology; they can't hear you; they are getting older. Real people struggle with technology and it makes them grumpy, because most technology was designed for the imaginary people we see in advertising.

Studies now put people with accessibility needs as the majority. It's not just the 1.2 billion people classed as having a visual, hearing mobility or cognitive disability, which would be commercial reason enough. It's the people with temporary needs through an injury such as RSI, or whose senses are temporarily impaired such as people unable to hear because they work in a noisy environment. And then there are people with age-related needs like reading glasses and hearing loss, which we may not even think of as a disability, but rather accept as part of life. Unless we are very unlucky, we can all expect to fall into this group sooner or later. So it's really the vast majority of people who have accessibility needs at any moment, and almost everybody will have accessibility needs at some time in their life.

The good news is that, when it comes to making accessible software and websites, it's never been easier. And since it benefits everyone, it really makes no commercial sense not to. Depending on what you are doing it may also be a legal requirement. Or you may feel that you’re ticking a box. Whatever the motivation, you don’t have to be “woke” - it's not virtue signalling or wide-eyed altruism. It's just sound business strategy. If your applications and web sites aren’t accessible, then you’re creating software that doesn’t work well for anybody. And nobody wants to build a website or software product that sucks.

But we need help and guidelines. The UK Home Office has an excellent free set of posters that you can download – Designing for Accessibility. I've used some of their recommendations in this article. Let's look at some of the key accessibility needs and some of those recommendations.

Anxiety

Who doesn't get anxious from time to time? But this refers to more serious issues caused by a clinical condition. Everyone gets anxious, especially old people who haven't grown up with computer technology. In a world where everything is constantly being reinvented - and of course we need to keep moving forward - it’s tempting to change things just to be new or "fresh", particularly with visual design. Remember that older people, and people with learning and cognitive challenges, don’t like change. Time passes quickly and when they’ve finally learned how to use your application or website; they won't thank you if you go changing things around for the sake of it.

Have you ever used one of those websites where you are asked for, say, credit card details and you start frantically rummaging around for the card and enter the information and then hit the "submit" button only to find, as you feared, the page has "timed out"? That takes a process that is already a source of anxiety about online fraud, and layers on top of it a nasty bit of time pressure, which for most people is just really annoying. But for someone with a clinical condition it is much, much worse.

Or what about applications with multiple forms where you can't check what you entered on an earlier page or where any error forces you to enter all the information again. This is particularly bad for people with anxiety and is a result of poor or lazy programming. It isn't difficult to make applications and websites that work for people with anxiety, and at the same time we are making them better for everybody. Why wouldn't you do the following anyway?

• Give users enough time to complete an action
• Explain what will happen – don’t leave users wondering
• Make important information clear
• Make access to support or help easy
• Allow users to check answers before they submit them
• Don't change for the sake of change

Autistic Spectrum

We all like to embellish, and in an article like this I'm going to use an anecdote or a turn of phrase from time to time to liven things up. These literary devices have a part to play in making a narrative more readable. But they're not appropriate for text in dialog boxes and functional websites. In these cases it's important to write in plain English and tell people what they need to do. It may seem cute to tell someone to "point your browser" at some website (actually, it's a bit of a cliché), but it might not be clear to someone who, for whatever reason, views the world very literally.

The autistic spectrum isn't just about people with serious mental disorders – many people are fully functioning members of society that just have particular challenges. Why make things difficult for them? But then again, why make things difficult for anybody? Things that work well for people with some form of autism generally work well for everybody else as well. So we should follow accessible design guidelines, such as making layouts simple and consistent. But why would anybody intentionally create complex inconsistent page layouts? And yet people do. Let's keep to the following guidelines:

• Use simple colours, not bright or contrasting colours (but maintain readability)
• Write in plain language - don't use figures of speech or idioms (unless it's creative writing)
• Use simple sentences and bullets, not walls of unbroken text
• Make buttons descriptive, not vague and unpredictable
• Build simple and consistent layouts
• Don't change for the sake of change

Deaf or Hard of Hearing

Here's another huge group of users who can be helped just by using understandable language. Many organisations seem to be so terrified of spam that they go to great lengths to keep their email addresses secret. But then they give out a telephone number as the only way to contact them. Not everybody likes to use the 'phone for all kinds of reasons – for deaf people that’s a particular problem - so that shouldn’t be the only option. Offer an email address, or a well-designed web form that someone is actually going to monitor and respond to promptly. I don't understand why some organisations are able to answer a telephone but somehow answering a simple email is beyond them.

• Use plain easily understandable language
• Use subtitles or provide transcripts for videos
• Use a linear, logical layout
• Break up content with sub-headings, images and videos
• Give users different options for communication, not just telephone

Dyslexia

Better communication means not relying on text alone – which is a huge help for people with dyslexia. And any text should be clear, which again comes back to using plain language. And allow people to change fonts – some font designs are better for dyslexia. There are a few fonts specifically designed for this, and some regular fonts have been found to be better for dyslexic users, such as, interestingly, Comic Sans. I don't think anyone is advocating using Comic Sans, which would give most designers sleepless nights, hence the recommendation to allow, or at least not prevent, font switching. It is also good to provide plenty of contrast between text and background colour, which helps with low vision as well.

• Support text with images and diagrams
• Align text left with consistent layout
• Use short, simple, plain text and avoid underlined words, italics or capitals
• Produce materials in other formats (e.g. audio or video)
• Use autocorrect or suggestions – don’t rely on accurate spelling
• Let users change text font and contrast

Low Vision

I'm convinced that print has become gradually smaller over the last couple of decades. I think the designers of television remote controls must all be teenagers with perfect eyesight. That's the only explanation for the microscopic captions printed below the tiny buttons, in a rapidly-fading colour I can only describe as "light black". There are many vision issues that can be helped by avoiding such tiny font sizes, and lack of contrast. Apart from choosing sensible text settings in the first place, it is a good idea to make content scalable. For example, in CSS for web pages use relative sizes like "em" or "%" rather than absolute size like "px" or "pt". Doing so means that when the user zooms the page, everything scales in proportion. If you use absolute sizes, then usually everything goes weird.

There are many tools built into web browsers and for Windows that can warn you about lack of contrast or other visual impairments like colour blindness. All these visual problems can be mitigated by following a few simple rules:

• Use a readable font size with good colour contrast
• Avoid exotic fonts - prioritise readability over stylish design
• Publish all information on the web page if possible (don’t force the user to download a file such as a PDF to get the information)
• Use a combination of colour, shapes and text – don’t rely on colour alone to convey meaning
• Follow a linear, logical layout and don’t scatter content over a page
• Put buttons and notifications close to the thing they relate to
• Make content scalable (use relative sizes, not fixed sizes)

Screen Readers

People with very poor vision, or no vision at all, usually need some kind of assistive technology such as a Screen Reader. This introduces a new problem – how to make sense of a screen rendered as a stream of spoken words, usually at high speed. If you have never used a screen reader, try switching on Windows Narrator, set the speed to 70% and go to any website. Or better still, if you are lucky enough to have the opportunity, have a screen reader user demonstrate how they use the software. Using a screen reader is a skill in itself, and you will understand why it is so important to structure applications and web pages logically, and provide textual context to visual elements.

A web browser actually has two ways of rendering a page – the visual UI DOM (Document Object Model), and the Accessibility Tree. The latter is built mainly from HTML5 elements but we can augment these if needed with ARIA attributes. So screen readers see a page in a fundamentally different way. Interestingly there is another very important group that sees a page this way - search engines. Most people want their web pages to make sense to Google and Bing. So with a bit of thought you can make your pages accessible to screen readers and search engines at the same time.

• Describe images (alt text) and provide transcripts for video
• Follow a linear logical layout - don’t scatter content over page
• Structure content using HTML5 elements
• Don't rely on text size and placement for structure
• Build for keyboard-only use - don't force mouse or touch-screen use
• Write descriptive, informative, economical links and headings
• If you really can't provide a logical page structure, use ARIA attributes

Physical or motor disabilities

Tiny buttons that are difficult to click on, input forms with weird behaviour, cascading menus that only work with certain input devices – seriously? If you sacrifice usability at the altar of graphic design then you create obstacles for people with physical disabilities. Actually, it's not just disabled users, it's users on mobile devices, users working in a cold environment wearing gloves, users in a hurry, and so on.

By following these guidelines and with a bit of thought and good UI development skills, we can make user interfaces better, not just for people with physical and motor disabilities, but for everyone else as well.

• Make large clickable actions - don't demand precision
• Give form fields space, don't bunch together
• Design for keyboard or speech only use
• Design with mobile and touchscreen in mind
• Don't have short time out windows – a user may need to take a break
• Provide shortcuts

Accessibility is for Everyone

Accessibility is for everyone, and a lot of these accessibility features have secondary uses for people that are working in situations such as multi-tasking or they have their hands occupied. As users we should be aware of these features and take advantage of them. Maybe that will also encourage more developers to implement them properly.

Be an A11y

Accessibility is sometimes abbreviated as "A11y" (A, 11 letters, y), which looks like "ally". You can be an ally to people with accessibility needs by following these guidelines, and that should be reason enough - it's just the right thing to do. But as we have seen, it also makes hard commercial sense because people with accessibility needs form the majority of the population.

As you read this article, you might have noticed that a few things keep coming up: using simple language, careful choice of fonts and contrast, simple and logical layouts and page structure. In fact almost all of the recommendations align with good design principles that apply to all your users. So we don't even need to make a special effort or deploy additional resources to build accessible software, because accessible design equates to good design.

We should be doing these things anyway - we just need to learn and then practice these good habits. Because sooner or later we'll all be that person struggling with the technology.

Resources:

• Home Office posters: https://accessibility.blog.gov.uk/2016/09/02/dos-and-donts-on-designing-for-accessibility/
• List of accessibility testing tools: https://docs.microsoft.com/en-us/microsoft-edge/accessibility/test?WT.mc_id=DOP-MVP-5002401
• Accessibility checker in Office: https://aka.ms/officeaccessibility
• Accessibility Insights: https://aka.ms/accessibilityinsights
• W3C Web Accessibility Initiative: https://www.w3.org/WAI/fundamentals/accessibility-intro/
• A11y heuristics : https://www.deque.com/resources/intro-to-accessibility-heuristics/
• WCAG: https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines

Picture credits: pixabay.com