Wednesday, December 31st, 2008
Category: Accessibility
John Resig wants us to file bug reports to browser vendors but what about accessibility? Is that a responsibility that we have as Web developers?
Todd Kloots of Yahoo! shows us how to configure our machine for screen reader testing with full instructions:
When developing using the WAI-ARIA Roles and States, you need to test your code in a screen reader to ensure everything is working as you expect. As a follow up to my presentation on Developing Accessible Widgets with ARIA and in the interest of helping other developers test their code, I thought I would provide some tips on how to configure your development environment for screen reader testing.
- Install virtualization software
- Install browsers & take a snapshot of that state
- Install and configure screen readers
- Restart the virtual machine & take a snapshot of that state
Wednesday, December 17th, 2008
Category: Accessibility, Ajax, RichTextWidget, Unobtrusive JS, Yahoo!
I am proud to be able to announce the new currency converter on Yahoo finance. Why? Because it is a perfect example of how a complex rich user interface can be built in an accessible manner.
As the main developer, Dirk Ginader explains:
About 9 months ago my fellow co-worker, the User Experience Designer Graham Beale, and I started developing ideas for a prototype of a new Currency Converter for the worldwide relaunch of Yahoo! Finance.
We wanted Features we haven’t seen like this in the Internet so far. We wanted conversion without a page reload, searching for currencies like in the Firefox 3 “awesome bar”, total accessibility, much more and of course everything in realtime.
There will be an in-depth article on how Dirk and his colleagues (with a special mention to Artur Ortega who did all the screen reader testing) build the converter on the Yahoo Developer Blog after the holidays. For now, have a look at the code and see the wonderful attention to detail. One of the main tricks they’ve done can be mentioned already: dynamic re-writing of form labels.
Saturday, September 27th, 2008
Category: Accessibility, Adobe, Flash, Security
Right now you can use Flash to work around a lot of JavaScript limitations and many products use an invisible Flash movie to for example batch upload files (Flickr, Wordpress), play movies in a screenreader accessible manner (with DHTML controls outside the main movie - Yahoo Video, for example) or automatically add content to the browser clipboard (snipurl.com).
All of these will cease to work without user interaction in flash as reported on the adobe devnet. There are very good reasons for it as explained by Lee Brimelow but it is a real problem that will cease to make Flash a useful tool to patch inaccessible solutions.
As long as you cannot access a Flash movie in non-Internet Explorer browsers via keyboard, there will be no such thing as an accessible flash page. Research findings presented at Scripting Enabled last week showed that for example many screen reader users skip Flash as soon as they hear that there is a movie on the page, regardless of how much effort you put in to make the movie itself keyboard enabled. DHTML controls worked around that issue - a button that cannot be accessed is very secure, but also pointless.
There must be some middle ground there somewhere…
Monday, September 22nd, 2008
Category: Accessibility, Editorial
Joe Walker was thinking about accessibility and wrote about a thought experiment that he had where he ponders ‘What if we didn’t lump all “accessibility” requirements together?’
What if, instead, apps are written for one audience. What could you do differently for different use cases?
Designing for Screen Readers
So you want to create a version of your site specifically for screen readers, ignoring everyone else. What might you do?
Scroll bars are generally bad for sighted people. They hide content, slow things down, and some people find them hard to use. But screen readers don’t care about long pages; the scrollbars are invisible anyway. So how about packing the whole site into a single page? Since the graphics are irrelevant, we can skip those, and for many sites still have less to download. The page can then start with a description of the access keys and the user can then navigate really quickly. We could quickly summarize the access keys at each page boundary in case they’ve been forgotten.
Designing for Dyslexia
Dyslexia is generally less of a barrier to web use compared to blindness, however it is very common and often overlooked. In contrast to the low graphic, high text approach for Screen Readers, some dyslexics think in terms of pictures, and may prefer a layout which uses a standard set of icons to back up common concepts. Many users without this disability may find this approach distracting, and it’s certainly going to be annoying to anyone with a screen reader, if the text goes on regular side-tracks reading the ALT text that is only there to back up the text anyway.
Designing for Cognitive Disability
One of the problems with the web, and computers in general is the level of distraction. Distractions are a problem for everyone whatever their abilities, but the problem is exacerbated by disability. I’ve noticed that as people slow down, they start to look around at their screens using their neck muscles, pointing their entire head rather than just their eyes, and I think it’s all about focus. We need a way to narrow our focus to concentrate on the important questions.
It might be possible to have a site where we could “zoom in” on what was important. If you could “zoom-in” to simplify GMail, what would you throw out? Invitations would go, as would links to other services, settings, maybe labels and the 2 sets of buttons that do the same thing. I think many people use email by just seeing their inbox, and maybe search. Ultimately email could be a wizard where you see what’s new and that’s it. Clearly this lack of detail isn’t going to be good for everyone, but having a “simplify it” function could be really useful in many cases.
Designing for Low Vision and Motor Impairment
I don’t know, but I suspect that the “zoom-in” to simplify concept is going to require lots of complex layout. In comparison to which, people with low vision or motor impairment want simple layout. They also want to zoom in, but probably just to make the words/buttons bigger. People with low vision often differ in how they need the screen enhanced. Is it black/white or white/black. Have colors gone, or might a flash of yellow help? Often the OS takes care of much of this problem, but websites that use yellow-fade might be helping, or might not, depending on OS settings. Good design for low vision is probably going to let the user select the type of visual aid that helps.
Of course, this sounds interesting in theory, but we have the sliding scale:
- How many developers build for more than one browser, let alone…
- Old browsers, let alone…
- Accessibility, let alone…
- Multiple accessible sites.
Christian Heilmann talked about having a movement for accessibility, and how we need to not be flailing in the wind.
Monday, September 15th, 2008
Category: Accessibility, Yahoo!
Blogging from @media Ajax. Christian Heilman is talking about the interaction of Ajax/Javascript and accessibility.
BTW Christian’s arranging an accessibility event, including a hack day, this Friday/Saturday in London - Scrpting Enabled. Tickets are free, but booking is required.
Legislation is not the (only) answer. Smart developers can find ways to work with the technology to improve experiences. He’s covering various examples of using the technology to improve accessibility. For example, Flash is evil for accessibility, right? But not if you’re building a chatroom where deaf users can see and sign to each other using video. Pragmatism!
His blog post includes a link to the presentation and a summary of sites he mentions:
Monday, June 9th, 2008
Category: Accessibility, Editorial, Usability
On the Stack Overflow blog, Jeff Attwood asks Is it OK to require JavaScript to participate?
Note that by “participate†I mean “edit, answer or ask a questionâ€. Of course passively reading a question and the associated answers will work fine without JavaScript enabled.
…
While we do believe in progressive enhancement, it’s possible that some of the features we’re building for asking and editing may be so dynamic that they do not degrade well, if at all.
What say you? Is it OK for a website in 2008 to require JavaScript for active (not passive) participation?
On a forum site like StackOverflow, is it an “enhancement” when you add a comment? Not really, which would make me lean towards keeping the site simple and not requiring Javascript for making basic contributions. There is also accessibility to consider (although “accessible” is not the same thing as “Javascript not required”).
It could be argued that as a developer-focused website, Javascript can be assumed. But developers are also the most likely folks to go out of their way and turn Javascript off. And developers are also among the most critical of sites that require Javascript (or Flash) when it could have worked without it.
Wednesday, May 21st, 2008
Category: Accessibility, Usability
We’ve covered the YouTube JavaScript API here before and especially the chance to write your own players in HTML and JavaScript with it. Especially the ext.js based one to one copy of the YouTube interface was of interest.
At the Accessibility2.0 conference in London earlier this year, Antonia Hyde of United Response gave a talk about rich media and web apps for people with learning disabilities and outlined a perfect media player for the needs of this group of disabled web users.
Whilst not ticking all the boxes, I took the YouTube API and created an easy interface for YouTube videos that has big friendly buttons and easy to use volume controls:
You can just add a YouTube URL to the end of the player URL to play the video or download the whole player to host it yourself and style it any way you want.
Check out the blog post about Easy YouTube player to get all the information and try it out.
What I found was that neither mine, nor the extJS nor the demo pages on the YouTube API page work in Opera, which means there is a bug in the API itself.
Wednesday, April 30th, 2008
Category: Accessibility, Ajax
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: Accessibility, Canvas, Library
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: Accessibility, Examples, JavaScript, 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: Accessibility, Google, JavaScript
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: Accessibility, JavaScript, 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: Accessibility, Ajax, 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,
