WebAIM Blog

WebAIM is often approached by individuals and organizations concerned about “ADA compliance” of their web site. This is a bit of a misnomer. The Americans with Disabilities Act of 1990 pre-dates and does not address web accessibility at all. That may soon be changing.

This week the US Department of Justice announced that they are considering expanding the scope of the Americans with Disabilities Act to cover some web sites. This is simply a request for comments. The Dept. of Justice will consider your feedback in any formal proposal to expand the ADA.

This announcement has brought much dialogue in the development community, particularly on this popular Slashdot story. It is clear that there are many concerns and misconceptions about what this would mean. There are also many deep-rooted, philosophical arguments against the ADA in general that have come to light. Web regulation is tricky. As a web accessibility consultancy, ADA requirements will certainly bring us more business (though admittedly, our goal is to work ourselves out of employment by making the web entirely accessible – something not likely to happen in the near future). The ADA and its implementation is far from perfect, but I believe that we live in a world where people with disabilities should have opportunities to engage in commerce and online activities uninhibited by discrimination. This has generally not occurred to date.

So, with the assumption that the Department of Justice will recommend that the ADA cover some web sites, I’d like to address some of the concerns and misconceptions about the ADA’s potential application. These all come directly from the Slashdot story comments.

“Why do I have to make my personal web site compliant?”

You don’t. Private web sites would not be covered by the ADA. Government sites and websites that provide “goods, services, and programs to the public”, including shopping and other publicly accessible e-commerce sites, will likely be covered. Where or how this distinction will be made is unknown. It is quite possible that, like physical buildings, different types or classes of web sites would be required to meet different levels of compliance.

“People with disabilities do not use my site”

This same argument was heard when the ADA became law in 1990. Bus operators, for example, complained that they should not have to make their buses accessible because people in wheelchairs did not ride them. Of course they did not, because they could not.

Are you sure people with disabilities do not use your site? If they don’t, is it because it is not as accessible as it could be? There is no way to detect whether a visitor to your site has a disability.

“My content can’t be made accessible.”

The ADA does and would require reasonable efforts and accommodations. Nothing in ADA or any other web accessibility guidelines would require that you fundamentally change what it is you do with your web site. Art galleries would not be required to pull the plug on their site because blind users can’t see their art. Music vendors would not have to close their doors because the Deaf can’t listen to music.

“The web will go back to looking like 1990.”

Most web accessibility happens ‘under the hood’ of a web site. Any accessibility-related modification to the visual design of a site almost universally increases the usability of that site to all users. For example, having sufficient contrast is required for users with some visual disabilities, yet good contrast makes the site more readable by everyone. Captions are necessary for users with auditory disabilities, yet can provide great benefit to anyone watching web video.

Modern, stylish, well-designed, interactive web sites and web applications can fully support accessibility. In fact, they can do so better than any site built in the 1990s.

“Why all the effort for so few people?”

Conservative statistics indicate that at least 8.5% of the population has a disability that would affect internet use. This may not seem significant, though I bet that most web developers spend time ensuring compatibility with browsers that are used by fewer users.

Yes, web accessibility requires some effort, but it is not overly burdensome if you build or purchase a usable site that is built using web standards. Accessible web design is good, usable web design. Efforts made to improve the accessibility for people with disabilities will likely make the site better for everyone.

“There is no economic benefit to being accessible.”

There are certainly costs associated with web accessibility. But there is also potential for great benefits. Consider viewing accessibility as more than simply opening the door to 8.5% of the population, but as an opportunity to directly target that audience and their multi-billion dollar discretionary income.

The web is generally not very accessible now. Those businesses that are ahead of the curve with ADA compliance have the potential to greatly benefit from receiving the business of this audience. Apple, for example, sees this potential; they’ve implemented high levels of accessibility into their new products, such as the iPhone and iPad, despite no regulatory requirement that they do so.

“Accessibility regulations will force me to close my small, online business.”

Perhaps. Accessibility does not come free. The Department of Justice will consider the burden and economic impact when considering whether and how to regulate small business web sites. The further your site is from being designed to web standards, the more expensive and difficult it will be to make accessible. The cost is generally inversely proportional to the accessibility knowledge of the developer building the site.

