Accessibility for High Definition?

I read an article today by Roger Johansson where he mentioned an interesting situation surrounding the use of high resolution screens. The impact of these newer screens is not something widely considered; but it’s certainly important!

Newer laptop screens are beginning to come available using higher than usual resolution - that is, they have more pixels crammed into a particular area of screen than the normal 72 or 96 DPI. This can have an unfortunate effect for websites, because all of a sudden you’ve got a minuscule interpretation of your elegant page design. Perhaps you can increase the text size, but there’s nothing you can do about the images.

This is not yet a wide-spread issue - but then, accessibility is not about dealing with issues only when they become common. The principle we want to strive for is universal accessibility - and that requires accommodation for high-end products, as well.

Accessibility is very frequently viewed as a means of making something available to those who have disabilities, or for devices with inferior capabilities. But that’s a very inaccurate description - accessibility is about providing equal access to all devices. Practically speaking, however, nobody can actually TEST for all devices. This is why accessibility is so closely tied to web standards.

By adhering to a common set of standards, we can strive to match a template for what will be commonly usable by all user agents. The burden of accessibility is shared between the device designers, user agent creators, and content creators. Only with a commitment to common standards can all information truly be granted equal accessibility.

An Accessible Web Design Glossary

One chronic problem in writing web development articles is keeping your writing readable. The world of web design, programming, and web accessibility is loaded with industry terminology which are undoubtedly not immediately obvious in meaning to someone who’s just begun researching the subject.

However, neither the option of excluding all industry terminology from an article nor the option of including a definition inline for every term is really palatable for me. With the first option, the article becomes simplified to a point of abstraction, and is less useful for the practically-minded designer trying to get a firmer grasp of the subject. Inline definitions, however, can easily interrupt the flow of the text, rendering the overall readability lower because of the extraneous information.

The fact is, a constant barrage of definitions is not the right choice for every audience; and neither is the assumption of too much or too little knowledge.

What I’ve done to attempt to tackle this sticky problem is begin work on a glossary of web accessibility terminology.
I will gradually be adding contextual links to these terms in articles where I deem it necessary or useful. Those who need the definition can follow the link, those who don’t won’t need to. I’ll also be implementing an alternate look for links to these definitions, to attempt to make it clear that these links are different from the normal, run-of-the-mill outbound links.

Why write my own definitions? So I can have continuous control over the definition of a term, and so I’m not dependent on some other authority site remaining authoritative or, for that matter, failing to include all the terms I may want to refer to.

The glossary has a long way to go - only 26 terms so far, but I’ll keep plugging away as time allows. Feel free to suggest terms I may want to define, as well…

MySQL Poll Updated

Well, it’s a work in progress, so it keeps mutating bit by bit. Today, I fixed a minor bug which caused some images to be produced at the wrong length and added the ability to use a wider variety of colors for your poll images. No longer are you restricted to monochromatic! The whole rainbow is available. Aww, how cute.

At any rate, the new package is available and you can download it as you please.

Afterthought: Oh yeah, I forgot. I also added a minor feature which prints the vote percentages after the images.

Web Accessibility in Microsoft Vista

There’s no doubt that the eventual release of Microsoft’s new Vista operating system is a big thing for the world of computing. Windows holds the vast majority share of office and home computing, and the release of their first new system in over 5 years will be very significant.

Matt Bailey recently pointed out Microsoft’s claims that Vista would be the most accessible Windows ever. His description of their new features sounds promising - one of the key improvements will be an extensive set up wizard which, rather than focusing on "normal" options and "accessibility" options, will interview the user about their work habits and demonstrate new features, hopefully resulting in operating system settings which match the needs of the user.

It’s a good idea - the interview process removes the stigma of disability from your computer settings, and instead focuses on the user experience. Whether it works, of course, is another matter - but that won’t really be testable until there’s a much larger body of users. Not to mention the inevitable bugs in a beta system…

Vista will also incorporate substantially reworked versions of existing accessibility options. These options will include speech recognition (now with a learning engine which will adapt to your own style and vocabulary) and more advanced magnification. The new magnification style will render images and text at a larger size, rather than simply stretching the view, which has always created distortion in the magnified view.

All of this is discussed at some length with Rob Sinclair, the Director of Microsoft’s Accessible Technology Group, in Microsoft’s PressPass. The press version, of course, carries the usual highly-positive spin of a Microsoft press document, but is thorough enough to give you a pretty accurate sense for what’s coming up.

