accessibility

Common web accessibility issues for a user with a visual impairment

Have you considered how your content might be consumed by a user with a disability?

A student with a visual impairment got in touch to say they were experiencing difficulties using certain form fields. I wanted to explore this and used it as an opportunity to run some testing with the user on common journeys on the website.

The testing was enlightening and gave some valuable feedback which we’re using to make adjustments on the website. The user highlighted several common issues they experience daily which I thought would be valuable to share.

Magnification

As you might have expected, increasing screen size across any device was a must for the user. If you or I wanted to see something more clearly when browsing the web, we’d probably zoom right? This works for us, but it isn’t necessarily how users with a visual impairment would do it. The user who tested with me uses screen magnification instead, commonly between 200-300%.

The difference is screen magnification enlarges the whole screen but maintains the aspect ratio. This takes parts of screen out of the viewport horizontally. Whereas zooming within a browser like Chrome the width of the screen stays the same and content stacks vertically.

The following screenshots illustrate the difference. The left is the magnified version and right is zoomed. You’ll notice on the zoomed version the logo, navigation and primary navigation are visible, but in the magnified version these are now out of the viewport.

Screenshots showing the comparison between zooming and magnifying a webpage to 200%

Magnification of the entire screen means horizontal scrolling comes into play. More complex layouts with text next to imagery can cause difficulty when only a portion of content is visible at any one time.

Take the following example, in the magnified version on the right, the user can’t tell there is text to the side of the image and could easily miss it.

Screenshots showing how web content with an image and text side-by-side is different when viewed at 100% and magnified by 200%

You can try out the difference between zoom and magnification yourself. Here’s how to do it on Windows and Mac.

On Windows, use Control with + to zoom in and Control with – to zoom back out again. Now use the Windows button with + to toggle on the magnification tool. Then use Windows with + to magnify and Windows with – to reduce in size.

On a Mac, you can zoom using Command with + and – to zoom in and out. For magnification, you will have to enable the “Use keyboard shortcuts to zoom” feature (yes, I know it says zoom rather than magnification) in your Accessibility preferences under System preferences. Once you’ve done that, toggle the feature on using Command with Option and F8. Then use Command with Option and + to magnify and Command with Option and – to reduce.

Screen readers

A screen reader is an application that assists users with consuming content, converting it into a medium which visually impaired users can digest easier. The user regularly uses a screen reader to help with using the web, but particularly on mobile devices where screen size is so small.

Key information can be hard to pick out in text-heavy content. Long paragraphs are difficult to process, particularly on mobile devices. Concise copy that gets to the point and is easier to consume for all users but particularly those with a visual impairment. This is also where accessible content like the correct use of headings and link text is crucial.

Try to consume some of your content using a screen reader on mobile and see how it works. These applications come as standard on iPhone and Android. On iPhone you need VoiceOver which can be found under Settings > General > Accessibility and on Samsung Android it’s Voice assistant under Settings > Accessibility > Vision.

Colour/contrast

In the use of colours, contrast is the major factor. Thin text wasn’t an issue for the user if the contrast is high enough. Even if the text can’t be made out, the contrast would let them know something is there. This allows them to tap for their screen reader to kick in or magnify the screen further.

Contrast with backgrounds is different. As this isn’t displaying information, a subtle difference between a white and a grey is often enough to indicate a change of state. The user mentioned that the zebra striped tables we use are very helpful. When the screen is magnified, only part of a table is visible, the change in colour despite being slight helps them to follow a row when scrolling horizontally.

Example showing how tables on the derby.ac.uk appear when the screen is magnified — Screenshot showing how the entry requirements table on a course page looks when the screen is magnified

In summary

Observing how different users consume your content will provide valuable insights that can help shape what we do. I’d encourage you to take half an hour to try magnifying your screen and using the screen reader on your phone.

If you’re interested in reading more on this subject, I’d recommend this blog by a software engineer from the BBC who writes in detail about his experience using the web for a day with a screen reader.

A blog about using plain English

We need to use plain English. Plain English gets our message across quickly and easily. People understand it the first time they read it. Plain English is efficient. It uses short sentences. Is that plain enough for you?

The challenge we face is balancing plain English with getting across our brand personality and our key messages. We need to be welcoming and approachable. We also need to express our expertise. So we don’t want our English to be plain yet dull and cold. We want it to be warm, engaging and compelling. All this applies whether we are writing for print, the website or email communications.

Academia tends to have a strained relationship with plain English. I had a brief conversation recently with a colleague who has a pretty high level of academic qualification. They admitted that the further up the educational tree/mountain/ladder you climb, the more complicated the language you are encouraged to use.

In other words, Professors are told to talk fancy.

Cleverness

The reason behind all the jargon, complicated sentence structure, academic language and even Latin is to give an impression of high intellect, of expertise. Half the battle, surely? However, if the great idea is hidden behind too many long, complicated words, the meaning will be lost to too many people. It comes across as cleverness for the sake of cleverness.

Here is an interesting point from Gerry McGovern. In the past, when someone read a sentence they didn’t understand, they saw it as their fault: “I must be stupid.” Now, they see it as the fault of the organisation: “They must be stupid.”