Thus, there is a need for better web development tools and better educated web developers who are committed to building things with standards in mind. This will come over time; and the regulations will certainly allow for this. When the ADA originally became law, there were many contractors that specialized in making physical spaces accessible. Now, there are simply contractors – nearly all of whom have the technical knowledge to naturally construct things to be accessible. The same is likely to happen with the web – and that is a good thing for everyone.

As noted above, accessibility can be an economic boon, especially for the businesses that do it right and do it early.

“I can’t just make my website accessible over night.”

And there will be no requirement to do so. If web compliance is at all similar to accessibility of physical spaces, there will be allowances for legacy content, transition plans, exemptions for certain types of content or businesses, etc.

The ultimate goal is to become more accessible over time.

“I shouldn’t have to hire a lawyer to make sure I’m compliant with thousands of pages of State and Federal regulations when I publish a web page?”

Accessibility guidelines can be daunting, but they are not overly technical. ADA guidelines will almost certainly mirror or at least reflect the WCAG 2.0 accessibility guidelines. There is a wealth of information (including this WCAG 2.0 evaluation checklist) available here at WebAIM.org and elsewhere.

One would not need a lawyer to verify compliance. Only in the case where a site remains inaccessible and discriminatory with no effort to improve might a lawyer be needed.

If you have additional concerns or thoughts about the ADA and its potential applicability to web content, please post them in the comments below.

As many of you know, I and a very tiny army of WebAIM software engineers are currently hard at work developing WAVE5—the fifth version of our ever-popular WAVE Web Accessibility Evaluation Tool. As part of this process, we’re planning to move from the “static web page” model used for the first four incarnations of WAVE to a more modern and powerful “interactive web application” model. This change will allow us to provide dozens of advanced features and capabilities that were never possible (or at least never feasible) in previous WAVE versions, as well as a level of responsiveness and interactivity we could never achieve before. Generally, we’re all very excited about it.

One of the consequences of this change in architecture is that, starting with version 5, the WAVE tool will require client-side scripting abilities (i.e., will require Javascript be enabled) in order to function. (Users without Javascript enabled will receive a friendly error message telling them that they must enable Javascript in order to use the tool).

Recently, several people who have seen or heard these plans have raised accessibility objections to our requiring Javascript. We are, of course, planning to develop the application with all current and reasonable accessibility features, including use of WAI-ARIA and related web application accessibility techniques. Additionally, we have planned extensive testing with screen readers and other assistive technology in an attempt to verify that all our accessibility components are working harmoniously and successfully.

Usually, objections to this plan do not equate to predictions that we’re going to screw that up or that it won’t be sufficient; rather, they represent an opinion that requiring Javascript for a web application is an automatic accessibility violation. This might be partly a historical feeling, as some older accessibility standards contained language that said (or could be taken to imply) that in order to be accessible, a site had to work with Javascript turned off. I don’t know what motivated the inclusion of those clauses at the time, but would note that most modern accessibility standards merely say that one’s site must be accessible (regardless of whether or not it uses or requires client-side scripting).

The aforementioned objections usually seem to follow one of three lines of reasoning.

1. “You shouldn’t require Javascript because other people will call you out as accessibility hypocrites if you do.”

   Often the person making this comment cannot himself say whether requiring Javascript would actually be an accessibility concern, or may even believe that it wouldn’t, but suggests that we not do it so that we don’t cause problems with other members of the web accessibility community.

2. “You shouldn’t require Javascript because that will create accessibility problems for some of your users.”

   This is slightly less common than the first, and often comes with a statistic that around 10% (or something) of web users are known to browse sites with Javascript turned off.

3. “You shouldn’t require Javascript because that will create an accessibility problem for me (or my brother, uncle, mother-in-law, co-worker, etc).”

   The truth is, I have never actually heard this one. That is, despite several warnings that we should not design WAVE5 to require Javascript, we have nevertheless been unable to locate a single specific web user for whom doing so would create an accessibility problem.

