Future Web Accessibility Updates

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.

Dept. of Justice considers Web for ADA

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?

"

The ADA and the Web: Concerns and Misconceptions

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.

Teaching a Blind Person HTML?

Teaching a Blind Person HTML?: "I’m after some ideas on something here. Tomorrow I will be sitting down with a lad who’s here on work experience who is completely blind. He’s been doing some assessment of various web sites over the last couple of days but tomorrow I have got to try to teach him a bit about building web [...]"

Interview with Accessible Twitter creator Dennis Lembree

Interview with Accessible Twitter creator Dennis Lembree: "Accessify recently spoke to founder of Accessible Twitter Dennis Lembree, who is also behind Web Overhauls and web accessibility podcast Web Axe. We wanted to find out more about the background to Accessible Twitter, what prompted it and where it might go next. Here’s what Dennis had to say: Accessify: Dennis, congratulations on Accessible Twitter: [...]"

Patterns for WAI-ARIA landmark roles in existing HTML

This is a short summary of some methods to add WAI-ARIA landmark roles to existing web pages, e.g. an existing template package for a content management system.

Currently many developers seem to be reluctant to add the role attribute in their markup since it will make pages invalid when using the W3C markup validation service. This is understandable given the attitude developers of content management systems have had to put up with from some people in the industry.

If you want to now more about WAI-ARIA, please have a look at the WAI-ARIA best practices document.

1. Adding the role attribute to relevant elements in markup

This is the easiest way of describing the different parts of your web page, but has the drawback of making the pages invalid. To add the role “main” to a div just add the role attribute with the value “main”:

<div role="main">...</div>

2. Set role attribute values on elements by ID

If your markup already has elements with proper ID attributes that match the landmark regions in scope you can use a simple javascript to set the role attributes when the page has loaded. This will allow your precious template code to pass the markup validation test as well if you or your users worry about that. Consider the following markup fragment:

<div class="special" id="mymaincontent">

<h1>The main content heading</h1>

<p>Some text</p>

</div>

Adding landmarks via the role attribute can be done with a simple javascript like this:

function setRoleAttribute(id, rolevalue) {

if(document.getElementById(id)) {

document.getElementById(id).setAttribute('role', rolevalue);

}

}

function setAriaRoleElementsById() {

//Add all Id:s and aria roles here

setRoleAttribute('mymaincontent', 'main');

}

window.onload=function(){ setAriaRoleElementsById(); }



For a larger example see Landmarks by ID (view source to see details).

3. Set role attribute values on elements via CSS decoration

If you for some reason are more comfortable using CSS classes instead you can create an unobtrusive javascript like this:

function setAriaRoleElements() {

var els = document.getElementsByTagName('*');

var pattern = new RegExp('ariarole-([\\w]+)', 'g');

for ( i=0; i < els.length; i++ ) {

var match = pattern.exec(els[i].className);

if (match && match.length > 1) {

els[i].setAttribute('role', match[1]);

}

}

return;

}

window.onload=function(){ setAriaRoleElements(); }



This will allow you to add CSS classes to existing elements in the following form <div class=”ariarole-main”> and get a role attribute with the value “main” on the same element. This pattern won’t affect validation. For a larger example see Landmarks by CSS decoration.

4. Set role attribute values on arbitrary elements using a javascript library

If you already are using a javascript library like jQuery and Prototype you may be more comfortable using that to set the role attribute. This pattern won’t affect validation. For jQuery a typical example may look like this:

$(document).ready(function() {

$('#mymaincontent').attr('role','main');

});

You can of course use other selector patterns as well.

If you find errors or have suggestions for improvement, please add a comment below. All code examples are free to use without attribution (yes, I am looking at you WTFPL license).

SuperPreview – Nice App, Shame about the Name

SuperPreview – Nice App, Shame about the Name: "It might be the done thing for web developers in certain corners to routinely have a dig at Microsoft – certainly, they’ve given us enough ammo/cause in the past to make this easy (Songsmith, I’m particularly looking at you at the moment!) – but while many of these people will be having a moan about [...]"