So our audience knows that it is our job to make sure they understand the message. And they are right. We want people to understand what we are doing. We want everyone to understand that we are experts in our fields.

Clarity and brevity

And the trick is that other experts in these fields would much prefer us to use simple language. Another colleague shared this little treat with me.

In 2012, research by Christopher Trudeau at the Thomas M Cooley Law School in Michigan into the use of language found that the more educated the person, the more specialist their knowledge, the greater their preference for plain English. They may understand complicated language but they want clarity and brevity. They simply don’t have time for all those long words.

Professor Trudeau also found that the more complex the idea, the greater the need for plain English. This is a big challenge for us. But it is one we need to overcome. It means that all our producers of content need to understand the idea before they can express it in plain (but engaging) language.

And I haven’t even talked about accessibility yet. I’m going to do that now. Our aim is to be the most accessible university in the UK – both physically and online.

Making our content accessible means using language that everyone understands. And everyone includes the potential student, researcher, business partner, business partner’s granny. They could be 15 years old, they could be 83. They could have a PhD in biochemistry or they could have no qualifications at all.

Beyond our stated aim, we also have a legal requirement to make our website content accessible. There are standards we must meet. Many of these are technical. In terms of the language we use, the standard is simple:

Make text content readable and understandable

Ideally, text should be written to be easily readable by all levels of ability. If we do feel the need to use technically advanced text, we should provide easy-read alternatives to explain what we mean.

So call a spade a spade. Don’t call it a long-handled slab of sharpened forged steel.

Writing tools

There are a couple of tools you can use to test your language. These tools will judge you on your sentence length and structure, use of passive voice and word choice.

Within Word, you can access readability statistics through File/Options/Proofing. Tick Use readability statistics and OK that. Then use the grammar check (F7). You will have to go through the checks but you will then get a list of statistics. These include Flesch reading ease. You should be aiming for a score between 60 and 70. By complete accident, this blog scores 65.

You can also use Hemingway Editor, which will give you a readability score. This relates to the education level (US grades) required to understand your text. The app judges this blog to be readable by sixth-graders. They are 11 to 12 years old.

Support

For anyone across the University who is producing content for the website, we do offer Writing for the Web training. This gives you an idea of the type of language you should be using. Contact digitalsupport@derby.ac.uk.

And the general Style Guide for Writing is available on the Marketing and Student Recruitment page on staff ID Intranet @ Derby (under Professional Services).

There is also a useful piece from the Government Digital Service’s senior writers with ten tips for writing for blog posts, opinion pieces or presentations.

How To Write The Perfect Alt Text

What is alt text?

Alt text is the descriptive text that is supplied alongside an image in a website. It is the text that is used if an image doesn’t load or for other reasons may not be visible to our users. As they aren’t often seen, they are easily overlooked, however, for sight-impaired users they can be an absolutely essential part of your web page. Blind or partially sighted users, for example, will probably rely on a nifty bit of software built into all mobile phones and most browsers called a “screen reader” which will read a web page’s content out loud, including the alt text. So you can see that it’s absolutely vital that they are well written so that everybody has the opportunity to understand our content equally.

Additionally, accessibility is the law. There is a requirement for websites to meet minimum accessibility standards. As a University, our aim is to not only meet but exceed those targets, not just because the law requires it but because it’s the right thing to do.

Writing the perfect alt text

Take a look at the following image taken from the University’s website which we’ll use as our example:

A smiling female University of Derby student sitting on a settee in halls holding a mug of coffee

First and foremost, alt text needs to describe the image. It should help users who read it to understand the content of the image. There can be a tendency to write alt text in a way that supports the content of the page but doesn’t describe the image. For example:

“Find out more about our halls”

This kind of thing is no good at all. That won’t help anybody understand the content of the image. It tells us that we’re looking at the accommodation section – but we already know that. It tells us nothing about the image. A much better alt text would be:

“Woman drinking coffee.”

We’ve immediately given the alt text purpose. It’s describing the image. It’s still not great though. We should try to give the image some context. Images on our website should tell a story; they should have a reason to be there. How about:

“University of Derby student drinking coffee”?

Better. We’ve given the image some context. This is no longer a picture of a random stranger drinking coffee, this is one of our students drinking coffee, which makes more sense in the context of the website. Of course, there’s still an issue with this. This alt text could also describe any of the following photos:

A group of alternate photos about coffee to show that alt text can be ambiguous

The recommended maximum number of characters for alt text is 125, as a lot of screen readers will stop reading out the alt text if it’s longer than that. Let’s see if we can use some more of those characters to give our alt text some clarity:

“A smiling female University of Derby student sitting on a settee in halls holding a mug of coffee”

Now that’s an alt text, and we’ve only used 97 characters!

We’ve described the image in a way that makes it distinct. We’ve given it context within the page and we’ve described the content of the image in detail. If you’re struggling to write an alt text, it might be useful to find another image that’s thematically the same and try to write alt text that fits your image but not the other. A bit like spot the difference. Use a character counter to check the length of your text – you’ll be surprised how much you can fit in just 125 characters!