This blog entry is an attempt to start, if anyone is interested, a slightly more public dialog on this topic, where anyone who feels strong about this can state and explain the relevant issues as he sees them. It’s probably pretty clear what side I take on this, so anyone who disagrees with me (especially if you’re number three above) please let me know how you feel in the comments.

Department of Justice seeks public comment on making the web part of covered regulations within the ADA

Along with many of you, WebAIM celebrates the 20th anniversary of the Americans with Disabilities Act (ADA). While we have much to be thankful for, many of us in the web accessibility movement have often wondered when the Federal Government would provide direct clarification on the applicability of the Internet to the ADA. We do have the 1996 letter to Senator Harkin by the Department of Justice to point to the plausibility that the Internet is a covered entity. We all anxiously await each time there is a high profile court case to see if case law might emerge to support web accessibility. But today, of all days, the federal government announced something that should give those of us in the web accessibility movement even greater reason to celebrate.

The Department of Justice (DOJ) announced an Advanced Notice of Proposed Rulemaking on the Accessibility of Web Information and Services Provided by Entities Covered by the ADA. You can read the fact sheet, or the entire notice. In short, the Department is seeking comments on their desire to revise regulation to “…establish specific requirements for State and local governments and public accommodations to make their websites accessible to individuals with disabilities”. The Department is seeking specific comment on many things including the standards they should adopt, and if there should be any exemptions for certain entities (e.g., small business) before they publish their Notice of Proposed Rulemaking. This is amazing news! The impact that this will have for individuals with disabilities cannot be expressed. It is time for our digital society to forever include individuals of all abilities. The period of public comment is open for 180 days. WebAIM will provide our thoughts to DOJ. Will you?

It’s been two months since my first Future Accessibility article, and less than a week since my most recent one, yet several exciting new developments have already made some of the things discussed in the series outdated or incorrect. Here, briefly, are some of those recent changes.

For reference, HTML5 <video>, HTML5 Semantic Elements, New <input> Types in HTML5, HTML5 <input> Extensions, SVG, and canvas.

HTML5 <video>

When I wrote about HTML5 video, the biggest accessibility concern was the lack of any caption or subtitle support in the HTML specification itself, requiring anyone who wanted captions to hack their own system on top of the native video playing capabilities. Work has been progressing somewhat rapidly in that front, and although the solution is still a work in progress, we at least know that it will be present and have a pretty good idea of what it will look like.

Well, sort of. The solution described below is currently only part of the WHATWG’s HTML5 spec, not the W3C’s, so it remains to be seen if some sort of a compromise will yet be worked out to bring both versions of the specification into alignment on this issue.

Specifically, the HTML5 media caption format is called WebSRT, and is a superset of the existing popular SRT format for media subtitles. WebSRT extends SRT by adding some style and mutilingual support not present in the original SRT, while maintaining compatibility with existing SRT files. To go along with this, a new <track> element (and corresponding script API) has been added to HTML5, allowing an arbitrary number of multilingual captions, subtitles, descriptions, and other text-based meta-data to be attached to a specific HTML5 <audio> or <video> element.

No browser has support for any of this yet, since the specification is still being written and debated, but it’s definitely progress.

SVG

In my article on Scalable Vector Graphics, I wrote that “each [user agent] implements a different subset of the spec—no browser (that I know of) has complete support for the full SVG syntax”. Several readers notes in the comments that the current situation is slightly better than this makes it sound: although it is true that each browser implements a different subset of the SVG spec, all major browsers (including the latest preview edition of Internet Explorer 9) implement correctly all (or almost all) of the “core” important things, with the unimplemented features usually being the fringe stuff nobody cares about anyway. (I’m paraphrasing them a bit, but that’s the general idea). In other words, using SVG on the open web in a cross browser way will definitely be a possibility very soon.

Canvas

The most exciting update of all happened just last night, when Microsoft released the newest “Platform Preview” of the upcoming Internet Explorer 9, which contains (happy surprise) nearly complete support for the <canvas> element! Not only that, their hardware accelerated graphics support result in what I’ve been told is the smoothest, fastest <canvas> implementation to date. This means that full cross-browser canvas on the open web will be a reality in the next few years, not a hypothetical.

