Behind every accessibility achievement, there is usually a story of perseverance, patience and tolerance. Rarely do we get to hear about the people behind these achievements and rarer still do we hear why perseverance, patience and tolerance were required. This is an update on an ongoing advocacy effort to make images on the web more accessible.
ARIA adds hidden information to HTML to make widgets accessible. Some believe that ARIA can also replace existing HTML accessibility features to make content accessible. Is it worth the effort to remove specialized built-in HTML accessibility features in favor of this generic add-on technology, or is ARIA for content doomed to failure?
Many people interpret the HTML spec to define
alt as a short description of an image and
longdesc as a detailed description. Is this useful? This definition of
alt does not take into consideration the context of the image, making comprehension difficult when reading content containing images that cannot be seen. The definition of
longdesc is also problematic, because content authors see little point in writing two versions of a description whose only difference is their length. So, what is it that we really need?
Jared Smith from WebAIM asks on Twitter "Want to help fix HTML5 accessibility? Convince AT vendors to be actively and adamantly involved in the process." Why are authoring tool and assistive technology vendors not actively participating in HTML5 development? Will simply asking tool/AT vendors convince them to get engaged in the process?
Regardless of your stance on whether longdesc should be part of HTML, I think we can all agree that the ability to textually describe non-textual objects, such as images, is a desirable feature for the Web. So I would like to propose a way to:
- make it easier for content authors to use longdesc right now
- offer a seamless transition path that will replace the longdesc feature with a technology that makes it supremely easy to describe images
- and ensure that this feature benefits everyone
The HTML Working Group at W3C is working on a document that is an extension to the HTML5 specification on how to write alternate text. The document is meant to be read by non-technical content authors, and will also become the basis for future derivative works such as articles, tutorials, and references. This document takes the simple concept of alternate text and morphs it into a 45-page monster tome that is full of conditional rules. Will this effort make the Web more accessible, or will it have the opposite effect and create the perception that Web accessibility is overly complex?
As professional Web designers and developers, we can use and support HTML5, but at the same time we need to be able to discuss the shortcomings and limitations of the technology. In this way, we can avoid pitfalls and provide invaluable feedback to the HTML5 team, to help improve HTML.
To the dismay of many accessibility experts and advocates, the
longdesc attribute has been dropped from the HTML5 spec because this feature is not popular. Despite its lack of use, this feature has the potential to improve Web accessibility if used and used correctly. So in the interest of making the Web more accessible, I would like to make an offer to the HTML5 team to save
longdesc attribute, although potentially useful, was removed from the HTML5 specification, despite recommendations to retain it from the HTML Accessibility Task Force. The decision to drop
longdesc was a lazy response on the part of the HTML5 team: the attribute isn't popular, so let's ditch it. At the same time, the Task Force's attempts to simply reinstate the
longdesc attribute won't suddenly make the attribute popular, or ensure it is used as intended. What both parties need to do is remember their obligations. Once they do that, a proper solution will emerge.
Different guidelines recommend different maximum lengths for alternate text. Some recommend 80, 100, or 150 characters. Some have even calculated different maximum lengths based on language (e.g. 100 for English versus 115 for German). Some accessibility checkers also raise warnings if alternate text is too short. So what should be the minimum and maximum lengths for alternate text?
We take for granted that photo-sharing sites must have alternate text for photos in order to be accessible. After all, the assumption is that alternate text makes images accessible in content-rich Web pages; so why not use alternate text to make stand-alone photos accessible? Or is it time to challenge this assumption and have a debate on whether or not alternate text is the best way to make photo-sharing sites accessible?
As a new CEO of W3C takes the reins, the mission of W3C is getting a look over. W3C is the self-appointed steward of the Web. What happens at W3C will ultimately affect us all because the Web has become an integral part of our society. Going forward, W3C has made a commitment to be mindful of the needs of all Web users. How will they fulfill this commitment? And do you trust W3C to represent your interests?
Accessibility checklists based on WCAG or Section 508 guidelines were intended to help make Web sites accessible. These checklists are meant to ensure that the process of accessibility checking is done consistently and comprehensively. So how can accessibility checklists be harmful?
In HTML, an image is made up of visual and textual data (alternate text). Most Web browsers attempt to render alternate text when visual data is not available. However, only one browser currently uses alternate text when pasting images into other applications.
Are we, the stakeholders in Web technology, doing the right things to move Web accessibility forward? Shouldn't we perhaps re-evaluate our strategy, to confirm what we are doing is right, or to find out if we need to develop new strategies?
Microsoft released a preview of IE 9 with support for XHTML and Scalable Vector Graphics (SVG). Microsoft should be commended for supporting XHTML, SVG and their attempt to make application development easier using these technologies. However, their implementation of XHTML and SVG in IE 9 destroys the very essence of these technologies - which is that they must be used according to specification.
<img> element is one of the more difficult HTML elements to use correctly. Part of the problem is caused by the unhelpful definition of the
<img> element in the HTML specification.
Recently, Steve Faulkner performed a detailed comparison of how the leading Web browsers render alternative text that revealed non-uniform behaviour across browsers. Steve called for the HTML5 team to document a recommended behaviour. This article adds to Steve's work and makes a case for what I believe to be the correct way to render alternative text.
The Web is now so tightly integrated into our society that it's second nature to obtain employment, access education, do commerce, get information, get entertainment and even build social relationships online. If the Web is now a permanent and integral part of our society, then is denying a group of people access to much of the Web a form of discrimination and a denial of a human right?
A number of renowned HTML5 supporters are advocating the use of HTML5 to the general public while the spec is still in development, unproven, and subject to change. Is this in the best interest of Web site creators or simply irresponsible behaviour?
HTML5 was conceived and continues to be developed within a group of likeminded people. There has not been any in-depth debate about the design principles of HTML5, the direction in which HTML5 is heading, nor the process in which HTML5 is developed. As a result, HTML5 may not be meeting the needs of many stakeholders in Web technology and may be insufficient to significantly evolve the Web. I invite the HTML5 team to a series of debates, with myself and others, on HTML5 and the future of Web technology.
Currently, each Web browser silently auto-corrects invalid HTML in a different way. HTML5 will harmonize the auto-correction of invalid HTML, so that all browsers will fix errors in the same way. Uniform auto-correction of invalid HTML behaviour across all browsers can only lead to good things - right? Or will this create even more invalid HTML on the Web?
The Web works with valid and invalid HTML. So why is valid HTML important? And how does invalid HTML affect everyone who uses the Web?
One of the primary reasons HTML is authored incorrectly today is because Web browsers do not display error messages when processing corrupt documents (constructed or transmitted incorrectly). Web browser vendors like to refer to these kinds of error messages as "draconian", i.e. unduly punitive. Why?
The transition from existing to future Web technology needs to be smooth or the Web could break. When HTML5 was conceived, it was taken for granted that the future specification (i.e. the language itself) needs to be backwards and forwards compatible. All design decisions in HTML5 are influenced by these two assumptions. If these assumptions are false and there are better alternatives for a smooth transition of the technology, is HTML5 a big design mistake?
What happens when Web browser vendors design new HTML features but don't consult with other parties such as vendors of WYSIWYG editors? We end up with a markup language that's difficult to author and prone to the same misuse as previous versions of HTML.
HTML5 will make the Web browser into an application runtime environment similar to how Java and .NET work, but will use a mishmash of old technologies to achieve this. Is this good for application developers? Is this a good way to develop applications for the next 20 years or is this a big step backwards in application development?
A few years ago I interviewed Ian Hickson, editor of the HTML5 spec. He inferred that the ability to author invalid HTML and have Web browsers silently auto-correct it is the reason the Web has been so "wildly" successful. Unfortunately, many people share his opinion, so it's time to dispel this myth and give credit to the real factors behind the success of the Web.
The HTML specification is a failure because, of its intended users, practically no one is using it as it was intended to be used. Why? Is HTML too difficult to use correctly? Is the incorrect use of HTML explained by a lack of education? Did W3C mismanage the deployment of HTML? Or is the failure of the HTML specification due to a lack of error feedback?
It may be hard to imagine right now, but at some point in time, the Web as we know it will cease to exist. Will the Web be replaced by a competing Internet application or will it simply evolve/morph into a completely different technology?