Exploring Website Accessibility: Part 2

Introduction

So in part 1 I created two websites, one of which adheres strictly to the various accessability guidelines that have been published by numerous authorities, the other of which pretty much goes out of its way to ignore them all. In this part I’m going to go through exactly what makes the good version “good” and the bad version “bad”, and I’ll show you exactly what the consequences are of coding sites the bad way by showing the output from a screen reader. In part 3 I’m going to go through the correlation between accessible websites and other more well practised web techniques such as SEO and the user experience.

So just a quick recap then, here is the code for both sites;

And here is what they look like when rendered;

We did briefly touch on the fact that, to the untrained eye, the bad version “looks better”. Unfortunately, I believe that this fact is chiefly responsible for all of the awful web coding that goes on in the world, and for the number of people who assume that knowing HTML keywords means they are suddenly a web designer. HTML is, of course, supposed to form the semantic layer of your site. It has absolutely no business “looking good” at all! This is often a bit of a tough sell to web newbies, but hopefully when we look at the results it should convince any non-believers 🙂

So here we go then: Where did the bad version go so wrong?

Noddy HTML code

The “bad version” should have had most professional web designers clawing at the walls. Web standards have completely gone out of the window and what we’re left with is a meaningless blob of text. Whoever coded it has clearly been focussing purely on how the site will look when rendered, rather than semantically analysing each element and selecting an appropriate tag to use. They have also taken the decision of using tables to form the basis of their layout (this is why the site “looks better” than the other version). Additionally there are lists of items which aren’t decorated with a list tag and liberal use of the line break tag.

The reason that coding in this way causes an accessibility issue is that screen readers can also see HTML tags, and help their user by “announcing” that they are about to hear a list of items, or that they are about to hear some tabular data. Because the author of the bad version has thrown semantics to the wind, neither the screen reader or the user will be able to tell whether they are hearing a list or just a plain old paragraph. Even worse, the site will be described to the listener as a table, which causes superfluous announcements which get in the way of the content. The visually impaired user doesn’t really give a hoot if your site “looks fine”, they just want to hear the content and the use of a table layout has wrecked their experience.

In addition, check out the difference in headings between the good version and the bad version. Headings are another element which screen readers will “announce”. This makes it clear to the listener that a new section is beginning. I had also previously mentioned that it is possible for screen reader users to pull up a list of the headings on the page. Each heading should therefore be descriptive of the section that it precedes, otherwise when they pull up their list it’s not going to be much good to them.

Access keys

The bad version hasn’t implemented access keys. As mentioned in the previous article, access keys allow a visually impaired user to use a keyboard short-cut to access certain links and there are well established conventions for which keys should perform which actions. The lack of implementation on the bad version means that the user would be required to either tab through the site until they find what they’re looking for, or they’d have to listen to the whole page being read until they found what they were looking for. Access keys will also be announced by the screen reader.

The good version, on the other hand, implements access keys precisely to specification. In particular note that the key “4” takes the user straight to the label of the search form, and that key “s” skips over the navigation. The good version has also implemented a handy guide as the very first element on the page (meaning that this will be the first thing the user hears after the page title). At this point they are able to infer that this is an accessible site, and may choose to perform one of the common actions such as searching or contacting you.

There are arguments against using access keys though. The first is that apparently some screen readers utilize the same keystrokes and so it is possible to “override” the screen reader functionality with your website functionality, which is completely ridiculous. Hopefully screen reader developers and browser developers will resolve this between themselves.

The other argument against using access keys is that because they are so rarely used, they end up just getting in the way. This is also completely absurd and defeatist, how do you expect to change anything with an attitude like that?

Both of these arguments clearly point to issues with either the browser or the screen reader – I don’t see why web designers should need to code around these failings once again. It wouldn’t be too hard to just implement a “please don’t announce access keys” feature, surely? For this reason, the good version has implemented them, however I have been careful to make sure that all but access key 4 are announced BEFORE the skip navigation key – meaning that if the user skips the navigation then they won’t hear the access keys being announced.

Front loaded paragraphs and content

The screen reader will start by announcing the page title, and then parse the rest of the site as it appears in the HTML document. Lets imagine then, that the user is listening to the bad version of the website. Given that access keys haven’t been implemented, they don’t actually get to find out what the store actually sells until Line 46 of the code, because there’s a whole bunch of marketing crap such as “Do you like cheap deals?” etc. before the site even mentions the types of products it provides. At best, you’ll annoy your user, and at worst they’ll have gone somewhere else before they even get that far.

The good version, on the other hand, gets straight to the point and opens its welcoming spiel by specifying exactly what the site sells and where it sells to. At this point the user can continue listening to the site description should they want to. Also note that the “Navigation” appears after the main site content. This means that the user gets the “main content” read to them prior to the “navigation content”, which makes perfect sense as navigating away from a page is something you would generally do after you’d read it.

Alt text on images

The bad version doesn’t include alt text in the logo image, the good version does.

Images are another example of a tag that would be announced by the screen reader (jaws uses the word “Graphic”). This is immediately followed by the alt text. Before I did much accessibility research, I used to think that putting hugely verbose alt text into an image tag was a great idea – describe the image in it’s totality so that someone listening to the description could picture it in their mind. I’ve since come to realise that this would probably be pretty annoying! Therefore, short snappy descriptions are best.

