Lesson: Web Page Design and Accessibility

…continued

Color choices also effect people’s ability to “see” a page. Approximately 10% of all Internet users have problems seeing colors, like those with color blindness. There are lots of sites which can help you test your color choices to see how they would be “seen” and recognized. You don’t have to design your site around these issues, but better informed makes for better designers.

Can Color Blind Users See Your Web Page?
Q42 Color Blindness Simulator
Visibone’s Color Blind Color Chart
Color Blind Web Filter – Testing Online
Blindness-Related Resources on the Web and Beyond
Accessible Web Page Design – Resources for the Visually Impaired
Design Considerations: Readers with Visual Impairments

For the visually or physically challenged, one of the ways of navigating a site is through the use of Access Keys. These are standardized keys that when pressed in combination will move the cursor around to the different areas. For example, if you have a link to a search page for advanced searches, the user would press Alt+s in Windows and Ctrl+s in Mac and the cursor would jump to the search link. The code to set the accesskey in a link to a search page would be:

<a href="search.php" accesskey="s">Search</a>

For information on accesskeys:
Accesskeys and Reserved Keystroke Combinations Chart
Clagnut: Accesskey Standards
Using accesskey attribute in HTML forms and links
W3’s Forms in HTML Documents – Using Accesskey
Accesskeys: Unlocking Hidden Navigation
Access Information, Technques and Keyboard Access Information (UK Government Recommendations)
Provide Clear Navigation Mechanisms

…continued.

Now, I’ve mostly mentioned access for the disabled, but here are some links for information on accessibility for other purposes:

Validation and Testing HTML
Gazingus.org’s Validation Bookmarks
NetMechanic’s Spell Check for Web Pages
Pcman’s Web Page Screen Resolution Tester
Web Page Monitor (check for different sized monitors)
AnyBrowser’s Web Site Viewer – How does your site look to other browsers
Window Sizer – Check a page at various window resolutions
AnyBrowser.org Developing Web Pages to Work for Every Browser
Archive.org: Preserving the Internet Web Pages (Find old web pages)
Bobby (checks sites for browser compatibility and disability access)
Web Browsers Compatibility from Delorie
Viewing A Sample Page Under Various Conditions and Uses
Webmonkey – Browser Kit
A Compendium of HTML Elements (browser compatibility lists)
NetMechanic’s Browser Compatibility
Learnwebdesign’s Browser References
Public Lynx Access Browsers
Checking with Multiple Browsers (the hard core way)

Checking Your CSS Accessibility
Code Style Media Monitor (projection, print, etc)
Guide to CSS2 Support in PDA/Handheld Browsers
pawgo.com’s Handheld Internet 101
Pcman’s Free WAP Tools and Resources (WML/WAP Page Emulator)
How Can I Tell HTML Browsers from WML (Wireless) Browsers
The Wireless FAQ (WAP, WML)
W3C Mobile Access – Seamless Web Access From Mobile Devices
W3C Mobile Access Activity Statement
CSS Mobile Profile Test Suite
W3C CSS Mobile Profile 1.0
W3C HTML 4 Specs on Mobility – Handheld
Aural style sheets
The W3C CSS2 recommendation, Section 7: Media types
Open Mobile Alliance for the Mobile Services Market
Web Design for Mobility – Handheld, PDA, etc.

…continued.

It is also a growing trend for websites to have their own Accessibility Policy, a page that informs users of the standards you are using to make your page accessible to everyone. In Britain, there have been law suits and complaints filed against government and corporate websites under the Disability Discrimination Act for NOT being accessible, and the trend is happening here in the US. It isn’t hard to be compliant with accessibility standards, it just takes a few extra keystrokes to help everyone get the most from your site.

Lorelle’s Accessibility Policy Page – an example
Creating an Accessibility Statement
Review: International Compliant Style (IC-Style) Accessibility
Accessibility Statement and Resources
A Primer for Accessible Web Pages
Section 508 US Accessibility Law
Checkpoints for Web Accessibility Guidelines

There are a lot of resources for validating your page, and each ones tends to test a different function.

Readability Of Websites With Various Foreground/Background Color Combinations, Font Types And Word Styles
Vischeck (simulates color blind vision)
Accessibility Checking Favelets (scripts)
Bobby (checks sites for disability access and browser compatibility)
HiSoftware’s Online Content Accessibility and Quality Tester
Evaluation, Repair, and Transformation Tools for Web Content Accessibility
W3C Web Accessibility Initiative: Evaluating Websites for Accessibility
WaiZilla: Open Source Accessibility Testing
WAVE Online Accessibility Tool Checker

