Blog » Archive by category 'Accessibility'
It wasn’t long ago that I wrote an article on authoring an effective text-resizing widget. In that article, I made a point not to espouse the use of text-resizing tools, since it’s generally more effective to allow people to use their browser’s built-in text-resizing functionality.
In fact, browser’s allow you a great deal more control than simply size. Modern browsers can give you extensive control over website text, including dictating background colors, text color, base text size, minimum text size, and link attributes. This post is intended to provide a quick overview of the specific controls for most modern browsers.
Most browsers have fundamentally the same options, although the interface and location in menus is quite variable. Some are more intuitive than others, and some interfaces simply don’t quite work right…
Read more: Refining Text Presentation with your Web Browser: Windows
The grand old question concerning techniques and choices in web accessibility which, while common, are not necessarily helpful is a popular subject which is always around in accessibility circles. It’s certainly not a new topic for me to write on, but one which (for whatever reason) I’m going to go ahead and write about again.
In this case, I’m going to take a single commonly implemented method: the text-resizing tool, and discuss the advantages and disadvantages in some depth.
This article isn’t intended to espouse the use of text-resizing tools, but it is intended to try and describe how you can best implement a text-resizing tool to provide for your users.
Read more: Developing an effective text-resizing widget
Just wanted to add the comment, since I didn’t specify it explicitly, that I’m not trying to claim that the accessibility of this particularly CAPTCHA is all that fantastic — - it’s pretty good, but there are serious problems. I’m just saying that it’s a neat idea. 
In case you don’t already know, “CAPTCHA” is an abbreviation for “Completely Automated Turing Test To Tell Computers and Humans Apart.” From an accessibility perspective, they tend to have significant problems — - and I’m not going to try and claim that this one is perfect. However, it is very thoughtfully done, and has a very interesting additional feature which I appreciated.
I ran across this via Stumbleupon. Unusually, rather than finding it because I was busily stumbling around, I actually became aware of it because I was trying to create a new account. The interesting CAPTCHA is called “reCAPTCHA.”
Specifically, the concept behind it (explained thoroughly on the reCAPTCHA site) is to gain value from user input in CAPTCHA texts.
Most spam protection systems are based on nonsense words, random strings of letters, or obscured text. Anything, fundamentally, which might be difficult for a computer to identify.
What the folks at reCAPTCHA observed was that scanning old books provides a wealth of resources in the realm of obscured text which can’t easily be understood by computers. To solve this problem, they pasted together the needs of a CAPTCHA and their scanning process to create a service which helps them identify these unknown texts.
Obviously, there’s an immediate problem: if the computer has already failed to identify the text, how do you test whether a human has read it correctly? Simply speaking, you don’t.
Instead, reCAPTCHA provides two words for the user: one they know, and one they don’t. The known word is the Turing test — - the unknown word creates a source for the computer to identify the word they didn’t know.
From reCAPTCHA.com:
About 60 million CAPTCHAs are solved by humans around the world every day. In each case, roughly ten seconds of human time are being spent. Individually, that’s not a lot of time, but in aggregate these little puzzles consume more than 150,000 hours of work each day. What if we could make positive use of this human effort? reCAPTCHA does exactly that by channeling the effort spent solving CAPTCHAs online into “reading” books.
[…]
But if a computer can’t read such a CAPTCHA, how does the system know the correct answer to the puzzle? Here’s how: Each new word that cannot be read correctly by OCR is given to a user in conjunction with another word for which the answer is already known. The user is then asked to read both words. If they solve the one for which the answer is known, the system assumes their answer is correct for the new one. The system then gives the new image to a number of other people to determine, with higher confidence, whether the original answer was correct.
The CAPTCHA itself is delivered via Javascript or iFrame. When Javascript is unavailable, a perfectly usable fallback is provided. reCAPTCHA also provides an audio alternative — - which, I’ll confess, I found very difficult. I’d need to see some kind of user test results, however, to really know how difficult the audio version is overall. In general, as CAPTCHA technology goes, this is an admirable project. Not only because they have taken a reasonably conscientious path in preparing the interface, but simply because it’s a very good idea.
It’s unlikely I’ll implement it, I’ll confess. The fact that it’s delivered via an iFrame and the simple nature of a CAPTCHA go against my generally preferences in web development. However, should I be in a situation where I need to implement one — - this will certainly be a strong candidate! (And even stronger if they fix their accessibility issues.)
More Information
Quietly released on the Saturday before Christmas, (what, are they trying to hide this news?) Google announced that their latest Toolbar release supports the Windows Accessibility API.
This is (obviously) a Windows-specific release, and even further, it’s just an Internet Explorer release. However, it’s definitely a step in the right direction! I was particularly glad to see the comment:
Version 5 comes as a part of our ongoing efforts to enhance accessibility in our client-side and web applications, which is a matter I hardly need to mention is very important. Jonas Klink, Software Engineer, Accessibility
(Emphasis added.)
Now, as many have commented, the accessibility level of much of Google’s code is atrocious. I like the idea that Google is actively invested in improving the accessibility of their products; but I have yet to see any serious evidence of this effort!
Still, in the holiday spirit, I will raise a glass to Google to encourage their accessibility efforts. (And if, as a side effect, I end up a little bit drunker, I will accept that.)
The justification that a web site is accessible because it “follows standards” contains a serious fallacy. Specifically, the assumption that standards support accessibility.
One root of current standard accessibility practice is conformance to the HTML or XHTML standards set by the World Wide Web Consortium (W3C). This is a fine practice, and certainly should be maintained. Using correct syntax and following a standardized method of communicating information is always a solid best practice. However, this should absolutely not be taken to mean that following these standards is the same as applying the principles of web accessibility.
Web standards only provide accessibility to the degree that they have been designed to do so — - and the guiding principle behind standards development (excluding accessibility-specific standards, of course) has not generally been to support accessibility. Web standards have been designed purely to establish a set, correct method of using the underlying code — - whether presentational (CSS), structural (XHTML) or behavioral (ECMAscript.)
In many (most) cases, web standards do not in any way require best practices — - they merely require conformance. Take HTML, for example. Web standards would permit the usage of table elements for layout, because they do not define semantic usage for the table element. Web standards also permit a variety of presentational elements, such as font, strike, or u. It all depends on what standard you have chosen to follow.
HTML5, most recently, is considering such contrarian steps as removing the requirement that alt attributes be required for images. This ensures the existence of a valid HTML5 web site which can radically fail basic accessibility guidelines. On the other hand, it may reduce the likelihood that some so-called “accessible” web sites will be littered with alt="this is a spacer graphic".
Does this necessarily mean that the standard is wrong or right? No, not as such. Different standards support different needs — - it is important to keep distinct the purpose of the standard. Conforming HTML is just that: Conforming HTML. It means nothing more.
Nonetheless, as an accessibility advocate, I feel that it’s important to support accessibility issues within the development of new standards. Taking the alt attribute issue in HTML5, for example, the lack of any perceived benefit to not requiring the attribute suggests to me that the better path would be to continue to require it. There are numerous examples of important accessibility aspects in HTML5 which are not yet included.
There seems to be a strong element of specious judgement: elements which are not supported by current user-agents are considered not to be needed. This seems a ridiculous expectation: after all, if unsupported elements aren’t needed, than why develop a new specification at all? What we’ve got must work just fine!
Practically speaking, user-agent support and developer use should both be only marginal issues when trying to decide what elements are most needed in a specification. The fact that elements are unused on either end are not a judgement on the value of that element; merely a judgement on the awareness of the element, on the clarity of the existing specification, or on the complexity of the implementation.
Nobody (or almost nobody) uses the q inline element. Does this mean that the element isn’t valuable, and should be discarded? No. It means that Internet Explorer should add appropriate support for it. The same is true for accessibility issues. The standards should support them to their best abilities: if an element or attribute could hypothetically add to the accessibility of a site, then the fact that it is little used or poorly supported should be entirely irrelevant. Support should follow the standards; not the other way around.
At the root of things, my stance is that I am unwilling to support a standard which specifically excludes features which are needed in order appropriately provide best-practice accessibility. HTML5 is still a long way from being done; and even further from being implemented (if it ever is,) but the removal of such attributes as the header from table markup, the inclusion of defined non-semantic elements such as b, and the “WYSIWYG exemption” on the font element strike me as decisions badly in need of reconsideration.
If we call ourselves professionals, we owe it to our clients, their clients, and ourselves, to do our job properly. A chef must care about health, a builder must care about safety, and we must care about accessibility.
James Edwards, aka ‘Brothercake’ has published a very neat argument on the frequently-asked question “Why Accessibility?”
Read his comments at Why Accessibility? Because it’s our job!.
An interesting thought in indexing and handling page structure is the concept that different areas of a single page can be identified and considered independently from surrounding bodies of content. This particularly applies to specific and readily identifiable data-types, such as phone numbers, postal codes, or abbreviations; but can also be extended to include broader content labeling.
A well-structured XML document has an absolutely clear labeling system for data built into the structure. If you take any RSS feed, for example, the elements which identify <title>, <link> or <managingEditor> can’t readily be mistaken.
A well-structured, semantically sensible XHTML or HTML document doesn’t offer nearly the same degree of data particulation — - the higher level data elements can sometimes be fairly clear, as is the case with <address> or <cite> elements, but other potentially valuable elements end up providing relatively neutral value: <h2> or <div>.
Read more: Thoughts about Content Labeling and Data
Return to Top