In the accessibility world, the “extend image map” canvas accessibility proposal has been endorsed by all the major browser vendors, but there are still some objections to it in the HTML5 world. If it is accepted into the spec, it is apparently being planned as an addition to, not a replacement for, the other “shadow DOM” proposal. It’s still too early to tell how this will be resolved, but the discussion is very active (this was all being discussed yesterday), so it’s certainly on track to be figured out sooner rather than later.

This is the sixth in a multipost series about the immediate and likely future of web accessibility. Each week or so I’ll discuss a different upcoming technology, tag, platform, or system from an accessibility perspective. Additions, corrections, or further thoughts are welcome in the comments.

Previous posts: HTML5 <video>, HTML5 Semantic Elements, New <input> Types in HTML5, HTML5 <input> Extensions, SVG.

HTML Canvas

The HTML <canvas> element provides a blank drawing surface via which web application authors can create advanced 2D graphical elements via scripting. In this sense it is similar to (and subject to the inevitable comparisons with) both Adobe’s ubiquitous Flash plugin and the other “advanced web graphics” technology, SVG. The former comparison is probably the better one, since canvas (plus javascript) is indeed capable of doing a fairly large subset of what Flash is popularly used for today.

Browser Support

The <canvas> element was first introduced by Apple almost six years ago, then implemented by Mozilla and Opera, and finally introduced into the HTML5 standard by the WHATWG. Microsoft remains the only major browser vendor not to support canvas at this time, and has neither committed to implement it nor officially specified that they have no intention of doing so; it is probably a safe bet that (barring a late-stage change of priorities or surprise announcement) canvas support will not be present in Internet Explorer 9 (their next major release), but it could easily find its way into version 10 or some other later release.

The lack of complete browser support will likely stall the widespread use of the <canvas> element on the open web. Part of this could be resolved via the explorercanvas project, an open source javascript library that adds canvas support to Internet Explorer via VML (an SVG-like vector graphics format supported only by them); another project, fxCanvas, is attempting to do the same thing using Flash. How either or these projects would deal with the yet-to-be-determined canvas accessibility features remains to be seen.

Accessibility

The HTML5 language specification contains the following note in its section on the <canvas> element:

“When authors use the canvas element, they must also provide content that, when presented to the user, conveys essentially the same function or purpose as the bitmap canvas. This content may be placed as content of the canvas element. The contents of the canvas element, if any, are the element’s fallback content.”

Generally speaking, “fallback content” (i.e., content included to benefit users whose web browsers don’t support a particular feature or format) are not appropriate as accessibility solutions because (to begin with) users with disabilities are likely to be using as modern and powerful browsers as anybody else. The case with canvas is similar; while some sort of DOM-based alternative content is a possible solution to canvas accessibility concerns, that won’t work without some modifications to the spec and/or canvas API.

Accessibility of what?

Solving the canvas accessibility problem is a bit tricky, largely because the <canvas> element (when combined with javascript) is essentially a mini-platform of its own, where just about anything is possible.

The official spec says only one thing about what the <canvas> element can or cannot be used for:

“Authors should not use the canvas element in a document when a more suitable element is available. For example, it is inappropriate to use a canvas element to render a page heading.”

This is a good thing because (as with SVG) emulating existing HTML elements in canvas is likely to result in a significant accessibility hit. But as long as web authors aren’t emulating existing HTML elements, any other use is allowed; more than that, the canvas spec was specifically designed to account for uses nobody has even thought of yet, it being merely a low-level drawing surface with no particular purpose or function in mind. This is what makes canvas so exciting as an addition to HTML, and so complicated from an accessibility perspective.

If one is merely using an HTML canvas to produce on-the-fly 2D graphics, simple alternative text (just like any other graphic in a web document) should provide sufficient accessibility. That’s the easy part. People using canvas to create animated web comics might need some sort of synchronized caption or description capabilities, similar to what’s being developed for the <video> element. That one’s a bit harder, but doable. Then there’s the statistical charts, various games and puzzles, fun physics simulations, drawing applications, and more. (And those are just the things people have built so far.)

