Posts Tagged ‘accessibility’

I’m pleased to announce the launch of my new course on Web Design Accessibility.

If you want to make the web a better place for disabled people, help improve your conversion rates, and add a valuable skill lt your CV, this is the course for you. We will look at a range of accessibility issues and conditions, the tools we can use to help us and the principles of inclusive design.

The course is usually $99.99 but if you use this coupon link you can register for free as an early bird student. Offer expires Friday!

I’m currently working with a client to improve the accessibility of their website for visually impaired users. This has involved a lot of time working with screen readers. As part of that, I have found a rather weird bug with Mac’s VoiceOver. It keeps saying the word “simul”.

Which isn’t a word. Maybe it’s saying simmul or simmel, or something else. None of these are words.

It happens when we give it a range to read. Something like “4-6”. The screen reader says the first number, then goes suspiciously quiet and says simul, and then starts building back up to regular volume as it gets to the final number.

I even asked about it on Stack Overflow, and everyone else was confused, too.

I wondered whether it might be a language issue. So, I tried adding a custom pronunciation, and double-checked the HTML tag had a lang attribute set to en-gb. Alas, no luck.

This is only a problem on Mac: TalkBack on Android works fine, for example.

In the end, I was able to get it to read correctly by changing the voice. By default, macOS comes with Daniel Compact set as the voice. However, when I switched to Daniel, Kate, or Kate Compact, it read it out correctly.

In a way, this is frustrating, because there is no much we can do to fix it. It’s a bug with the voice in Mac. But it is at least somewhat comforting to know that I wasn’t making some obviously silly mistake.

You’re trying to make your website accessible. Lovely stuff. But because screen reader technology is so bad, you need to add a bunch of inline span tags with the aria-label attribute on them so that you can add additional context, or, more usually, use some kind of hack to get around a screen reader bug.

This works well. However, it also splits the whole thing into separate groups. Consider the following example:

An annual subscription costs £20.00 per year.

Looks good. Except for VoiceOver on Mac and iOS, and probably other screen readers, too, will read out something like this:

Pound two zero zero zero

Oh no! It totally ignored the decimal point and now your user, if they are able to track the weird way it read out individual numbers, thinks that your product costs two thousand pounds. So, our old friend the Aria label is here to help.

An annual subscription costs <span aria-label=”twenty pounds”>£20.00</span> per year.

Hurray! It now sounds like normal language. But it’s still confusing. Now the screenreader reads them out as three separate blocks. “An annual subscription.” “Twenty pounds, group.” “Per year.” The user has to navigate through all three of them even though it is one sentence.

The fix

To fix it, we can use the role attribute. Sometimes.

If we set it to role="text" it will work in WebKit. For example:

<span role=”text”>An annual subscription costs <span aria-label=”twenty pounds”>£20.00</span> per year.</span>

Now it will read out the entire sentence as one string, but still using the Aria label.

Is role=”text” a thing?

No. That’s the drawback. it was proposed to be included in the Aria spec, but nobody could agree on whether it should be a thing or not. So, it was left out. Therefore, it is not implemented everywhere.

It is implemented in WebKit, so will fix the problem on Chrome, iOS, etc. But it won’t fix it in some other browsers. And, you might get pulled up by linting tools and validators because it is not part of any formal specification.

Where can I put it?

Anywhere you like given that it is a made up attribute.

But there are some things to be cautious of. It should only go on a block of text where you do not mind losing any of the context inside of it. If you have an element inside the paragraph, for example, that should be treated as a separate group, then leave it off.

It shouldn’t on headings because you don’t want to lose the context. Instead, put a span tag inside the heading with it on.

Also, you need to ensure you are using the aria-label attribute for anything inside. Normally, you can use an abbr tag with a title attribute and the screen reader will read out the title. However, if you wrap it in a role="text", this will only work if you use an aria-label instead/as well as the title attribute.

Making your website accessible people who are visually impaired isn’t sexy or glamorous. But it is pretty easy. And given how prevalent visual impairment is, especially among the elderly (which, all e-commerce operators should note are the people with all the money), it is time well spent.

Here are four tools that will help you tune up your website.

W3 HTML validator

Assistive technology is already out there helping people. All you have to do is provide it with the correct input. And that starts with following HTML standards. And, where possible, using semantic HTML5 tags.

These work in everything except Internet Explorer 8 and the number of users who make use IE8 is now lower than the percentage of people with visual impairment. Plus, it’s very easy to add backward compatibility in.

Once you have done this, run it through W3’s HTML validator tool. This will check that your code makes sense and so everyone’s browsers (visually impaired or not) will be able to read it correctly.

Click here to go to the W3 Validator.

WAVE

WAVE stands for the Web Accessibility Evaluation Tool. It’s an online tool that has been running since 2001 and is considered one of the best ways to test how accessible your website is.

All you have to do is enter the URL of your website and WAVE will give you a full report, including helpful suggestions and things to fix. You get a copy of your page highlighted with the information to make it easy to find.

Like everything on this list, it’s free.

Click here to access the tool.

a11y.css

This is a bookmarklet that scans your page for problems. If you are not familiar with a bookmarklet, it is a magic bookmark: you save it to your favourites and then when you click it, it will run the report on the current web page you are browsing.

It highlights areas of the page with possible errors that you can then review. It’s quick and simple to use but doesn’t offer as much depth as WAVE.

