Accessibility Angles

Vista Rant

2007-09-15T19:25:00.000-04:00

So my laptop was stolen two weeks ago. Data was encrypted, password protected, good backups, not too many worries. The police caught him, recovered my laptop and promptly impounded it for evidence. I'm not going to see it for a year, maybe two. What to do? The kids needed a new computer -- they were complaining bitterly about their 486 and were always sneaking on Tim's or mine, so I picked up a cheap tower from Staples -- fast for them, and I can work on it. But everything came with Vista Home. So why not? I figured I'll need to learn it sooner or later, and the price and immediate delivery is worth it.

3 days later, I finally got my Thunderbird email working and a bare minimum of software to do existing work. A SnagIt installation was prompted by the number of screenshots of error messages that I needed to get. 4 chat sessions, uncounted Google searches of Vista forums, 2 tech support phone calls to get the bare minimum for existing work. I was starting the struggle of getting JAWS to work when the new laptop arrived, so I abandoned the effort. To be fair to Freedom Scientific, I dreaded the problems (every other piece of software was a hassle, and JAWS is a challenge any day) and didn't give the installation a chance.

I got my new laptop two days ago which I custom ordered with Windows XP Pro. I just finished installing ALL my work software -- including JAWS -- with no hassle, no error messages, and no tech support or Google searches. I expect problems with a new OS, but the comparison was so surprising, that I was inspired to make a post -- the first in a long while.

Nothing like a little righteous moral indignation to get my fingers on the keyboard again.

I learned a lot at this last Fidelity gig, and I plan to do some detailed posting soon. Now that I have the laptop working, it may be sooner than later.

Accessible Design priorities - Part II

2005-05-17T09:22:00.000-04:00

Different types of disabilities have different needs from the web designer/developer. The canny designer will include the target disability audience in their analysis of the design goals. For example, an investment firm may be very interested in accessibility for Seniors� the aging baby boomers is an strategically critical target market. Aside from obvious design issues as fonts that can be resized, seniors have more subtle design needs, such as clear links and navigation on a page.

The gaming sites my children frequent obviously have not considered the needs of low reading levels in their site design. I spend a lot of time answering, �Mom can you help me with the computer?� The problem is usually game instructions that are not organized for low reading ability and short attention span. Sometimes it is a navigation problem with the site, as they click on the picture of the game they want (not a link) while ignoring the obvious underlined link that says �click here�.

Accessibility and Web Standards and Usability fields start to merge here. Fortunately, I am interested in all three, can you tell? More in my next post.

Accessibility Design priorities for different disabilities

2005-05-15T11:24:00.000-04:00

So first we need to get people thinking about designing for Accessibility at all. Given. But I believe we also have to the same kind of client analysis for the disability audience that we do for any other kind of client market analysis. Different disabilities have different priorities. Too often, accessibility analysis is only focused on meeting the WCAG or Section 508 standards and not looking at the target audience.

The accesskeys that make using a page easier for a mobility impaired user can break the functions of the JAWS that the visually impaired user needs to read the page. How do you decide? Client analysis. I was recently working on a proposal for a college that wants to attract visually impaired students. They need to set their accessibility priorities in that direction. A major investment firm wants to meet general accessibility standards, but they also want to focus their accessibility priorities toward senior citizens, a target market.

The May WebAim newsletter has a scholarly article on A Conceptual Framework for Accessibility Tools to Benefit Users with Cognitive Disabilities. It got me thinking about sites that would want to target this large market. So far, it is not a large market of computer users, but the entertainment sites would be wise to consider the very large market of low-level readers and their accessibility needs.

Your thoughts?

What's happening with Accessibility?

2005-05-14T18:48:00.000-04:00

It's been over a month since I last posted. I am perilously close to an abandoned blog. My daily excuse has been "I have to do the paying work first", but I think the real reason is that lack of accessibility stimulus. I have been doing small website development -- it pays the bills. The pages are accessible, but it isn't anything challenging to inspire posting.

