{{ searchResult.published_at | date:'d MMMM yyyy' }}

Loading ...
Loading ...

Enter a search term such as “mobile analytics” or browse our content using the filters above.

No_results

That’s not only a poor Scrabble score but we also couldn’t find any results matching “”.
Check your spelling or try broadening your search.

Logo_distressed

Sorry about this, there is a problem with our search at the moment.
Please try again later.

Accessibility is an important topic in web design, but one that previously hasn't been covered on the Econsultancy blog.

To rectify this omission, I'll be writing a series of posts exploring how to make your websites more accessible from the outset. 

In this first post we’ll look at creating a design that people with visual impairments will hopefully find easy to use.

Put simply, the quality of the HTML you use to write your website is as important as how it looks visually.

Sure, you’ll have been told that your “HTML must be semantic”, but what’s the underlying reason, and who does it affect if it isn’t?

And, for that matter, what does that even mean?

What are semantics?

To understand why semantic HTML is so crucial, we first need to define what the term ‘semantics’ means in the context of a web application.

In the general sense, semantics can be described as

...the branch of linguistics and logic concerned with meaning.

When using a website, humans associate meaning with parts of the page through a variety of senses - visually (via the browser interface), aurally (if you use screen readers for example), or through touch (Braille output devices).

How do they apply to my website?

Since you have visitors who use assistive technologies, providing a quality interface for them to consume your content should be a default position. We will discuss how to do that in a later post. 

In terms of website interaction, two distinct interfaces are used to convey meaning to the user.

The portion of your user demographic who use browsers such as Chrome or Firefox and rely solely on visual cues will be inferring the meaning of the page purely from its visual design language.

However, users of some assistive devices such as screen readers will be reliant on the semantic nature of the HTML to deduce the same meaning.

Assistive devices and machine readability

Assistive devices can use a number of mechanisms that infer meaning from HTML. These include:

  • A hierarchy-inferred representation of the page referred to as the document outline. It relies upon important structural elements to build up a structure of the document that can be used for presenting the document in many different ways. 

    A typical example would be OSX Voiceover’s ‘web rotor' feature, which presents the user with a list of ‘landmarks’ within the document that allows quick navigation.

  • A high-level composition that includes an enriched document object model (DOM) representation, as well as objects from the user interface - referred to as the accessibility tree.

    I highly recommend Léonie Watson's article on Accessibility APIs that goes into more depth on the subject.

With great power, comes great responsibility

In essence, conveying the meaning of an application's composition regardless of device, has always been a fundamental concept of the web.

A common pitfall which results in a website being inaccessible, arises from developers not understanding the distinction between describing meaning (the role of HTML), and describing the presentation of that meaning (the role of CSS).

This separation between presentation and content is incredibly powerful, as demonstrated by CSS Zen Garden - a showcase of a variety of visual designs that use the same HTML structure.

Conversely however, this also allows a fixed aesthetic to be typeset into virtually any number of HTML structures, incorporating varying levels of semantic quality.

This can result in a disparity between what is visually displayed and what is conveyed to assistive devices.

So next time you’re creating a new component, start by describing what you mean, not what you see.

How does this still work if HTML is so old?

The web sphere has evolved quickly due to technological enhancements, and rich internet applications that have many of the characteristics of desktop applications are commonplace nowadays.

Since those user interfaces comprised more complex HTML structures, however, they became difficult for assistive technologies to infer their intent without using some level of heuristic analysis.

For example, how can you signify to a screen reader that a portion of your page needs to be re-read due to some content having been dynamically updated?

Or that a value you’ve typed in a form field is of an invalid format?

Moreover, the HTML specifications aren’t flexible enough to include current user interface trends. The answer is mirroring the accessibility model of conventional desktop-based applications.

Copying the desktop application model

Modern operating systems include an accessibility API whose job it is to represent entities within a user interface and expose information about each to consumers such as assistive devices.

For example, a menu button might be registered with a name ('Edit'), its state (is it pressed in or not?), and a role (a menu item).

In order to construct this representation, accessibility APIs interface with an accessibility tree, which is a composition of the current user interface.

Enter ARIA

Accessible Rich Internet Applications (ARIA) is a specification that deals with how to make dynamic applications more accessible.

It co-exists alongside HTML and other markup languages as an entirely separate standard, allowing it to evolve independently.

Once previously impossible, we are now able to directly manipulate the accessibility tree through the use of a series of HTML attributes, resulting in a direct connection between HTML components and their equivalent types on the operating system.

This allows for the potential of complete parity between the experiences of web and desktop applications.

An example demonstration is available that demonstrates how easy it is to compose two HTML structures that could visually look the same.

Putting it to the test

To fully understand the importance of the subject, I’d implore you to choose a screen reader (Voiceover, JAWS, NVDA) that is supported by your OS, and spend half an hour learning some basic navigation skills.

After that, try reading your favourite website; if you’re a user who is able to use visual cues, then blindfold yourself and read a portion of the page, and compare the experience with the visual semantics.

How do they relate to one another?

In summary...

When composing HTML structures, you must ensure that you describe its meaning using the correct HTML elements, and ARIA state and role flags where necessary.