..continued…the end…

To find out more about accessibility and designing your site with accessibility in mind:

Notes on Tools for Checking and Improving Web Page Accessibility
Arguments for Making your Site Universally Accessible
Don’t Fake Your Markup Accessibility Issues for CSS
How Alt Attributes Help Accessibility
Five Site-accessibility Tips to Help Comply with Section 508
Improving Web Site Usability and Appeal
Designing More Usable Web Sites
Making Accessibility Accessible: The Reasons Organizations Don’t Have Accessible Websites
Dracos Accessibility Examples (using popular “inaccessible” websites and redesigning them to be accessible)
CSS Accessibility Problems: Is Markup Dead?
Accountability of Accessibility and Usability
Useit.com CSS and Usability
W3C Device Independence Principles – Understanding Accessibility Issues
Guidelines for Creating Accessible Web Sites
Curriculum for Web Content Accessibility Guidelines 1.0
Accessible Web Authoring Resources and Education
Designing More Usable Web Sites – massive links
Designing More Usable Web Sites
Alertbox: References on usability of web design

If you are really serious about creating and designing accessible web pages, there are some folks who would really love to have your help, or just to have you hang around a bit:

Accessibility Forum
Makoa.org’s Accessibility Resources and Information
The Accessible Web
Guild of Accessible Web Designers

Now, do you have any questions about accessibility, why you should consider this, why it should keep you up worrying at night, or how to implement it, or you have some other good resources to add to the list….start your engines.

Note: I’ve gathered these links up over the past couple of years, so if one is bad or changed and you find it, please post a note here so others can find these resources, too. They tend to change quickly and I do my best to keep them up-to-date…but….

That is a formidable list of resources. Sometimes the simplest things can repay the investment many times over. For example simply increasing the white space on a page with margins, padding, and line height can really make a page much more accessible and enjoyable. It is surprising how many well informed people overlook this easy fix. ??

Lorelle,
Awesome list! Thanks for putting it together!

I found some info that underscores your information about ALT text:

Alt text should not describe the image, it should replace it.
The rule that deals with alt text in Section 508 is 1194.22 (a):

A text equivalent for every non-text element shall be provided (e.g., via “alt”, “longdesc”, or in element content).

Source: Section 508

The WAI’s Web Content Accessibility Guidelines (WCAG) 1.0 checkpoint that deals with alt text is 1.1:

Provide a text equivalent for every non-text element (e.g., via “alt”, “longdesc”, or in element content). This includes:
images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ASCII art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. [Priority 1]

Source: w3

Excellent. The longdesc is a pain as you have to create a file that describes your non-text element, but if you have something worth “looking” at, then it makes a difference to take that extra step.

And I love that you added that EVERYTHING including music and such should be tagged with alt.

Now, everyone has their level of standards and after much research and articles on this subject, I found out that non-visual web users are tired of “hearing” things that don’t “add” to the story. So when I have presentation graphics that don’t contribute to the content but only impact the visual look, I use the alt but I just put nothing in the quotes and the text readers skip it completely because there is “nothing” there.

...and the story goes on and gets more exciting so we wouldn't want to be interrupted by <img scr="flag.jpg" alt="" /> anything that keeps us from the dramatic conclusion....

But anything of consequence – give it a name for those who can’t “see” it.

And it helps in so many other ways.

You know, I got involved with this because I spent a lot of time working with the disabled, visually and audiably impaired, and introducing them to the Internet was a thrill. At the time, though, it was darn frustrating because there were so few options and they were expensive and inaccessible to those who weren’t starving and on the dole. If you had money, but not quite enough money, tough.

But now, accessibility is built into web browsers. Microsoft provides it as part of Windows operating system. More software packages are getting with it to help their users USE their programs.

And as I did more work and research and articles on this topic, I started realizing that accessibility isn’t for the blind or handicapped. In order for a web page to be accessible, EVERYONE must be able to “see” it. I have a friend who rarely uses his computer any more. He (16) surfs the net via his cell phone. I get web pages downloaded onto my handheld computer to read while traveling.

I know that WordPress has done a lot of work into making their pages accessible for different media. How about a list of what they are doing?