I went to two blogging seminars this week to get reinspired. It worked, here I am. But I am striking out totally on a juicy subject to write about. I went and caught up on my RSS feeds (last read on March 9th). Sadly, most of them have been abandoned too. The sites with new posts didn't have anything that really struck my interest. Even my technorati search for Accessibility yielded mostly drivel. There was an basic article from Trenton Moss on Alt tags, that was, well basic. Basic is always needed, but there was nothing to inspire the first blog post in a month. the highlight of my afternoon catching up was a post from Dan Berkowitz of Boston University with a link to the Assistive Technology Boogie. Enjoy.

Sorry for the lack-luster post. Best to just do it, get back in the habit and have a better post tomorrow.

Accessible Web Publishing Wizard for Microsoft Office

2005-04-12T07:29:00.000-04:00

How did I miss THIS gem? The web is too big sometimes. Illinois Accessible Web Publishing Wizard for Microsoft Office:

The Illinois Accessible Web Publishing Wizard simplifies the task of converting PowerPoint presentations, Word documents, and Excel spreadsheets to accessible and vaild HTML 4.01 with CSS through an easy-to-use user interface and automation of many of the details of conversion needed for accessibility. The HTML generated meets or exceeds Section 508 and W3C WCAG 1.0 Double-A requirements for accessibility by people with disabilities and validates to HTML 4.01 and CSS standards.

It costs $39 for the single user version, cheaper the more you buy.

New Web Accessibility standards at Penn State

2005-03-10T23:08:00.000-05:00

Google News alerts sweep a lot of otherwise obscure information into my inbox. A year ago I would have missed this gem of news. Penn State is requiring all public web pages to validate and be accessible. They put together a good document -- all the basics, but they thought about resources for developers, suggestions for accessibility evaluation tools (LIFT) and even to have the Web Admins check for the subjective parts of the guidelines. A nice package and one that I will bookmark for future reference to clients.

Web Accessibility on the cheap

2005-03-10T18:13:00.000-05:00

It's relatively easy to make a website accessible. There are tools and instructions and the HTML -- while sometimes obscure -- isn't exactly rocket science. So why aren't more large websites accessible as a matter of course? There are three perceptions that I keep hearing from potential clients:

Perception #1: Why are we putting in all this work for the 17 (THE random number) blind people that use the site?

Reality: there are millions of people in the U.S. with disabilities. 20% of the population have at least one form of disability and the percentage rises with age. In my middle-class town, 34% of the senior citizens are disabled. The Census Bureau estimates that people with disablilties control over $1 trillion in assets. That is a lot of market share to write off. If your competitors aren't already looking at that market, they will be.

Perception#2: The web site will be ugly and all the cool features will have to be taken out.
Reality: There are very beautiful web sites that are accessible. Check out cssZenGarden.com for examples of accessibility and web standards. Scripts and applets can be made accessible. Flash has accessibility features, if the developer uses them. It takes a learning curve for the developers, but once the training is integrated into the development department there are usually accessible ways to accomplish the effects you want.

Perception #3 : It will cost a fortune to make the site accessible � we have other priorities.
Reality: There is a cost to accessibility, but spread over time with planning, it can have a minimal impact on the organization. Certainly, a big project to overhaul the entire site, hiring outside developers and Accessibility consultants is very costly. But with a relatively small investment in training, a plan to make pages accessible as part of the natural turnover of the web site, and implementation of project metrics to insure on-going accessibility maintenance, results in an accessible web site that enhances your marketing stratagy.

Wouldn't you want to have an attractive web site, that appeals to 20% of the population that you are not currently reaching that can be implemented with minimal cost impact? Not to mention that accessibility and web standards has been shown to decrease costs of web site maintenance and improve server throughput. What's not to love?

Microsoft and Accessibility features of IE SP2

2005-03-08T19:29:00.000-05:00

