Digital Web Magazine

The web professional's online magazine of choice.

Understanding Disabilities when Designing a Website : Comments

By Leona Tomlinson

September 16, 2008

Comments

Mark Wyner

September 17, 2008 10:00 AM

Excellent. An article that needed to be written. Nice work.

Eric D

September 17, 2008 12:40 PM

Very good job in summarizing these considerations. Oftentimes accessibility can seem overwhelming to designers and developers, but this is just a common sense checklist. Thanks for the resource!

Tor Løvskogen Bollingmo

September 17, 2008 1:31 PM

Nice article, a good read. About the alternative text (alt text) – if you leave it empty, you would get an error in the validation of the HTML, what if you used a single space, would that work for the screen reader and the validation?

Mosey

September 17, 2008 10:34 PM

Thank you for this article. I’m in the middle of revamping one of my main sites and the tips are really very useful and easy to follow. I really hope I’ll be able to use most if not all of them!

Surdeep

September 17, 2008 10:49 PM

Thank you for a cracker of an article, it really makes sense and provides a good checklist, I’ll surely use it in all my future work. Keep up the good work.

Tomaz B

September 17, 2008 11:55 PM

Thanks for this article. It will contribute a lot to my future work.
One thing though – what about CAPTCHA images in forms and vision impaired people? You take a blind person successfully through a whole form and then…he comes to CAPTCHA image that he can not see and it has no alt description. How would this be solved?

Timex

September 18, 2008 12:10 AM

just a quick note on form instructions: we found out that adding the label tag to the form field requirements (which are oftentimes error messages) help people using assistive technologies. especially screenreaders read out the label element loud, so you can apply the form instructions to the corresponding form element. and don’t mind using the same label tag twice, it works well across different screenreaders and even validation tools are fine with it.

MiSc

September 18, 2008 3:00 AM

I just sent a memo to all my colleagues, that actually dealt with some points on your list. However, I found it useful to differenciate between what designers, developers and editors can do.

Gregg Moore

September 18, 2008 4:51 AM

Thank you so much for sharing this article with us. I have picked up a lot of valuable information that I need to start implementing into my web sites.

Again, thank you!

David Owens

September 18, 2008 6:01 AM

Hi,

@Tor Løvskogen Bollingmo

There is no need for an empty space. Using alt=”“ will validate fine.

HTML 4.01: How to specify alternate text

@Tomaz B

I’m not sure CAPTCHA can ever really be an accessible solution. Maybe we need to start thinking of better ways to confirm somebody’s authenticity.

There is a good article on the UK’s Guardian website about why CAPTCHA doesn’t really work,

How Captcha was foiled: Are you a man or a mouse?

and there are a few interesting discussions on the accessibility implications and alternatives.

CAPTCHA – if your name’s not down you’re not coming in

Inaccessibility of CAPTCHA: Alternatives to Visual Turing Tests on the Web
Spam vs Accessibility

DesignerDad

September 18, 2008 8:27 AM

This is probably the best article I’ve read on designing with disabilities in mind. Much of what was covered is often overlooked in other articles. Nicely written.

IDS

September 18, 2008 6:39 PM

Very good article. One growing industry that has been challenged to find creative solutions for web accessibility is Education. Having worked in the e-learning world for quite some time, I can tell you that this article is on target.

There is another thing to note and that is that many of the assistive technologies used in websites do not work well or at all in modern browsers like Firefox and Safari. This poses a challenge for us as many of the features of these modern browsers are beneficial to e-learning environments.

Also, Flash pays an important role in e-learning as it allows content publishers to provide students/users with interactive activities to enhance lessons but they in turn do not provide the same benefit to students/users with disabilities; even with the improvements in Flash technology. Getting there though… We have come a long way in the last 2 years!

… my two cents!
IDS

Tomaz B

September 19, 2008 12:18 AM

@ David Owens
Thanks for links, good reading.
Cheers, t.

Jan Rezac

September 21, 2008 4:31 AM

Hello, I have a question about the article:

>> Use a resizable sans-serif font which is left-aligned.

Why sans-serif?

G F Mueden

September 21, 2008 7:30 AM

Great. I can add this: It s a lot easier to read if the material is scrolled up to where my eyes rest than have to search the screen for what to read and then mouse over to it. The NYTimes emails me the headlines, each with a short paragraph, and i scroll down the list and click on what I want to read. Wonderful.

BTW Why are you using so much hard to read blue on white?

=gm=

Matthew Pennell

September 21, 2008 12:53 PM

@Jan Rezac:

Sans-serif fonts have been shown to be easier to read (i.e. they facilitate faster reading/comprehension) than serif fonts on screen, while serifs are generally a better choice in print.

Some serif fonts, for example Verdana, were designed specifically for use at small sizes on computer monitors.

John Faulds

September 22, 2008 6:22 AM

Just to expand on a couple of the points you made:

You can still have links that say ‘click here’ or ‘read more’ (if the design dictates it) while also adding the additional information about each link by wrapping the extra info in a span that is hidden offscreen (e.g. position: absolute; left: -999em).

And when using headings be careful to use them in sequence and don’t skip any levels, e.g. h1 – h2 – h3 – h4 is correct; h1 – h3 – h4 is not.

Per

September 23, 2008 12:56 PM

Well written article, Leona.

For those who want to read some further on regarding this topic I recommend the following: Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers

It’s a bit old but still very useful.

Tom

September 25, 2008 5:35 AM

I was at a accessibility seminar yesterday and the issue of the H1 tag was brought up but it was left unresolved as other issues got discussed.

Anyway, taking your page as an example, you have two H1 tags. One for the logo and one for the title of this article. Is this ‘allowed’? Don’t get me wrong, I’m not having a go :)

If a screen reader or other software lists out the headings, it will have two H1 tags. Thoughts?

Oh and by the way, it was fascinating to watch people with disabilities trying (and in some cases succeeding) to use websites.

Leona Tomlinson

September 25, 2008 12:44 PM

Hi Tom,

Thanks for your question. In my professional opinion I would only use one <h1> on a page. The <h1> assigned should define the content of the page – e.g. if it is a contact page the <h1> heading should be something along the lines of Contact Us. As you mentioned in your comment, screen reader users depend on the correct semantic mark up of headings to navigate and identify key elements within the page. If there are multiple <h1> headings on a page then it would be more difficult to ascertain what the page is about.

Hope this helps.
Kind Regards,
Leona

denise

October 9, 2008 9:25 AM

Well done, indeed. Have read a lot on this subject, but have never come across such a succinct and comprehensive article.

Lisa Pappas

October 16, 2008 5:40 AM

Leona,
Great article combining many aspects of Web accessibility. I especially appreciate that you included cognitive disabilities. I find that in corporate Web development, that aspect can be considered inapplicable, much to the chagrin of my colleagues with dyslexia and attention-deficit challenges. I’ve linked to your article from the blog of the STC AccessAbility SIG. Great information worth sharing.

Sorry, comments are closed.

Media Temple

via Ad Packs