useful list! I’ve got most of those bookmarked already, though it’s useful to see them all in other lists.

One thing that I did read somewhere (I think that it was a BBC report, but I can’t find it any more), is that for dyslexic users, having the alt text pop up over an image can be confusing, as it’s information they don’t need to read.
The article suggested that the best option is to use Title tags – for anything that you _really_ want to use as a tool tip (remembering that the ability to use Alt text as a tool tip was never intended) – so mostly the title tag would be empty. Then use the alt tag as intended.
The result is that for those who can see the images, where the alt text doesn’t add further information (which it shouldn’t anyway), they won’t get confused with the extra reading, but for those who can’t see the images, then they do get the additional information.

Does the image tag feature a “title”? The things you learn!

And “title” does pops up on a link by default in most browsers I’ve worked with.

‘Title’ indeed pops up on links, but if you want a tooltip on images in Firefox ‘alt’ won’t work, you have to use ‘title’.

On images or links or all?

I popped over here after reading this post (on a WordPress blog):

https://arkansas.blogsome.com/2005/03/03/web-site-accessibility-design-for-business-blogs/

One thing he mentions that looks very time consuming to handle manually is the tabindex attribute, which as I understand it controls the order of the links for someone using a keyboard to navigate. The idea is great, but with the number of links in the typical blog, it would have to be automated to be useful. The whole thing that moved me to the blog format, and WordPress specifically, was being able to add content easily without having to write a bunch of HTML (or use one of those tables based WYSIWIG HTML “editors”). If I’m going to add all these extra tags manually, I’m right back where I was pre-WordPress. Anyway, I headed over here with the thought of posting something in the feature requests, but since there’s a recent and apparently ongoing discussion, I thought I’d throw in my two cents worth here.

I’d also add that the biggest issue I found with my own sites was not in anything I had personally written or even in things that WordPress had produced. Those things are all at least a “B” grade generally for accessibility and compliance. The problems are in code and scripts for everything from Adsense to the Truth Laid Bear ecosystem, many of which simply won’t function correctly for the other 99% of cases if they are altered. So, to some extent, some advocates of this need to stop preaching to the converted and go tell the big boys that make the code we have to use “as-is”.

Bottom line: Accessibility is a great goal, but if it involves a bunch of manual changes, especially changes that break the code in other ways, it eliminates the single biggest advantage of the blog/CMS format over just writing pages by hand.

Actually, from what I know, most of WordPress is fairly friendly to accessibility, at least in the back code. Yes, the use of accesskeys are not there and they should be, but part of that comes from the Theme with the new version of WordPress.

Accesskeys highlight only specific pages that are universal within the site itself. Site maps, search, contact, about, the typical universal links to more information. So these can be easily coded into the index.php. Should they come with WordPress by default…well, do you have a “contact page” on your site? About about a “site map”? If you list one, which doesn’t come with WordPress by default, then you have to be the one responsible enough to include the accesskey for it if you include it.

See, double edged sword.

WordPress for the visually impaired right-out-of-the-box is pretty good since it doesn’t force any styles down the throat of the user. They can be quickly and easily overwritten by software so the user’s reading program can process it easily.

The only work for accessibility, other than the one time adding of accesskeys to YOUR site structure, that comes in writing the posts happens inside of the WRITE admin screen. When you use the Quicktags to insert a graphic, WordPress asks for the target link (the place and name of the file to find it) and then pops up another window that says “Enter description”. This because the alt tag automatically. Bingo, accessible automatically.

Links to other pages and sites, though, do need to have a descriptor in the form of a title. Here is one of the let downs of WordPress. Like the image, they could have a second window that allows for a description of the link to come up naturally with the Quicktag Link, but it doesn’t. So you should manually add your own.

Other than that, what else is there to do? This isn’t a lot of work. When you have the core basics done in the templates to make them accessible, just like you would customize the Theme or template to your needs, you don’t have to think about this for a year or two, or until you get board and want a new theme.

This isn’t a lot of manual work, but it is a courtesy. Do you get up from a table in a restaurant and leave your chair hanging out in the aisle? No, if you are a polite and well trained human being, you would tuck your chair back in to the table so others may move between tables without hassle. I like thinking of accessibility as that kind of politeness.

I have just discovered a great site which automagically analyses your blog across a whole range of categories including accessibility all in one go. Why not check out Sitescore at It is a lot of fun