Kelly Ford of Microsoft posted information on the Accessibility features of Internet Explorer Service Pack 2, which introduces new security features that complicate the working of Assistive Technology devices. She offered work-arounds for screen reader users.

Nektar, a screen reader user, posted his suggestions for accessibility improvements to IE. He requested access to the toolbar, opposed the "Find as you type" feature and requested care in creating new versions of IE that will break existing screen reader software.

He stated that "Find as you type" will break screen reader controls. I had been aware that the Find as you type feature is not accessible because of refresh issues that prevent the screenreader from being able to confirm what is being typed without losing the data entered., but hadn't considered it conflicting with the keys in JAWS. Nektar is not a JAWS user, but it will be important to test this feature in the new version of JAWS.

Specification for a QA Accessibility Testing Tool

2005-03-08T19:15:00.000-05:00

The common accessibility testing tools (Bobby, Cynthia, Valet, Wave, etc) are oriented toward the developer who knows their code, but doesn't know the Accessibility standards or guidelines. The QA Engineer, particularly one who tests for accessibility often, doesn't need to know the guidelines, as much as s/he needs an efficient way to see if it is coded properly and the grammar and spelling are correct on all the non-visible text that is spoken by the screen reader.

Some of the free tools have parts of the ideal QA test tool... The Web Developer Toolbar for Firefox has a number of the pieces -- outlining all the links, outlining images with empty alt attributes, disable stylesheets -- but no one has it all in one test. It can take a tediously long time to turn all the tests on and off.

The most important requirement of the ideal test tool is that it renders a recognizable page, with lots of red highlighting the obvious mistakes (missing alt attributes, form elements without labels or titles) so that executives who need a overview of their accessibility status AND their competitors, have an easy to understand, visceral report that looks good in a PowerPoint presentation.

I've written the spec. Anyone interested in the development?

Evaluating the Accessibility Testing Tools

2005-03-06T17:08:00.000-05:00

I'm working on a proposal to do an accessibility analysis for a 250 page web site, and realized that it is time to upgrade my accessibility testing tools. It's been at least three years since I did a systematic evaluation of the testing tools, and I thought you should benefit from my search.

To start, I went to WAI and started downloading all the tools listed on their site. I knew 3 specific flaws on my home page and looked to see how the different reports handled the 3 problems. I ran a lot of on-line reports with a range of results from WCAG AAA pass, to a report with an error on every null ALT tag. I've written my initial impressions of each service. I hope it helps you.

I discovered some great new tools along the way: mostly Firefox extensions, since I have converted over to using Firefox almost exclusively. I was delighted to find a good replacement for the Web Accessibility Tool for IE. Firefox users should try out the Web Developer extension. It provides many of the same tests, with a new tests for highlighting types of code. Fangs, which I have already raved about, deserves another rave, in case you missed the first one. Checky is a Firefox extension that gives easy submission of a page to over 40 on-line services to validate or check accessibility. the National Center for Accessible Media has their own Accessibility QA Favelet for accessibility checking. This also provides some useful tests.

More to come. I've been through most of the free services. On to the commercial testing tools.

Joe Clark's new project

2005-02-21T08:00:00.000-05:00

I have long been a watcher of Joe Clark - long time accessibility guru and author. His newest venture, screenfont.ca, is dedicated to to research and develop a set of standards for captioning, audio description, subtitling, and dubbing. As my mother loses her hearing (and I notice the rapid degrade of my own) I spend more and more time looking at captioning. Important work that is desperately needed. Go Joe!

Accessibility Statistics for Management Proposals

2005-02-20T09:12:00.000-05:00

So where do you get the information to convince management that they should include accessibility in their next web site update? At first I thought they would be easy to find, but I think the medical privacy issue makes it more challenging than first thought.

I started with the U.S Census Bureau. They give general statistics for the US population. It is self reported, and not broken down into disability types that affect web access, for example, the people reporting physical disabilities includes disabilities that don't affect web use, like wheel chair use is combined with severe arthritis. The overall number is impressive, 54 million Americans self-report themselves as disabled in 2000. That's a number that makes every marketing type sit up and think "market share". I also found another article that quoted

