Wednesday, April 30th, 2008
Category: Ajax
, Accessibility
John Resig put together a nice overview of the ARIA Live Regions specification with an example of how you can track a list of people in a way that a screen reader can understand when someone is added or deleted. Imagine a todo list application.
HTML:
-
-
<ol aria-live="polite" aria-relevant="additions removals"
-
aria-describedby="users-desc" id="users">
-
-
-
-
-
</ol>
-
Firefox supports this right now (as of 2.0) and we covered AxsJax the toolkit that helps you implement these features, which Google Reader uses to get the job done.
Thursday, April 24th, 2008
Category: Library, Accessibility, Canvas
The picture above is showing you how someone with the color blindness trait Tritanopia would see the image. Michael Deal first created the Color Matrix Library, which supports a large portion of the most common color functions available, including:
Hue, Saturation, Brightness, Contrast, Exposure, Temperature, Tint, Channels, Blindness, Colorize, Threshold, and Invert
Michael then created a canvas library that uses the Color Matrix to help us visualize what our content may look like to people who have various color blind issues. Here is what he did:
The most obvious way would be to do the calculations in CIE XYZ using confusion lines, however, <canvas> uses RGB. So you’d have to convert from XYZ to RGB, run the confusion lines, then convert back to RGB. Here’s an example of what that looks like: Color Blindness Library — It’s great for running on a few colors, but too slow for larger images.
Matrix’s are generally about as quick as you’re going to get for generic color filters, so that’s what I’ve converted the formulas into – compliant with Actionscript’s ColorMatrix, and other programming languages that use standard RGBA matrix’s. Also, I’ve converted them into color transform’s which are useful in Actionscript (ColorTransform), Pixelmator (Image... Channel Mixer), and Photoshop (Image... Adjustments... Channel Mixer).
I used data generated by Matthew Wickline’s formulas to base my blindness library. My script triangulates the hue by comparing the un-filtered, completely saturated, RGB values with the same value after they’d been run through Wickline’s formula.
Wednesday, March 26th, 2008
Category: Accessibility, jQuery
Accessibility is on the minds of most of us and for some companies, it's an absolute priority. The Filament Group is taking accessibility seriously has produced two jQuery extensions that take that into consideration.
Accessible Charts
There's been quite a lot of effort of late to leverage HTML Canvas element for visualization of data but doing so in an accessible way hasn't been a priority. The focus has really been on making data look pretty without much thought to how it should render to those that can't benefit from those extended browser features.
The idea of visualizing HTML table data has been a hot topic lately. The first mention of it that we have seen was Christian Heilmann's YUI blog entry, which provides a clean solution for the problem using the Yahoo library. The idea is a good one: having the data on the page in a table allows it to be accessible, and the chart can be shown as a visual enhancement. Our attempt at solving the problem uses jQuery and provides several types of graphs, such as Pie, Line, Area, and Bar.
Using a combination of jQuery, some custom syntax to define the look of the the canvas element and standard HTML tables, the script can generate results like this:
The library also supports the following types of charts:
- line
- filledLine
- additiveLine
- additiveFilledLine
- pie
- bar
- additiveBar
Accessible Slider
A bigger challenge for the team at Filament Group was developing a slider control which could be accessible. Building a slider requires the use of JavaScript, DOM manipulation and CSS all of which need to be added progressively if such a dynamic control will be viable in a non-JS environment.
Many of the advanced widgets and controls we develop today don't exist in the current HTML specification — there is no "slider" or "accordion" or "menu" element, so we must create one from scratch using markup that isn't semantically correct (divs, spans, unordered lists and the like), and layer on the appearance and behavior using CSS and Javascript. This works well when your audience is using a standards-compliant browser, but what about those using older browsers or mobile devices that only partially support the styles and scripts necessary for it to work? And how do you make the fully functional version — a block of non-specific divs and spans — accessible to assistive technology, like screen readers?
By beginning with standard semantic markup and progressively enhancing it when CSS and JS are available, the FG team was able to come up with a great slide extension that degrades gracefully:
JS/CSS Available:
JS/CSS Unavailable:
With a more complex double-slider scenario, again, the extension degrades gracefully:
JS/CSS Available:
JS/CSS Unavailable:
The team has always worked to make the sliders ARIA-accessible and will continue to refine it to make it compliant with the specification.
Wednesday, February 13th, 2008
Category: JavaScript, Accessibility, Examples, Security, Unobtrusive JS
I've just come across a solution for badges on web sites that makes it terribly easy for implementers. The idea is that the implementer could add a badge wherever they want in an HTML document, choose the look and feel and add a message to be shown. The implementation code is the following:
HTML:
-
-
<script src="badge.js" size="small" skin="blue">Brandname
</script>
-
The badge script then replaces the script node with the badge using the settings defined for each script include. Clever, right? Well, almost. Security concerns and invalid HTML aside (the attributes - content inside a script is valid and should be ignored according to the W3C when a src attribute is present) there are many more issues with this:
- you need to loop through all script nodes, read the info and create the correct badge - this can get slow
- the badge.js script gets called over and over again, even if it is only needed once (granted, it will be cached)
- every script inside a body makes the rendering engine stop, pull the src and try to execute either that or the content of the node - this makes for terrible performance.
I've written up an example of how the above works and three alternative solutions that work around these issues.
What do you think? Should the ease of implementation be the success factor or the performance for the end user?
Wednesday, January 9th, 2008
Category: JavaScript, Accessibility, Google
Accessibility is something most developers consider an afterthought but not Chris Heilmann, web architect at Yahoo!. As a member of the Yahoo! Accessibility Stakeholders group he takes issues concerning accessibility very seriously and makes it a top consideration in everything he builds.
Chris Heilmann recently described his technique for making Google Charts more accessible for those who cannot see pie charts. His technique allows for standard accessible data tables to be converted to charts thus ensuring that visitors using screen readers can take advantage of the data while allowing users of traditional browsers to view the actual charts:
Using this script you can take a simple, valid and accessible data table...and it gets automatically converted to a pie chart.
Simply add the script to the end of the body and it’ll convert all tables with a class called “tochart”. You can define the size (widthxheight) and the colour as a hexadecimal triplet as shown in this example. If you leave size and colour out, the script will use presets you can alter as variables in the script itself.
To verify his code, Chris enlisted the help of a blind friend, also a member of the Yahoo! Accessibility Stakeholders group, who tested it with JAWS.
The script has also been enhanced to allow the creation of accessible data tables when pulling charts via the APIs verbose mode.
As always, it's best to see it in action in order to truly appreciate it. I commend Chris and the Yahoo! Accessibility Stakeholders group for their efforts in making the web more accessible to all.
Thursday, November 15th, 2007
Category: JavaScript, Accessibility, Unobtrusive JS
From what I've seen, it appears that many developers, especially those new to the JS space are somewhat confused by the reasons for developing JS in an unobtrusive fashion. Typical arguments that I've heard are:
- It takes too long to develop
- If they don't have JavasScript, then they're out of luck
- We shouldn't have to code for the 5% that don't want to use an up-to-date browser
I'm sure many of you have heard similar comments and had many debates over the semantics of this topic.
Which leads me to a new blog post that tackles unobtruse JS and provides excellent feedback into the subject. Christian Heilmann continues his advocacy of writing JavaScript in unobtrusive ways in his most recent blog posting, The seven rules of Unobtrusive JavaScript.
Christian's posting not only provides the reasons why it's important but also includes example code that drives the idea home. Right off the bat, he makes several points that really make sense:
Probably the most important feature of unobtrusive JavaScript is that you stop making assumptions:
- You don't expect JavaScript to be available but make it a nice-to-have rather than a dependency
- You don't expect browsers to support certain methods and have the correct properties but you test for them before you access them
- You don't expect the correct HTML to be at your disposal, but check for it and do nothing when it is not available
- You keep your functionality independent of input device
- You expect other scripts to try to interfere with your functionality and keep the scope of your scripts as secure as possible.
I conducted a brief interview with Christian via email and here's what he had to say:
What are the biggest challenges, in terms of unobtrusive JS, that you're seeing in your work? Are you limited in what you can provide to
your audience?
The biggest challenges are that JavaScript is still considered a thing to bolt on or something that comes from a library/framework. Hardly anyone really plans interfaces in two states: one without scripting and one with scripting. A lot of frameworks tell implementers that they do the checking automatically for them, but in reality this is hardly ever the case. Of course you can say you limit yourself to a less interesting interface when you build it unobtrusively, but you also build interfaces that work for everyone. Just because we can totally change the way browsers interact with users with JavaScript that does not necessarily mean we should. Ajax and JavaScript enhanced interfaces should be planned out by developers and user interface designers / IA / Usability / Accessibility experts. As it is a "brave new world" thing this doesn't happen a lot, instead we believe in truisms (this is how drag and drop works, believe us).
Has awareness grown? Do you see more developers actually understanding how to write unobtrusive JS and using it in practice?
Yes it has, the hits I get on the article and especially this new one show that. However whenever you talk about JavaScript, there are a lot of "experts" who love to bring their own agenda in. It is good though to see other people than me stating why things make sense. The thread on reddit http://programming.reddit.com/info/60gtv/comments/ is pretty cool in that way.
With so many libraries out there at the moment, it's natural for beginners to look for some help by using them. Has this impacted, negatively or positively, the application of unobtrusive JS techniques?
Neither nor I'd say. It depends on the library. I've been adamant to change some of the examples that come with the YUI to be unobtrusive, and I am in contact with other library developers to do the same. Whenever I've covered the topic of libraries in my books I also made sure the examples show how you can do things unobtrusively. It is a bit of a shame that a lot of libraries don't wear that idea on their sleeves though, this is something I'd love to see. The release that made me the happiest was Dan Webb's unobtrusive plugin for Ruby on Rails: http://www.ujs4rails.com/. It is up to people to start advertising the unobtrusive use of libraries more. I am currently doing that with an article series on dev.opera.com, and every publisher I am in contact with is crying out for books about using libraries. So if you are inclined to write, this is the time.
You can read more about Christian's views on unobtrusive JavaScript at his blog post: The seven rules of Unobtrusive JavaScript
Wednesday, November 14th, 2007
Category: Ajax, Accessibility, Firefox
Charles L. Chen, the developer behind the Fire Vox Firefox plugin that enables the browser to talk to you, has released a new open source project, AxsJAX.
In my first week at Google, I discovered Google Reader a highly optimized feed reader with very good keyboard support. For my starter project at Google, I decided to access-enable this application using W3C ARIA. Using Greasemonkey, I could inject JavaScript code to add the needed ARIA bits to make Google Reader say the right things at the right time.
Based on the experience of access-enabling Reader, we have now refactored the code to come up with a common JavaScript framework for enhancing the accessibility of AJAX applications. This framework is called AxsJAX, and it was refined in the process of access-enabling Web Search.
We're now excited to open-source this framework since we believe that there is nothing Google-specific in the techniques we have implemented. We invite the Web developer community to help us collectively define a robust framework for rapid prototyping of accessibility enhancements to Web 2.0 applications.
The ability to rapidly prototype end-user interaction has led to an explosion in the number of AJAX applications; until now, visually impaired users have been left behind in this process. We hope that the AxsJAX framework encourages the Web community to bring the power of Web 2.0 development to solving the problem of accessing rich Web interaction in an eyes-free environment.
What AxsJAX does...
The AxsJAX framework helps inject accessibility features into these applications so that users of adaptive technologies such as screen readers and self-voicing browsers experience the same level of interactivity that is now taken for granted by users of Web 2.0 applications.
AxsJAX injects accessibility enhancements as defined by W3C ARIA. The prerequisites for experiencing its benefits include:
- A modern Web browser like Firefox 2.0 or later that supports W3C ARIA.
- Adaptive technologies that respond correctly to the accessibility enhancements introduced by W3C ARIA.
- In particular, many of the enhancements injected by AxsJAX depend on support for live regions a feature that enables adaptive technologies like screen readers and self-voicing browsers deal correctly with asynchronous updates to portions of a Web page.
The AxsJAX framework can inject accessibility enhancements into existing Web 2.0 applications using any of several standard Web techniques:
- As a bookmarklet --- small snippets of JavaScript? that are used to create smart bookmarks.
- Using Greasemonkey --- a powerful browser extension that allows end-users to customize the look and feel of Web sites via custom scripts.
- Using Fire Vox --- Fire Vox, an open source talking browser extension for Firefox, automatically injects the AxsJAX scripts if the "Use site specific enhancements" option is turned on.
Thursday, October 4th, 2007
Category: Accessibility
A recent press release by the National Federation of the Blind discusses two rulings that could have a dramatic impact on accessibility requirements:
A federal district court judge issued two landmark decisions today in a nationwide class action against Target Corporation. First, the court certified the case as a class action on behalf of blind Internet users throughout the country under the Americans With Disabilities Act (ADA). Second, the court held that Web sites such as target.com are required by California law to be accessible.
Accessibility has been a hot topic but with no real laws in place to enforce it, many developers have considered it an afterthought. These rulings could be a real wake up call for those that have overlooked the need for accessible websites and if taken further, could have a dramatic effect on existing businesses who would need to extensively revamp their Internet initiatives.
The President of the National Federation of the Blind, Dr. Marc Maurer, commented on the court's ruling: "This is a tremendous step forward for blind people throughout the country who for too long have been denied equal access to the Internet economy. All e-commerce businesses should take note of this decision and immediately take steps to open their doors to the blind."
If you're interested in learning more about accessibility, Max Keisler has a posting listing over 40 tutorials and articles on accessibility. In addition, the Illinois Center for Information Technology Accessibility has created a Firefox plugin that can help you in testing your web applications for markup and structural adherence to functional web accessibility.
Finally, The Ajax Experience will have two presentations presentations regarding accessibility:
I ask that Ajaxian readers post links to good web accessibility reference material to help those unfamiliar with this topic become more aware of the considerations in making accessible web applications.
Friday, August 31st, 2007
Category: Accessibility, jQuery
Everyone's throwing up JavaScript functionality left and right, most of the time without giving any thought to accessibility. Not so for Brian Reindel who has created an accessible news slider component which meets the requirements of the W3C's Web Content Accessibility Guidelines 1.0.
Brian really gave the development of this jQuery plugin some good thought as attested by his overview of the functionality:
- The JavaScript is only 2KB compressed.
- The XHTML and JavaScript were developed specifically to meet the WCAG 1.0, and this will always be the number one priority of the plugin. It is suggested that if you modify the XHTML, you do so keeping this in mind.
- Users with color vision deficiency, or color blindness
The plugin does not use color as a primary indicator of a change in state for the slider. Instead, the "previous" and "next" arrows are either visible or hidden, depending on the location of the news slider. There is also an indicator that communicates the total number of news stories in the slider.
- Users with limited or poor vision, but who do not use a screen reader
If the user chooses to resize the text via the browser file menu, the slider will flex vertically to accommodate the larger text, and still function. This is primarily a function of the CSS, and it is suggested you maintain a variable font size on your site in order to take advantage of this capability.
- Users that are legally blind, and who browse Web pages with a screen reader
Since screen readers actually read through the code, it is important that the XHTML be formatted free of confusion. The appropriate skip links and title tags have been included for navigation and messaging. The important thing to remember is that screen readers like JAWS ignore elements with the display property set to "none", or with the visibility property set to "hidden". This helps significantly in managing the presentation to several categories of disabled users.
- Users that browse with the keyboard and an adaptive device such as a mouth stick
When developing a Web component to be accessible, this is the most difficult group of disabled users to accommodate. If you have ever tried to browse by tabbing through a Web page, it can be frustrating. Although the core functionality of the news slider is partially accessible with a keyboard, the "View All" link was added as a catch-all mechanism.
- Users who have turned off JavaScript or CSS
The key was to make sure that not only were all the news stories readable with JavaScript or CSS turned off, but that the appropriate messaging was displayed to the user to inform them of the implications. Although not a category that I think fits explicitly under accessibility, it is a component of the WCAG 1.0 checkpoints, and strides were taken to make sure the plugin met these requirements.
You can download the plugin here and you'll need to pick up a copy of jQuery v1.1.3.1 or higher in order to use it.
Thursday, April 12th, 2007
Category: Accessibility
Martin Kliehm has written up a nice overview of what is going on in the world of accessible Web 2.0 applications.
The article documents the Accessible Rich Internet Applications (ARIA) work, primarily done by Becky Gibson, Aaron Leventhal, and Richard Schwerdtfeger.
One of the core problems is that anything can be an input of some time. What we see as a slider could just be <div class="slider"> and how would a screen reader know what to do there?
This is where roles come in:
Roles come in two flavors: XHTML and WAI‑ARIA. A basic set is defined in the XHTML 1.1 Role Attribute Module. It is extended by the WAI‑ARIA Role RDF taxonomy. WAI‑ARIA roles have the wairole prefix, like in role="wairole:slider".
Roles are further divided into widgets and structural roles. Widget roles include progressbar, slider, button, tree, textfield, checkbox, alert, and dialog. So if you want to use a fancy layer instead of a system dialog box, you can tell screen readers what it is by using role="dialog". More cool widget examples can be found at mozilla.org.
I have been playing more and more with the graceful failback side of Ajax, and how microformats can help out. It seems to be able adding semantics to our simple building box (CSS classes and such).
Monday, February 19th, 2007
Category: Accessibility
Joe Hanink let us know that Section 508 is under revision via the W3C Roadmap for Accessible Rich Internet Applications (WAI-ARIA).
As a developer of Rich webapps, Section 508 compliance is a concern since its most recent update occurred in 2001. I am awaiting feedback from access-board.gov on whether there will be any provisioning for transitional compliance for webapps built after the announcement but before the new rules take effect.
The w3c WAI-ARIA draft indicates what mechanisms will be standardized to allow webapps to communicate semantic details to API driven screen readers, but there I’ve been unable to find any public information about the specifics of the new 508 rules.
Friday, February 16th, 2007
Category: Accessibility, Unobtrusive JS
Ara Pehlivanian talked about the graceful degradation myth awhile back, and since then has come up with a simple solution to his problem.
The key is setting CSS styles aimed at JS enabled browsers that overwrite the initial state in the document that does the right thing for someone who isn't coming in via a JavaScript enabled environment (e.g. accessible).
Here is an example of a window that drops down content in JS mode, and shows it without thus not blocking that content from non-JS view.
The CSS
Brand CSS for items that you want to override via hasJS classnames.
CSS:
-
-
body.hasJS {
-
background-color: #0f0;
-
}
-
-
body {
-
background: #f00;
-
}
-
JavaScript
Turn on that CSS via JavaScript (addClassName):
HTML:
-
-
<script type="text/javascript">document.body.className += "hasJS"
</script>
-
-
-
<h1 id="toggle">This is a window head
</h1>
-
</div>
-
<div class="content" id="toggleContent">
-
<p>This is the windows contents.
</p>
-
<p>And some more content...
</p>
-
</div>
-
</div>
-
Do you use these tactics?
Wednesday, January 24th, 2007
Category: Accessibility
Gez Lemon and Steve Faulkner have gone into more detail on using the virtual buffer in JAWS to enable Ajax interactions.
Popular screen readers use a virtual buffer to allow users to interact with web content, whereby the virtual buffer provides a mechanism for screen reader users to interact with web content. This article uncovers undocumented behaviour in JAWS 7.1 and later, which allows web developers to build Ajax applications that update the virtual buffer without any interaction from the user.
The hack relies on a hidden input form:
JAVASCRIPT:
-
-
function prepareBuffer() {
-
var objNew = document.createElement('p');
-
var objHidden = document.createElement('input');
-
-
objHidden.setAttribute('type', 'hidden');
-
objHidden.setAttribute('value', '1');
-
objHidden.setAttribute('id', 'virtualbufferupdate');
-
objHidden.setAttribute('name', 'virtualbufferupdate');
-
-
objNew.appendChild(objHidden);
-
document.body.appendChild(objNew);
-
}
-
Thursday, November 16th, 2006
Category: Editorial, Accessibility, Mobile, Rails
Phil Greenspun bemoans the difficulty of running modern web apps from his sidekick.
My Motorola/Windows XP phone began to die after two years. Wanting something that would let me keep in touch with friends over AOL Instant Messenger, I got a T-Mobile Sidekick. I was reluctant to get a non-flip phone, but so far I have only managed to make one unintended phone call per day. The Web browser is excruciatingly slow. I’ve found that most of the Web sites developed in the early 1990s work just fine. It is possible to log in, fill out forms, get results. What doesn’t work? The latest and greatest Web sites. They are too script-heavy. Programmers seem to have forgotten that although the average desktop has ever-greater capabilities, the average user is increasingly connecting from a handheld device. I tried using one of my students’ sites from last semester. They lifted some username/password code from a Ruby on Rails toolkit. It relies on JavaScript. The site is 100 percent useless from the Sidekick.
Have we proven that “the better the tools the worse the application?”
Seems unfair to blame Rails for this ... Rails makes it just as easy to build accessible websites as it does to build pure-Ajax websites. Can you blame Ajax for this? Yes, a bit ... it's true that most web developers are more focused on delivering rich, interactive, experiences than making sites accessible from the mobile. In this example, it is indeed quite ridiculous that someone created a login page requiring Javascript. For more dynamic applications, though, it's just not practical or worthwhile to make the site mobile-compatible.
Greenspun mentions that many early '90s websites work quite well on the phone, but it must be said that many sites created in the late '90s or early '00s would work really poorly on the phone, because those were the times when many developers used Flash or Javascript for the sake of it (mmmm...cascading menus) and were oblivious to web standards. A major theme in many Ajax apps is to use well-known web conventions where possible, and augment them with dynamic behaviour where necessary. For that reason, many modern Ajax apps are actually more accessible than their equivalents from a few years back.