Then, and only then, should you pay attention to the presentation of those structures.

James Hopkins

Published 14 March, 2016 by James Hopkins

James is a Software Engineer at Red Badger and a contributor to Econsultancy.

3 more posts from this author

Comments (6)

Comment
No-profile-pic
Save or Cancel
Hazel Bolton

Hazel Bolton, Content Manager at Formisimo

James, I think it's brilliant that you're adding posts on accessibility to Econsultancy. It's such a popular blog, it'll help to spread the message far and wide.

I've written on accessibility and webforms in the past. It's not only people with visual impairments that find it hard to access content online. Hopefully you'll highlight the scope of accessibility too.

Looking forward to the other posts in the series.

4 months ago

Avatar-blank-50x50

Matt Terrington, Digital Projects Manager at Imperial College London

Definitely agree that it's great to see the importance of accessibility written about on this blog, alongside all the other brilliant advice. One area I'm personally struggling with is how to marry up fancy data visualisations (https://econsultancy.com/blog/tags/data-visualisation/) with accessibility for visually impaired users.

Does anybody have any nice case studies or examples of this working really well?

4 months ago

James Hopkins

James Hopkins, Software Engineer at Red Badger

@Hazel: Cheers for the feedback! Indeed - the scope of the term "accessibility' is far and wide, and reaches into many spheres - a topic that will be touched upon in the near future.

@Matt: The level of accessibility that can be achieved in the realm of visualisations depends very much on the technology used to generate them. For example, AFAIK, Flash allows for a very limited level of accessibility. However, an SVG-based visualisation can be introspected by an assistive device in a similar way that HTML can be. Moreover, since SVG supports ARIA, additional semantic meaning can be added for this purpose. Hope this helps!

4 months ago

Ben Davis

Ben Davis, Senior Writer at EconsultancyStaff

Great post, James. We certainly don't cover this area enough (nor do many), but we have previously posted about accessibility. See the following (hopefully still-relevant) posts:

Five quick checks for your website's accessibility
https://econsultancy.com/blog/64846-five-quick-checks-for-your-website-s-accessibility

Style and substance: two (accessible) websites which have it all
https://econsultancy.com/blog/63283-style-and-substance-two-accessible-websites-which-have-it-all

New BBC interactive guides: responsive, dynamic and accessible web design
https://econsultancy.com/blog/64215-new-bbc-interactive-guides-responsive-dynamic-and-accessible-web-design

4 months ago

Avatar-blank-50x50

Brandon Biggs, CEO at Sonja Biggs Educational Services Inc

James the best way I have found to communicate that a website is not accessible is by asking someone to copy and paste their website into a txt file. If they are still able to understand what is going on in their website after the copy and paste, then so can I as a screen reader user. This almost always works. With the wider use of aria it is a little different, but even still, the buttons and whatnot need to have text in them in order for me to read what is going on. Most websites do not have aria and that is how it should be. HTML is still the most important way of presenting information. I see a website as a vertical document with links and search boxes at the top, the text in the middle and the footer and copyright links at the bottom. There is no sense of left middle or right. This means that if there are no headings (<h1>) then I need to start at the top and arrow all the way down in order to find the information that I am looking for. If there are too many headings, then I get lost and frustrated. Websites such as Trip Adviser are a blind person's worst nightmare. They have everything on one page and I can never find a thing. But the most common part of a website to not be accessible are the sharing links and edit boxes. Even accessibility websites do not label their edit boxes right and most WordPress websites do not label their sharing links.
NVDA has a nice little feature developers can use in the NVDA menu under tools and speech viewer. This is a little window with the text the screen reader is reading. Screen readers can only see one line at a time, so just expand this window to the full screen and only read that one line and you will get a feeling of what it is like to use a screen reader.
(*note* posting this comment is incredibly difficult because after I click the post button it is not clear where to go, neither the headings or the links say, it is as if I am at the top of a website with no body. Sometimes I get placed on a search page by just arrowing over something).

4 months ago

Avatar-blank-50x50

Brandon Biggs, CEO at Sonja Biggs Educational Services Inc

This is a great article and super important. The best test I have found is if you can copy and paste your website into a txt file and read it, then so can a screen reader. Another thing to keep in mind is a screen reader reads from top to bottom. There is no concept of right, center and left. A website starts with links, has a body and ends with links and the copyright. But by far, the most prevalent problems with websites are:
1. the lack of or over prevalence of headings. A webpage should have no more than 7 headings.
2. lack of correct labeling for edit boxes. The for tag is not always set in the label for an edit box, so it is sometimes incredibly difficult to figure out what an edit box is for.
3. Sharing buttons are almost always blank. See this website for an example!
A great example of buttons not being labeled and how copy and paste can show this are the sharing buttons above this article. Here is the sharing area copied and pasted:
Share

BTW I'm having my dad post this comment because the page that shows after I click the post button doesn't have a body. It's just a bunch of links and headings that take me to different places on this website.


81
14 March, 2016

There are 4 buttons, but I have no idea what they are. Also, what is that 81?

4 months ago

Comment
No-profile-pic
Save or Cancel
Daily_pulse_signup_wide

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Daily Pulse newsletter. Each weekday, you ll receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.