US Census Bureau stated that disabled persons in the US alone had an aggregate
income of $1 trillion in 2001, including $220 billion in discretionary income.

But where to find the numbers for Internet users. A lecture by Andrew Kirkpatrick led me to a Forrester Research project for Microsoft with lots of good statistics. Go to page 4 for the numbers. Microsoft also keeps a useful page listing Accessible Technology marketing research.

Good luck!

Advanced Accessibility Information

2005-02-16T06:53:00.000-05:00

Subtitled: Drinking From The Firehose

I haven't posted much in the last two weeks, and I know what is to blame. I started receiving and reading RSS feeds of accessibility subjects. The amount of new ideas and information is over-stimulating. I have started three different writing projects for articles that are in various stages of completion. Expect an article today on Accessibility Testing Tools. The first two lessons of my tutorial on Testing for Section 508 are done. I'm trying to decide to make the links active, or wait until more is done. But I know the real culprit is the Firehose. I am also writing a proposal and a stand-up training program. More to come.

Accessible Radio Buttons - Likert Scale Solutions

2005-02-09T12:04:00.000-05:00

I was looking at a page using a Likert scale that the developer had made an effort to make accessible. A Likert scale is commonly used for opinion polls. The scale is a data table where the first column is usually the question and the remaining (usually 3 or 5 columns) are the rankings with a radio button in each cell labelled something like: Strongly Agree, Agree, No Opinion, Disagree, Strongly Disagree. In the case I was lookig at, the developer had put table heading <th> tags on the cells at the top of the column so the listener could tell what column they were in.

This would be useful if the user was just listening to the table and using the JAWS key commands to read the information about the cells. Unfortunately, in order to answer the questions, the JAWS user must be in Forms mode which is not going to give them table information. In order to properly code this type of table for accessibility, you also need to use the form element features.

Normally, I recommend using <label> tags for form elements. Normally, they are better, as they also provide increased click size area for limited mobility users (clicking the text selects the box, button or dropdown). In this case, we don't want to put visible text on each radio button as that will add clutter for sighted users.

As I started to get more into the issues and code samples, this blog morphed into an article. Read the entire article with code.

Firefox Extension emulates screen readers

2005-02-03T10:52:00.000-05:00

This is great! Even the name is fun. Fangs, an Open Source extension for Mozilla's Firefox, gives a text version of a page emulating the JAWS screen reader.
I cannot tell you how many hours I have spent listening to pages in JAWS, the popular screen reader from Freedom Scientific. This doesn't replace the need for JAWS testing - this simply emulates the "Say All" command from JAWS - but it certainly reduces a lot of tedious work listening to pages. I'd rather scan FANGS for obvious blunders on the page, then do actual JAWS testing for pages with complex scripting or other features to test. I just looked at my own page design and saw a major oversight -- time for some redesign of the Blogger template.
The version I downloaded today, version .80, has added new features -- a tab with the list of links and a tab with the list of headings. This makes it really easy to see what a good job (NOT!) I have done naming blog entries. Well, I have been at it for a month, so there is lots to learn.

Accessibility and CAPTCHA tests

2005-02-01T18:28:00.000-05:00

I failed a CAPTCHA test yesterday, which got me thinking and researching CAPTCHA accessibility. Most of us have taken a CAPTCHA test to sign up for different on-line services -- they are the forms where you enter the letters you see in a graphic. They are usually on a patterned background so that computer programs like 'bots and spiders cannot gain access to the site. The test I failed used a bit-mapped graphic with so much background "noise" (little dots) that I couldn't tell whether it was an "r" or a "7".