Click here to check it out.

MDN documentation

The Mozilla Developer Network is the de facto authority on how HTML works. This includes documentation on the ARIA standard, which is a standard designed to make web applications more accessible.

Even Mozilla’s documentation is rather hard to penetrate, but if you bare with it, you can get your head around it.

Click here to read the ARIA documentation.

Summary

Making your website accessible is pretty easy: it’s all about following standards and best practice, and maybe adding a few HTML attributes if you have code doing fancy things.

Doing so makes your website much easier to access for the visually impaired, which will mean a better world for them and more traffic for you.

There is nothing like reading an article on the website and finding it one of the best you have ever read – you immediately want to show to it other people. You flick the switch on your printer to on, hit Control + P and prepare for it to emerge. But what do you get? A mess of DHTML, adverts or half the text missed off the edge of the page.

You could always hope the visitor turns their page to landscape but with the length web pages usually turn out like it is not very likely. Save them the trouble of having to print selection or copy and paste into a word processing package by making your pages printer friendly for them to print straight from.

Making them friendly in the first place
There are two main ways to allow visitors to print the pages easily. The first is to make the original web page with the article or content on, the right size to be able to print. For liquid width sites this is ok as long as they can condense down although for fixed width sites this is not as easy.

Generally you have a width of about 600 pixels, which the users printer will print. This is good if you have a navigation or sky scraper advert down the site taking the last 200 pixels of your page as the user does not need these printing. Although if your article goes all the way to the edge its time to rethink the design.

One way of getting round this would be to have a link, which chances the width of the page. The user clicks a link to say somepage.php?mode=printer. Then you could have something, which says if the mode is set to printer the page width is altered to 600 rather than 800 pixels using server side scripting. This could also be done to a certain extent using JavaScript so the page will not always have to be reloaded although in some browsers it may have to be and there is more chance of it going wrong.

The printer friendly page

This is a more common solution to the problem of visitors not being able to print. All you have to do is set up a separate page without all your adverts, logos and navigation, which is less wide or uses a liquid width so that the user can print this.

Generally you wont want to include adverts on this page, otherwise visitors may not use it at all as they can remove the ads themselves using print selection or copy and pasting the text. However you may want to include your logo and visitors won’t mind and it increases branding when the article is passed around.

If your articles are static then you may end up creating a separate page for each of these but if your articles are dynamic, most likely stored in a database you will simply be able to make a dynamic page just like your main article page for the printer friendly page and link them together.

Making it usable

Whatever solution you use you may want to include a print link to. This will encourage users to print the article simply by clicking the link, as their finger will already be on the mouse button, so users who would not normally print the article may give it a click.

Another good point about users printing the whole page rather than copy and pasting the text into a word processor is that the URL of the page will be at the bottom so other people who read it will see it and when the visitor looks at it later they will remember your website.

So you’ve designed your perfect homepage. The only problem is that it doesn’t fit on anyone’s screen but yours. Suddenly you are finding you have to redesign your site so it is more accessable to everyone and your amazing designs and idea’s are laid to waste.

When first building your website you need to decide how wide your going to make it. If its just formatted text going across the screen then you are ok, but for most of us, we need to set a width for our tables and layers which is bound to cause problems somewhere along the line.

100% width

The easier way to make a site fit is to set the width to 100%. It will stretch across any screen so no problems you say. However its not as simple. Designing a site with 100% width is not always that easy as you have to make sure everything will squash down – no point using 100% width if your images won’t let it go down futher than 900 pixels.

You still really need to pick a width as any images and menu’s that make your site wide will set the width for you. People on 640 X 480 screens with browsers in shrunk mode would probably like your site to squash down to about 400 pixels. Test if your site will do that (though don’t worry if it won’t).

100% width works good for sites such as Microsoft.com and Worfolk.biz who have a lot of product information and so use text with can go across the screen and still squash down easily.

700 pixels width

This is the site I use for most of my sites. I use it because I can fit a banner into it and still have room for a 200 pixels wide logo next to it. The only problem with doing this is that its slightly too big for people with 640 X 480 screens and slightly too small for 800 X 600 screens. I consider it a nice balance though.

A lot of sites go for a 800 pixels wide screen so that it wil fit on a 800 X 600 screen now as people using 640 X 480 are become rarer quickly – I’ve been using 1024 X 780 for years now. Ever Yahoo is now to big to fix on a 640 X 480 and has been for a while too.

A fixed width site works well for sites which have content in the right place, all neat and correctly laid out in sections such as Msn.com or Mworld.us.

Other options

MSN use javascript to show hide layers. If you read Java Junky (MXL Magazine column) then you will know what this is about. Bascially if the browsers screen is big enough, they add extra information dowen the left column – Full screen your browser on one of the channels and then shrink it to a fairly small size. Some content should disappear (probably the channels menu) from the right hand side.

They also have a script on their homepage so that it rearrages the content for people with 640 X 480 screens so it fits on them while using up the space nicely on a 800 X 640 screen.

Conclusion

If you site isn’t almost all text then go for a set width such as 700 or 800. If you don’t have any menu bars or extra content down the side then you might even want to go for 600 pixels like Worfolk Online uses (or used to use depending on whether it has changed since I wrote this). Test it out on different screen sizes and see what looks good. Check out what the competition does. When you’ve found something you like – stick with it.