When to not use alt text

There are a couple of situations where you may not need to add an alt text to an image:

If the image is purely decorative or structural. For example, if you have a fancy underline that’s been done as an image or perhaps a background gradient image. Those images don’t convey any meaning, so they won’t need an alt text.

If the image is already fully explained by the supporting page content. You might have a bar graph that is supported by a table. You wouldn’t need an alt tag for the bar graph as its content is fully supported by the table.

If you’re a web developer, it’s important to remember that the alt text property itself should always be included to meet accessibility requirements but, in these cases, it can be empty.

As a general rule of thumb: if in doubt – use alt text.

In summary:

There are some basic rules that you should follow to make sure your alt text is truly outstanding:

It needs to describe the image
It needs to give the image context within the site
It needs to be fewer than 125 characters
Do not use phrases like “image of” or “picture of”, let the screen reader handle that

This blog is about how we can make our website as accessible as possible

Do you understand what this blog is about? If you believe it will give you information about how we can make our website as accessible as possible then the title has done its job.

I have, obviously, over-egged the pudding to make a point [do you all understand that metaphor? If not, it is not accessible]. But the first step on the road to an accessible website is to have a title for each page that tells the reader what they can find on the page. And that continues through the initial content, the subheads, the images, everything. At no point do we want our audience to be wondering what our page is about.

That is the first stage of accessibility. And it is also the first item in our content checklist titled How to achieve AA accessibility rating:

Your web page must have a title that describes its topic or purpose

You will be thinking that goes without saying but one of the biggest blockers for accessibility is assumed knowledge.

A short story

Let me tell you a story. A short one.

I put together a list of 15 points specifically relating to content and how to make it accessible. I shared this list with a few people and asked for feedback. I was slightly embarrassed to get replies back saying: “What does this mean?”

Clearly my list wasn’t accessible. Not everybody knows what an “alt tag” is and what it does. I do and had assumed everyone else did as well. The checklist has now been updated with better descriptions. But that doesn’t mean it can’t be improved. All feedback welcomed.

It’s the law

We have an approaching legal requirement to make our website accessible. And we need to achieve an AA accessibility rating. We have put together our content checklist on the Web Content Accessibility Guidelines (WCAG) 2.0. This is what WCAG says about accessibility:

“Following these guidelines will make content accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity and combinations of these. Following these guidelines will also often make your web content more usable to users in general.”

Our checklist

And this is our AA content accessibility checklist:

Your web page must have a title that describes its topic or purpose.
All images must have “alt tags”. This is a description of the image and can be added in the Media Library in the “Description” field. NB when creating a media gallery, ensure you use a different description for each image.
The purpose of each link on the page can be determined from the link text alone. Do not use simply ‘Click here’ or ‘Read more’.
Use easy-read alternatives to technically advanced text. Ideally text should be written to be easily readable by all levels of ability.
Only play sound if user activates it [unless there is a good reason otherwise].
Do not rely solely on shape, size, visual location, orientation or sound for understanding or navigation. Eg avoid content such as “click on the triangular button on the right when the music starts”.
Do not change context (eg go to another page, play video) unless this is activated by the user. We want our users’ journey through our website to be as predictable as possible.
Provide submit buttons to initiate change of context (eg go to another page, play video) and warn users in advance when opening a new window [opens in new window].
Avoid images of text as these cannot be read by screen readers (logos are OK – with the appropriate alt tag).
If language changes within the text, mark it in the source code so it is recognised by screen readers. Eg if there is a paragraph in French, use code <p lang=”fr”>Il y a un paragraphe en francais.</p>
Information conveyed by colour differences should also be explained in text. For instance, the following four points are technical and will need to be discussed with video/audio providers.
Provide a text transcript of audio-only content.
Provide captions for all prerecorded audio/video content. Note: captions include subtitles plus text to describe important sounds.
Provide a second audio track on all prerecorded video to provide audio description – or a second version of the video with audio description.
Provide captions on live audio content.

What’s next?

We are testing our accessibility regularly using the SiteMorse platform and updating our pages where necessary.

We are also taking steps to improve our methods and our content types as we learn more about what is required. For instance, users can now toggle captions on and off on video within the website, and we now have the provision to add text transcripts to video files. We are also investigating the possibility of users being able to toggle to pared down, less visually noisy versions of pages. Every day’s a school day.

A close-up of the YouTube caption button

What we need now is for our content producers to make sure any new content achieves these AA standards.

All new video we upload to the website must have captions and we also want to add a full transcript of what is said in our videos. By the time the law applies to us, we need to make sure EVERY video, new or old, on our website has both of these features. NOTE: We cannot rely on YouTube’s auto captions. They seem to work OK a lot of the time but will then say something jawdroppingly embarrassing. We do not want this. We now have guidance on how to correct subtitles and create transcripts.

Accessibility is a challenge and one we intend to meet well before it becomes a legal requirement. The bigger challenge is to make sure the website is accessible while also being appealing and engaging to all our users.