The CAPTCHA (Completely Automated Public Turing test to Tell Computers and Humans Apart) is used to discriminate between human users and automated software.
[Apologies: Blogger deletes all the text following the ACRONYM tag whenever I try to use it. I've given up for now. Any Blogger experts with solutions for me, please be in touch]

There is a market need to verify whether the user is a human. Right now, the common CAPTCHA tests only can verify sighted humans. Even sighted humans have difficulty with it -- people with color blindness have difficulty discriminating the letters from the background. People using zoom magnifiers may not be able to discriminate the pattern when the "noise" is magnified.

So how can these be made accessible? An ALT tag would give it away to the 'bots. As other researchers in robotics work to make their robots more visually capable, they are defeating the earlier, easily decoded patterns. The CAPTCHA experts retaliate with more complex patterns to stymie the 'bots. Hence the CAPTCHA I saw -- too tough for sighted humans. The visual CAPTCHA are probably a dead-end, doomed to endless warfare between competing technologies. The existing auditory CAPTCHA currently in use today have their own problems - requiring a sound card, not accessible to deaf-blind, and too hard to decipher.

Unsurprisingly, the W3C has been doing research on the techniques for accessible CAPTCHAs as part of the Web Accessibility Guidelines V. 2.0. They list a number of alternatives. No silver bullet, but a combination of techniques will help. Friday's blog from Matt May (Web Accessibility for W3C) posts the good news of a logic puzzle solution for WordPress by Eric Meyer of CSS fame.

I'm looking forward to seeing more on this issue.

Confusion in UK over Accessibility Standards

2005-01-25T07:27:00.000-05:00

As an citizen of the US, dealing with very limited Accessibility legal requirements, I have looked with envy at my colleagues in the UK. I'm sorry to see that they deal with the reality of politicians, too.

The crux of this article is that the department responsible for Web Accessibility standards doesn't have an accessible web site. Rather than admit that, and make a public plan for how they will get there, they are throwing the standards into confusion by declaring that there are no standards. Ugh!

New accessibility tool for technical diagrams

2005-01-24T06:37:00.000-05:00

Thanks to Dan Jellineck's E-ACCESS BULLETIN - ISSUE 61, JANUARY 2005 for this tidbit:

Technical Drawings Understanding for the Blind (TeDUB -
http://www.tedub.org/) has been headed by the TeDUB Consortium which comprises partners from the UK, Germany, Ireland, Italy and the Netherlands.
TeDUB works by uploading diagrams, such as the "box and pointer" diagrams often used to design family trees, to a web site where they are converted into a compatible format and then emailed back to the user. It has been designed to work best with diagrams created in Unified Modeling Language (UML), a coding language often used by software engineers to represent real-world objects.
The system also allows vision-impaired users to move around diagrams with a joystick. It provides basic sound to accompany navigation allowing users to hear where they are, and is also compatible with screen readers.
The software is available by download from the TeDUB web site where tutorials and examples of UML diagrams can also be found. It is funded by the sixth framework of the European Commission's Information Society Technologies research programme (http://www.cordis.lu/ist/).

JAWS and Javascript

2005-01-21T06:21:00.000-05:00

I ran across a Freedom Scientific Tech Note that gives their perspective on the interaction on coding with JAWS including the correct way to do a screen refresh so JAWS will detect it.

From Freedom Scientific FAQ: "Tips on HTML code and expected behavior from JAWS"

Q: How can I expect JAWS to handle JavaScript on my Web page?
A: JAWS will work correctly with JavaScript if:
* The scripts are activated by clicking a link or clickable item and the script dynamically updates the HTML source.* The scripts do not update the page without user intervention.
If you want to refresh your page, use the following method rather than using JavaScript: <meta content="nSeconds;URL" equiv="refresh">

Useful link to have.

Attractive accessibility

2005-01-20T06:52:00.000-05:00

Recently two different people have expressed their aversion to Accessibility. The most pithy was "you accessibility nazis come in and take an attractive web site and make it ugly." I was astounded. Perhaps because I primarily retrofit existing websites for accessibility, I have always been oriented toward keeping the original look and feel untouched. Perhaps not pixel-perfect identical, but I strive for that.

One area that impacts the look and feel is testing for color contrast and testing for color deficiency. Perhaps I have been lucky, but I think I have been dealing with professional designers who know how to use color -- they may not be thinking about accessibility directly, but good design and accessible design are very closely linked -- just like good coding techniques and accessible coding are very close. A well coded site is easy to make accessible. Bad code is a nightmare, no matter what you are doing.

Check out CSS Zen Garden for examples of attractive, accessible design. It is a demo site with standardized HTML where different designers simply apply different style sheets for a radically different page.

Accessibility - The need for legislative standards

2005-01-14T07:04:00.000-05:00

My daily Google alert brought the news that the EU is setting up a consultation to study accessibility of computers, cellphones and web sites. This is progress. I have been reading the complaints of my clients across the pond that they don't have standards to go by. Then there was the article just before the holidays that a private club of top 100 British and International firms discussed accessibility and many agreed that providing phone support was adequate. This is what can happen without standards.

Now admittedly, government standards are usually far from ideal or what we would like to see, but they provide a line that limits a companies ability to brush them off. The U.S. Section 508 standards are quite limited, but they do provide a guideline and a starting point for companies. My current client is feeling the pressure from their own clients who do business with the Feds. In our interconnected world where many are vendors to the vendors, the need for Section 508 compliance is spreading. A month ago, I did a presentation to a room full of VPs who had never heard of Section 508 and thought that they didn't need to provide services to such a small amount of market share. Yesterday I was on a conference call where one was referring to Section 508 compliance and the time issues of redesigning the dynamic pages. That's a long way in a month.

The pressure is increasing and the public awareness is improving. That's progress.

Tips for the Accessibility Evangelist

2005-01-10T15:58:00.000-05:00

When I took my current contract, I was told in my interview that they were looking for an evangelist for Accessibility. About 10 years ago, that was a very popular job title, and although it was never officially my title on this contract, it is a good description of what I do. I was hired by the QA Department to do Accessibility testing -- and I do that, but it is a very small part of what I do. I have made a big impact so far, so I'd like to pass on what I can see as working.

Depending on the industry, referring to your work as Section 508 Compliance is more powerful than Web Accessibility. I focus on the Marketing Opportunity ("the carrot") and the risk of non-compliance ("the stick"). The Marketing Opportunity is clear and powerful if you are in a business eyeing the ever-increasing Senior Citizen marketplace. The over-65 is the fastest growing segment of the population in the US. As they (we) age, the percentage of disabilities increase rapidly. An accessible website is a marketing edge for this population group.

Section 508 didn't mean much to people outside Federal agencies, but the Attorney General of New York, Eliot Spitzer, settled out of court with Priceline and Ramada last August. This made many legal departments sit up and take notice. Section 508 Compliance means a lot more today than it did 6 months ago.

I also do a lot of work to make tools for different groups. I do presentations, visit a lot of project meetings, answer emails with Accessibility questions and try to have a useful handout or tool for each one. I help maintain existing internal websites on Accessibility. When I have permissions, I put tools up as I make them. On the site where I have to ask for someone else to post, well, let's say there are a lot of things waiting to go up, but I have yet to see them. I constantly offer to "speak to your group" so that I have been able to do some education for all areas of the Development Cycle. I try to focus most of my efforts on Project Managers. If you get the PMs, the rest of the cycle will follow. Establishing a business need for Accessibility helps make things happen.

Does Accessibility Testing Belong in QA?

2005-01-07T06:02:00.000-05:00

Since I ended yesterday's post with such a cogent question, I'll give some thoughts about it.

Quality Assurance is a critical component of an enterprise-wide accessibility plan. The ability to write a bug is a powerful tool for motivation. When developers get bugs assigned to them for accessibility features that are missing, they start to pay attention. QA provides the safety net that helps prevent blatant accessibility omissions from slipping onto the website during updates and changes.

QA, however, should not be the driving force (or the only force) behind an Accessibility plan. Accessibility is NOT just another browser to test against. Accessibility has to be built into the entire development cycle, otherwise much time and resources are wasted trying to put accessibility into a mostly completed product. Writing bugs at the end of the development cycle to add in the accessibility features leads to bad code, late projects, or endlessly postponed accessibility bugs.

Accessibility requires specialized knowledge that needs to be brought to bear early in the Development cycle to insure that designs are well constructed, speech-only text is written and approved, and special accessibility concerns are specified and constructed. Some sophistication in using screen readers is required to really test a page in JAWS. JAWS has a steep learning curve, and the novice user cannot test whether a script or applet is accessible - or even that the table headings are correctly done.

The accessibility testing done in QA can be done with a good tool and basic training in the general things to look for. Certainly, QA can look for ALT tags, labels on form elements and table headings with a basic testing tool. This insures that each page is being looked at and routine maintenance doesn't overwrite accessibility work already done. Accessibility Subject Matter Experts are needed to test complex scripts and applets and to insure that designs are well constructed. What department the SME is in can vary, but the SME must be involved early in the project process to be more efficient and effective.

Limitations of Accessibility Testing Tools

2005-01-06T07:03:00.000-05:00

One of the interesting points Andrew Kirkpatrick of the WGBH National Center for Accessible Media raised in his presentation to the IP495 meeting was the limitations of Accessibility testing tools. Of the Section 508 requirements, only 3 or 4 can be tested with an accessibility tool, therefore the certifications of accessibility by Bobby and others are of limited usefulness. He put it more colorfully, but since I can't remember the exact phrase, I'll paraphrase vaguely.

I have been working on this as I was updating the QA Test Tracker tool for Section 508 -- although by my count, 7 of the 508 standards can be tested with a tool: (a) ALT tags; (d) works without stylesheet; (g) table column & row TH; (h) TD is associated with TH; (i) frames have meaningful TITLE tags; (n) form elements have LABEL tags; (o) skip navigation provided. NOTE -- these are my abbreviations of the requirements - you can find the specific 508 requirements and suggestions for pass/fail at WebAIM.

Of the remaining standards, 6 can be tested in a browser by a trained tester: (c) no info only with color;(e) redundent links for server side image maps; (f) client side image map, not server side; (j) no flicker; (k) text-only version; (p) timed response. The remaining standards can only be tested in a screen reader: (b) synchronized captions (l) scripts are accessible (m) applets & plugins are accessible (n) dynamic form elements are accessible. These take considerable expertise in using a screen reader.

As I am currently writing a training program for QA testing, this raises the difficult question -- does Accessibility Testing belong in QA?

Keywords and Resizable Fonts

2005-01-05T06:49:00.000-05:00

If you want to make sure that your site is accessible to people who are visually impaired - particularly to the elderly - you need to move away from absolute sized fonts. Ems or percentages are the most commonly used relative sized fonts. Switching to ems or percentage sizes have their own problems. If your page designs use nested divs or other CSS inheritance, your em and percentage definitions are also subject to inheritance.

This means that a font defined as .85em nested in a div with a font defined as .85em will display as .72em. This can make your stylesheets complex and buggy. A large stylesheet is a performance hit.

There are absolute font sizes that maintains their size despite inheritance and will resize properly in IE. They are the keyword font sizes: xx-large, x-large, large, medium, small, x-small and xx-small. A List Apart ran an article by Todd Fahrner that gives details and sample code.

There are no easy answers, however. The Keywords approach covers 7 sizes, but most of them are too large to use. Practically, there are 3 sizes to use commonly, that work out to be roughly 10, 12 and 14 pixels in size. My current client wants 11px Verdana -- Verdana is optimized for 11 pixels, says she, and it is the ideal size. So we are currently doing a mixture of techniques -- keywords for the even sized fonts and percentages for the the 11 pixel size.