Tag: A11Y

Posted on

What’s in a name?

People who use assistive technologies, such as a screenreader or speech-recognition software, need to know the names of interactive elements on the web. Otherwise they may not be able to recognise the thing they’re dealing with, and so be unable to interact with it.

Which means we, as authors, need to give things meaningful accessible names. How does this happen?

Under the hood

Browsers (and, through them, assistive technologies) get accessibility information through something called the accessibility tree. This is a kind of stripped-down version of the Document Object Model (DOM), a representation of the web page that browsers use to render the page.

Screenshot of developer tools open on a web page ahowing the accessibility tree
The accessibility tree for the homepage of this website. The accessible name is shown in the panel on the right

While the DOM contains everything needed to render the page, the accessibility tree doesn’t need to know about things like styles, colours, fonts, and shapes. Instead, it focuses on four things:

  • description
  • role
  • state
  • name

It’s the last of these, the name, that assistive technologies use to announce things. But how do they get them?

Continue reading “What’s in a name?”
Posted on

Standard accessibility acceptance criteria 

This is based on a document I wrote several years ago, a proposal to standardise test acceptance criteria for our quality assurance process.

Scottish Enterprise's device testing lab has a variety of different devices, from desktop to mobile and everything in between, all displaying the same content simultaneously.
Our test lab, from a few years ago

I deliberately avoided any reference to WCAG guidelines or success criteria – instead, I chose to keep the focus on the user experience, what they should be able to perceive, understand, and do, in that scenario.

It didn’t really get anywhere, but I came across it the other day and thought I may as well publish it; perhaps someone can make use of it.

It’s written in gherkin format, because that was what we were using at the time. But it could be adapted to any format you need

This is far from perfect. I welcome contributions from others more knowledgeable than me. Especially people with lived experience.

Continue reading “Standard accessibility acceptance criteria “
Posted on

The disability myth

Saying “No-one using our service has accessibility needs” is a bit like saying “We don’t need a ramp, no-one in a wheelchair has ever come up the stairs”.

An access ramp in a modern structure with large sloping glass windows admitting plenty of light on a sunny day.
An accessible ramp at Glasgow Queen Street train station. The long, low rake helps wheelchair users but also people pushing prams, or a bike, or – as in this case – a heavy suitcase. Basically, it makes life easier for everyone.
Continue reading “The disability myth”
Posted on

Who are we willing to exclude?

A screenshot of a whiteboard with posit notes all clustered in the leftmost column

This is an exercise I like to run at the start of any project.

It’s based on a tweet a long time ago by Jamie Knight (and Lion, of course) which I can’t/won’t link to because, well, twitter. You can read Jamie’s bio on their site or LinkedIn profile.

The exercise is simple. At the start of any digital project, get the whole team – devs, testers, writers, designers, stakeholders, literally anyone you can round up – together, in-person or virtually, and ask the question:

Who are we willing to exclude?

Continue reading “Who are we willing to exclude?”
Posted on

Providing text alternatives for non-text content

I recently ran a session with some of our content developers covering alternative text, and the difference between alt text and captions. It seemed to be well received, so I thought I’d write it up.

A screenshot of HTML code showing markup for a <picture> element
Modern web design includes a variety of techniques to provide text alternatives for non-text content. In this example, a <figcaption> provides additional context,

“Text alternatives” is the first guideline of the first principle of WCAG 2.1. It’s literally the first thing to think about – and the reason why is pretty simple: not everyone can see images.

That may be because they have a vision disability. But it could also be because the image has been deleted, renamed or moved. Maybe their network connection is poor. Or their browser doesn’t support the format. Or they have disabled images in their email client because they have a 500MB monthly limit.

Whatever. It happens. Text alternatives are what users rely on when images are not available. Like this one right here:

This image is not available

The alternate text needs to replace the image. So your question becomes very definite:

What text do I need to provide if this image is not available? How might I describe the appearance, purpose, function, or meaning of this image to someone who can’t access it?

Continue reading “Providing text alternatives for non-text content”
Posted on

On alternatives

This is for everyone

Tim Berners-Lee

As a content author myself – I am, actually writing this, with fingers – I know it can be hard to choose how to provide alternative text for non-text content.

Do you go full-on and launch into a full description of the image? Or is just a brief alt=”cat” sufficient?

Delicate white blossoms against blue sky.
Tree blossom

So, how would you choose to describe this image to someone who can’t see it?

I gave it a <caption>Tree blossom</caption>, and alt=”Delicate white tree blossom against a clear blue Spring sky”.

Is that perfect? Probably not.

I don’t pretend to understand the lived experience of people whose experience is not like mine.

Then I stumbled across An alt text decision tree on the w3c website.

And I thought, “this looks handy”.

And it is.

Continue reading “On alternatives”
Posted on

How to create accessible Word documents

First, some definitions

An accessible document is a document that people with a range of physical and cognitive impairments can read and understand.

An accessible document is, typically, also a document that people with no physical or cognitive impairments can read and understand better, and faster.

Also typically, an accessible document is easier for content authors to maintain. Because it uses tools that are baked in to Word and other MS Office applications to support accessibility and improve workflow.

So, here are some tips on creating accessible Word documents.

Continue reading “How to create accessible Word documents”
Posted on

Accessibility – Sharing knowledge between organisations

Using Skyscanner and Scottish Enterprise brand colour palette to show the same visual explanation to a11y being used for short for accessibility
Accessibility can be written as a11y for short — 11 is the number of letters between the first and last letters

Heather Hepburn is the Accessibility Lead for Skyscanner and has been running their accessibility programme for just over a year.

Stéphanie Krus works as a Service Designer and is a member of the ‘Disability Positive’ group at Scottish Enterprise.

We ‘met’ virtually in October 2020 after a talk at the UCD Gathering from Heather Hepburn (Skyscanner) and Adi Latif (AbilityNet): “Digital Accessibility – How to get your organisation on the right track” 

We realised we had a lot we could share regarding how we address and improve accessibility in our organisations.  So we planned a knowledge sharing session which was held online on 27 January 2021 with about 20 people.

Continue reading “Accessibility – Sharing knowledge between organisations”