Because canvas apps can be so drastically varied in form and function, canvas accessibility is in a sense different for every project. Some use-cases could easily be made completely accessible, while other projects might require a significant amount of work to get accessibility right, while in still other cases full accessibility might not even be possible. Additionally, many of the principles and techniques required to do make canvas apps accessible will more closely match those used for traditional (i.e., desktop) application accessibility, rather than web accessibility as we usually think of it.

This probably explains why the canvas accessibility situation hasn’t been figured out yet (and therefore isn’t really mentioned in the specification language).

Proposed Solutions

As with the HTML5 <video> element, the fact that there aren’t any accessibility features right now doesn’t mean there won’t be soon. Lots of very smart people are working on coming up with a solution, so we can probably safely assume that they’ll figure something useful out at some point. (The W3C isn’t in the habit of giving themselves deadlines, so when exactly that might happen is anybody’s guess.) As of recently, there were two main proposals being discussed, one that involves the concept of an accessible “shadow DOM” and one involving a beefed-up version of the client-side image map. (Somebody involved with the discussion can feel free to correct me in the comments if I get this horribly wrong.)

The shadow DOM concept would provide a canvas alternative via a tree of equivalent elements “underneath” the visual canvas. Essentially, this would make canvas an exception to the rule discussed above, so that an accessible alternative could be included as descendants of the <canvas> element. This would help assistive technology users interact with the canvas content, though it is unclear to me how other users (such as those navigating with only the keyboard) would access the fallback DOM.

The image map solution involves allowing the usemap attribute on canvases, then allowing any element in the DOM to serve as an image map area (as opposed to the area elements used currently). This way an actual button element could be created in the DOM (but possibly hidden from view) and attached to a certain pixel region of a canvas (where a clickable area exists in the canvas application), in the which case the latter region would be keyboard focusable and announced to assistive technologies as if it were an actual (i.e., the actual) html button, with all the flexibility and accessibility that that allows.

Other proposals currently or previously discussed involve extending the canvas javascript API to allow developers to programmatically make certain areas focusable, or provide alternative text to them.

An Opportunity

All of the canvas accessibility solutions discussed in the previous section have one thing in common: they all require some nontrivial work on the part of the developer in order to make accessibility happen. This is, of course, unavoidable, since only the author knows for sure what something is supposed to mean or represent. However, it’s important that we make the solution as simple and easy to both understand and implement as possible, in order to get as many developers as we can to actually use it.

These days, most advanced graphical web applets are created using Adobe’s Flash plugin, and are not typically very accessible. Adobe developers are quick to point out that there is nothing intrinsically inaccessible about Flash itself: accessibility support exists for almost everything, but for one reason or another most flash developers don’t take advantage of these features, and the result is a web overflowing with inaccessible flash apps.

Although Flash isn’t going away any time soon, people are right to expect that much of what is currently being developed with Flash will soon migrate to canvas/javascript systems. With this transition there is an amazing opportunity to make sure that things are done right the second time around. If the eventual accessible canvas solution is flexible enough to handle the multitude of possible canvas uses, yet simple and “normal feeling” enough to get large numbers of developers to use it, it will be a huge gain for global web accessibility as a whole. If that doesn’t happen, then I suppose we won’t be in any worse of a situation than we are right now, but we’ll have missed a big opportunity that could have made a serious positive difference.

The Bottom Line

HTML canvas really neat, but sadly held up by a lack of support in IE. No current accessibility features. Work undergoing to add them.

Further Reading

• Canvas element – Wikipedia [wikipedia.org]
• The canvas element – HTML5 [whatwg.org]
• Let’s Call It A Draw(ing Surface) – Dive Into HTML5 [diveintohtml5.org]
• Canvas – HTML Accessibility Task Force Wiki [w3.org]
• Canvas Element Accessibility Issues – HTML WG Wiki [w3.org]
• ISSUE-74: How accessibility works for <canvas> is unclear [w3.org]
• Thinking About HTML 5 canvas Accessibility [paciellogroup.com]