Marketing Spiel

Sometimes, as a web developer, you hear marketing types constantly mention certain words over and over again to the point that you wish they’d never learned them. Two such offenders are “Call to action” (meaning that the user should be encouraged to take an action once they’ve seen something funky like the price or the product name) and “Above the fold” (meaning things that are visible before the user is required to scroll). Now, there are appropriate uses for both of these; what I have a problem with is not their use but their over-use. Unfortunately when it comes to accessibility, the problem actually gets a lot worse.

The bad version contains three “calls to action”, one next to each of its products. I mentioned in the first article that visually impaired users tend to tab through elements on a page. When the user reaches the “Click here” link, the screen reader will say just that to them. With no understanding of the context, it’s unlikely that the user is going to follow the link, thus your call to action becomes a call to inaction!

The page title also goes on and on about the great deals that the user can expect from the site. Given that it’s highly likely the first time a user sees that title is going to be in a set of search engine results, it is likely that the title has been designed to stand out and be clicked on, as well as being keyword rich. The good version, on the other hand, has a short, plainly descriptive title (which it should be given that it’s what a screen reader will dictate before anything else). Here, tragically, we’ve hit upon a conflict between the interests of SEO and the interests of accessibility, more of which I’ll come on to in the next part.

On to the results!

To show you exactly how the Jaws screen reader would interpret the two pages, I’m going to use a free firefox plugin called “Fangs”. Fangs can provide us with three summaries;

  1. The output that the screen reader would dictate
  2. A list of headings on the page that a user could call up
  3. A list of links on the page that the user could call up.

Here we go then…

Result set 1: Screen reader output

This is what the screen reader would dictate for each of the sites. “Announcements” appear in bold.

The good version:

Page has four headings and thirteen linksHome left double angle bracket My Simple Store dash Internet Explorer Heading level two Accessibility guide List of six items bullet Access key S to skip navigation and this guide bullet Access key four to perform keyword search bullet Access key one For home page bullet Access key six For help bullet Access key eight For Terms and conditions bullet Access key nine To Contact Us List end Graphic My Simple Store Logo List of four items bullet Link Home alt plus one bullet Link Contact Us alt plus nine bullet Link Terms and Conditions alt plus eight bullet Link Help alt plus six List end This page link alt plus s Heading level one Welcome to My Simple Store!! We sell a great range of this type of product in the location you’re looking for. We’ve made thousands of customers happy and hope to do the same for you. Heading level two Our products List of three items bullet Link Product one This product is awesome! bullet Link Product two This product is also awesome! bullet Link Product three Awesome, just like all the others! List end Heading level two Navigation Search our site colon Search colon Edit Enter Keywords Search Site buttonList of five items bullet Link Menu Item one bullet Link Menu Item two bullet Link Menu Item three bullet Link Menu Item four bullet Link Menu Item five List end

The bad version;

Page has one heading and twelve links Awesome Cheap products, fast delivery, Money Back Guarentee dash Internet Explorer Table with one column and four rows Table with two columns and one row Link Home Link Contact Link Terms Link Help Table endTable with two columns and one rowNavigation Search colon Edit Search Site button Link Menu Item one Link Menu Item two Link Menu Item three Link Menu Item four Link Menu Item five Heading level one Welcome to our Website!! Do you like cheap deals? Do you like fast delivery? Do you like awesome quality? Then you’ve definately come to the right place! Check out our store and our amazing offers!!! These are the best products of this type in your location! Our products Product one ! This product is awesome! To view more details, Link Click Here! Product two ! This product is also awesome! To view more details, Link Click Here! Product three ! Awesome, just like all the others! To view more details, Link Click Here!Table end Table end

So which would you prefer? Remembering that with the first one you can just hit alt-s to skip the entire thing (right down to the “welcome to my simple store” heading) I don’t think there’s any contest really.

Result set 2: Heading summary

This is what the user would hear if they called up a list of the headings on the page;

The Good version:

  • Accessibility Guide
  • Welcome to My Simple Store!!
  • Our Products
  • Navigation

The bad version

  • Welcome to our Website!!

Yeah…

Result set 3: The links summary

This is what the user would hear if they called up a list of links, or more importantly if they tabbed through them.

The good version

  • Home alt+1
  • Contact Us alt+9
  • Terms and Conditions alt+8
  • Help alt+6
  • Product 1
  • Product 2
  • Product 3
  • Menu Item 1
  • Menu Item 2
  • Menu Item 3
  • Menu Item 4
  • Menu Item 5

The bad version:

  • Home
  • Contact
  • Terms
  • Help
  • Menu Item 1
  • Menu Item 2
  • Menu Item 3
  • Menu Item 4
  • Menu Item 5
  • Click here!
  • Click here!
  • Click here!

Where’s your call to action now huh? 😛

Closing thoughts

So that’s what a screen reader would output and I will go into more detail on that in the next part. I did just want to mention one thing before closing though: As a web developer you should always be coding for your user. What we’ve done here is attempt to make one site that will work for both visually impaired users and those who aren’t. Even though the “good version” is very accessible, the ultimate solution is and will always be to create a seperate version of your pages for each type of user, this way you can truly code each situation appropriately.

Advertisements

One thought on “Exploring Website Accessibility: Part 2

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s