Thursday, February 25th, 2010
Category: Accessibility, JavaScript, Library
EnhanceJS is a new library from the Filament Group, who are serious about progressive enhancement and accessibility.
What is EnhanceJS?
EnhanceJS is a new JavaScript framework (a single 2.5kb JavaScript file once minified/gzipped) that that automates a series of browser tests to ensure that advanced CSS and JavaScript features will render properly before they’re loaded to the page, enabling you to build advanced, modern websites without introducing accessibility problems for people on browsers that aren't capable of supporting all advanced features. It's designed to be easily integrated into a standard progressive enhancement workflow: just construct the page using standard, functional HTML, and reference any advanced CSS and JavaScript files using EnhanceJS to ensure they're only delivered to browsers capable of understanding them.
So, you have simple markup, if you pass the test you will get "enhanced" with new CSS and JavaScript behaviour additions to take things to the next level. You can even do conditional CSS for IE:
HTML:
-
-
<script type="text/javascript" src="enhance.js"></script>
-
-
enhance({
-
loadStyles: [
-
'css/enhancements.css',
-
{href: 'css/print.css', media: 'print'},
-
{href: 'css/ie6.css', iecondition: 6}
-
],
-
loadScripts: [
-
'js/jquery.min.js',
-
'js/enhancements.js'
-
]
-
});
-
</script>
-
There are detailed docs:
Go to the bottom of their blog post and click on the low-bandwidth version to see it in action.
Sunday, January 10th, 2010
Category: Accessibility
Paul Irish points to a recent survey by WebAIM showing what high-level accessibility guidelines frequently omit to mention: screenreaders and Javascript often co-exist. The study shows between 75% and 90% of screenreader users have Javascript enabled. This isn't just speculation, but a survey of 655 screenreader users.
This response may help strengthen the notion that scripted content must be made accessible. Many developers incorrectly believe that inaccessible scripting is permissible so long as it degrades gracefully or a non-scripted alternative is provided. The vast majority of screen reader respondents encounter scripted content.
Assuming you've solved the accessibility problem just by graceful degradation to raw HTML is fallacy. The whole issue is much more nuanced.
There's also a handy summary of problematic items reported by this user segment, which ranked as follows:
- CAPTCHA - images presenting text used to verify that you are a human user
- The presence of inaccessible Flash content
- Links or buttons that do not make sense
- Images with missing or improper descriptions (alt text)
- Complex or difficult forms
- Lack of keyboard accessibility
- Screens or parts of screens that change unexpectedly
- Missing or improper headings
- Too many links or navigation items
- Complex data tables
- Lack of "skip to main content" or "skip navigation" links
- Inaccessible or missing search functionality
Monday, December 14th, 2009
Category: Accessibility
Weston Ruter has created a nice mashup that marries HTML5 Audio support in modern browsers with the new Google Translate API that does text to speech (for them):
Recently Google Translate announced the ability to hear translations into English spoken via text-to-speech (TTS). Looking at the Firebug Net panel for where this TTS data was coming from, I saw that the speech audio is in MP3 format and is queried via a simple HTTP GET (REST) request: http://translate.google.com/translate_tts?tl=en&q=text. Google Translate notes that the speech is only available for short translations to English, and it turns out that the TTS web service is restricting the text to 100 characters. Another restriction is that the service returns 404 Not Found if the request includes a Referer header (presumably one that is not for translate.google.com).
In spite of the limitations of the web service which certainly reflect the intention that the web service is only to be used by Google Translate, thanks to the new HTML5's Audio element and rel="noreferrer", the service may be utilized by client-side web applications
Others have been playing with text to speech too, such as this French Ubiquity command. I hope that Google makes it a public API of translate!
Friday, November 20th, 2009
Category: Accessibility, HTML, Usability
Todd Kloots is talking accessibility and ARIA, with examples showing how YUI nicely supports these techniques. He explains how to improve in three areas: perception, usability, discoverability.
Can We Do ARIA Today?
Yes.
Firefox and IE (he didn't say which version) have really good support for ARIA. And Opera, Chrome, and Safari. Likewise for the screenreaders - JAWS, Windows Eyes, NVDA - also have good support. An the libraries - YUI, Dojo, JQuery-UI - all have good support baked in, one of the benefits of using ARIA is automatic support.
Improving Perception - ARIA and Screenreaders
Websites can have problems in perception when rendered with a screenreader; it's hard to get the big picture about what the words refer to. With ARIA, we can close the gap in perception. This is another example of progressive enhancement - augment the item by adding properties, markup or Javascript if required:
JAVASCRIPT:
-
-
node.setAttribute("role", "menu")
-
node.role = "menu" // alternative introduced by IE8. IE-only, so don't use!
-
Improving Usability - Keyboard Focus, ARIA, and YUI support
Keyboard access. For some people, it's a necessity, and for others it's still an option or preference (think Vim). To support it, you must be able to tab to the element to get focus, so you should control tabbing with tabindex. A good application of controlling tabbing is, amazingly enough, moving through tabs. Another is modal dialogs; the browser doesn't "know" it's modal, so we have to control focus to make sure it doesn't slip out of the thing that's the only thing users should be able to click on!
Todd shows us just how many steps are required to perform a task in a complex application like Yahoo! mail, using just tabs to navigate through - 19 steps in this example, walking through the toolbar; and even more, when you consider the wider picture of entering the app in the first place. To help with this, he introduces a pattern whereby tabIndexes are updated dynamically to control what comes next, as you move through a toolbar. A negative tabIndex will ensure the element is skipped over.
You can also use the "focus" pseudoclass to ensure focus appearance is consistent for all elements. But, and it's a big one, it's not very well supported; even IE8 doesn't support :focus on <a>, for example. Doing it manually with Javascript has problems, in particular performance. Fortunately, PPK has worked out how to handle focus and blur with event delegation, so that it's much more performant, and the resulting technique is built into YUI3.
Device-independence with markup was also advocated to further improve accessibility:
HTML:
-
-
<input role="menuitem" type="text/>
-
Improving Discoverability - ARIA
Essentially, this is about "random access" and keyboard shortcuts; jumping straight to areas in this page and activating them. The key ARIA feature here is "landmark roles" to identify particular points on the page. This is still something where users aren't aware of the feature, and Todd points out it's not surprising as most screen reader users are self-taught (just under 75% according to the study he showed). Also, not every user is a geek, and the same applies to screen-reader users.
Tuesday, September 15th, 2009
Category: Accessibility
Andrew Sutherland is giving a presentation at The Ajax Experience tomorrow at 9:30am where he will announce the availability of WAMI (Web-Accessible Multimodal Applications).
WAMI is a project out of MIT that lets you plug voice recognition directly into a javascript powered page, and optionally record+save audio files of people talking.
There are a couple of great demo videos that show it in action:
The "hello world" of WAMI is an application that listens to what you say and repeats it back to you, all via:
JAVASCRIPT:
-
-
ar myWamiApp;
-
function onLoad() {
-
//div in which to put the audio button, see below
-
var audioDiv = document.getElementById('AudioContainer');
-
-
// JSGF grammar for your application
-
var jsgf =
-
"#JSGF V1.0;\n" +
-
"grammar parrot;\n" +
-
"public <top> = hello wami | i want a cracker | feed me;\n";
-
-
var grammar = {"language" : "en-us", "grammar" : jsgf };
-
-
//Audio options.
-
//pollForAudio: must be true for speech synthesis to work.
-
//If your application doesn't use speech synthesis, set this to false.
-
var audioOptions = {"pollForAudio" : true};
-
-
//Configuration options.
-
//sendIncrementalResults: if true, you'll receive "incremental" recognition results as the user speaks
-
//sendAggregates: if true, you'll receive a "semantic" interpretation. Your grammar
-
//must follow a specific format.
-
var configOptions = {"sendIncrementalResults" : false, "sendAggregates" : false};
-
-
//Handlers are functions which are called for various events:
-
var handlers = {"onReady" : onWamiReady, //WAMI is loaded and ready
-
"onRecognitionResult" : onWamiRecognitionResult, //Speech recognition result available
-
"onError" : onWamiError, //An error occurred
-
"onTimeout" : onWamiTimeout}; //WAMI timed out due to inactivity
-
-
//Create your WAMI application with the settings and grammar we just created
-
myWamiApp = new WamiApp(audioDiv, handlers, "json", audioOptions, configOptions, grammar);
-
}
-
-
function onWamiReady() {
-
//Called when your WAMI application is ready. You might wait until now
-
//to tell the user it's time to start interacting
-
}
-
-
//called when a speech recognition result is received
-
//since we set sendIncrementalResults to false, this will only
-
//be called after the user finishes speaking. Otherwise,
-
//it will be called many times as the user speaks.
-
function onWamiRecognitionResult(result) {
-
var hyp = result.hyps[0].text; //what we think the user said
-
alert("You said: '" + hyp + "'");
-
myWamiApp.speak(hyp); //Speech synthesis of what we heard
-
setTimeout("myWamiApp.replayLastRecording()", 500); //play back audio we recorded
-
}
-
-
//called when an error occurs
-
function onWamiError(type, message) {
-
alert("WAMI error: type = " + type + ", message = " + message);
-
}
-
-
//called when your WAMI session times out due to
-
//in activity.
-
function onWamiTimeout() {
-
alert("WAMI timed out. Hit reload to start over");
-
}
-
Tuesday, March 3rd, 2009
Category: Accessibility, JavaScript, Library
Daniel Steigerwald has written a nice little standalone library for accessibility called QFocuser.
It features:
- allow to your widget to listen key events when its focused
- focus can be enabled on any element
- fires focus and blur events (so your table row will NOT remain highlighted after click out of table for example)
- make your widget to be accessible by tab key
- tiny and library agnostic
- Works also in Safari!
You can give it a test drive.
As far as usage, you can do things as easily as this:
JAVASCRIPT:
-
-
var focuser = new QFocuser(widgetContainer, {
-
onFocus: function(focusedEl) { .. add highlighted class or whatever }
-
onBlur: function(focusedEl) { .. remove highlighted class or whatever }
-
});
-
-
// attach your own keys listeners
-
$(focuser.getKeyListener()).addEvent('keydown', e.g. handleArrows);
-
-
// when your widget decided to set the focus (and then receive key events)
-
focuser.focus(tableRowForExample);
-
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.
Next Page »