Finally, Vista will incorporate a testing model to allow 3rd party software providers to incorporate accessibility features into their software. This is unquestionably a great addition. The easier you make it for developers to make their software accessible the more likely it will be they’ll take the time and effort.

Error with last version of MySQL / PHP based poll

I just fixed an error in the code for my PHP based poll script - please download the new version! No change to the version number; this wasn’t that major of a fix, but if you are producing a poll which will have fewer than 5 result choices you will need to use the new version.

 Thanks!

Changes to PHP/MySQL Poll

Recently made some minor revisions to my MySQL/PHP Poll. The previous version was very limited in that it was only capable of handling polls with exactly 5 options. The new version is still fairly limited, but can now handle polls with anywhere from 2 to 5 voter choices.

Download now!

The Groundswell Surges Against WCAG 2

groundswell
1. A sudden gathering of force, as of public opinion: a groundswell of antiwar sentiment.
2. A broad deep undulation of the ocean, often caused by a distant storm or an earthquake.

I think, of course, that definition number one is most applicable here. What I’m finding particularly interesting about the recent surge in public commentary on WCAG 2.0 is how late it is in coming. This eleventh hour response, coming just days before the May 31st deadline for comments on the working draft document, seems somewhat tardy.

The document has been in progress since January 25th, 2001. Now, of course I can see why there was no need, at that time, for a huge response. At that time, and through most of the period of WCAG 2.0 development, the document was simply an acknowledgement that WCAG 1.0 was insufficient. The abstract of that first edition states:

Primarily, this is the first attempt to write checkpoints that may be applied to a wider range of technologies and that may be understood by a more varied audience. Since this Working Draft builds on WCAG 1.0 it has the same aim: explain how to make Web content accessible to people with disabilities.

At that time, their goals were straightforward and clear. The simple statement of the abstract was to make checkpoints have broader applicability and to make them more easily understood. In the second version, of August 24, 2001, they in fact state explicitly their goal "to use wording that may be understood by a more varied audience".

So far, so good. However, in the version of June 30th, 2005 a significant change appears in the abstract. This version no longer commits to a more understandable document. I’ll provide this abstract version in full:

Web Content Accessibility Guidelines 2.0 (WCAG 2.0) covers a wide range of issues and recommendations for making Web content more accessible. This document contains principles, guidelines, success criteria, benefits, and examples that define and explain the requirements for making Web-based information and applications accessible. “Accessible” means to a wide range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning difficulties, cognitive limitations, limited movement, speech difficulties, and others. Following these guidelines will also make your Web content more accessible to the vast majority of users, including older users. It will also enable people to access Web content using many different devices - including a wide variety of assistive technology.

WCAG 2.0 success criteria are written as testable statements that are not technology-specific. Guidance about satisfying the success criteria in specific technologies as well as general information about interpreting the success criteria are provided in separate documents. An Introduction to Web Content Accessibility Guidelines (WCAG) 2.0 Working Draft Documents is also available.

Until WCAG 2.0 advances to W3C Recommendation, the current and referenceable document is Web Content Accessibility Guidelines 1.0 (WCAG 1.0), published as a W3C Recommendation May 1999.

Try as you might, you can read no indication that this document will aim to be understandable. This is a significant and crucial change in goals. At this time, you might expect a protest to begin. Still; the drafts were a long way from being completed, and there was no real reason to see the full consequences of this change. Hindsight is, as they say, 20/20.

Unfortunately, this revision of the web content accessibility guidelines has been in progress for such a long time that an expectation of completion has been difficult to ascertain. Finally, now that they have announced last call, the community becomes aware that THIS document is the one we’ve been waiting for; and that it does not hold up to scrutiny. The last call working draft of April 26th contains a strong call for comments:

The W3C strongly encourages broad community review of this Last Call Working Draft, and submission of comments on any issues which you feel could present a significant barrier to future adoption and implementation of WCAG 2.0. In particular, we encourage you to comment on the success criteria and the conformance model. Reviewers are encouraged to provide suggestions for how to address issues as well as supportive feedback and endorsements of the document.

Although the surge of commentary in the last few weeks may be late in coming, we can only hope that the committee is sincere in there request and acknowledges the extensive criticism the document is now receiving.

Further reading on WCAG 2.0 as of this week:

 Tags:

Return to Top