Category: html5

Response to MSDN Article “Designing Accessibility with HTML5”

This blog is a review/response to the recent MSDN article Designing Accessibility with HTML5 by Rajesh Lal (@irajlal). The article is quite extensive and covers an intro to accessibility and disability, progressive enhancement, ARIA, forms, tables, and more.

I had actually reviewed an early version of this article, but it seems some of my feedback was not incorporated, and there is also some new content in the article. So let’s discuss some of those items and more.

The introduction does an adequate job of covering the four main types of disabilities: hearing, mobility, cognitive, and visual. For reference, here’s the link to the WCAG 2.0 POUR model (perceivable, operable, understandable, robust) as mentioned.

Progressive Enhancement

I was happy that Progressive Enhancement (PE) was mentioned next, early in the article. I firmly believe that semantic markup and PE are essential to a robust and accessible webpage. PE was described fairly well, but then I was disappointed to see example code further down the page which does not use PE. In Figure 9, the form example is missing a URL in the action attribute and contains the following line to submit:

<div><a href="#" onclick="submit()">Send Your Message!</a></div>

This line does not represent proper semantic markup, progressive enhancement, nor the non-JavaScript use case. A better example would be to add a dummy URL in the action attribute, and for the submit button, do this:

<input type="submit" value="Send Your Message!" />

Headings

In Figures 6 and 7, home page sample code, the document outline is broken. The heading order jumps from H2 to H4 so is missing the H3. It also appears that the H4 elements in the aside element are correlated to the last H2, which in incorrect; they are separate topics. To solve, I would insert an H2 heading in the aside element and change the H4 elements to H3. In addition, there is no H1 element.

Figure 11, Markup for a FAQ Page, does indeed provide an ideal heading structure.

A perfect heading structure is not essential, but certainly helps. Especially when the code is an example for other developers.

And for the record, in Figures 6 and 7, the image element for the logo is missing alt text.

JavaScript Insertion

It’s good that the author recommends placing the external JavaScript files at the end of the body (at end of home page section), but remember that you may need to put certain JavaScript at the top, mostly scripts for feature detection such as Modernizr. (This isn’t really accessibility but thought I’d include anyway.)

Fieldset/Legend

In the Contact Form section, I really like that the sample code is using the placeholder attribute correctly. But there’s one issue; the fieldset element is being used but the legend is missing. The spec oddly says legend is optional, but it’s definitely best practice to use it. Otherwise, there’s no reason to use fieldset in the first place as far as I know.

Data Table

In the data table, use of a caption element is great, but I’m perplexed as to why there is a details and summary element within the caption. And I wouldn’t recommend using a strong element with the caption text; use CSS instead. Also, the TH elements should have a scope attribute; it may not be necessary with newer assistive technologies, but makes the code more robust and semantic.

Links, titles, and abbreviations

Towards the end of the article, there’s a section on links and images. I really advocate this advice: Use a CSS background image if your design requires an icon such as “>”.

Just before that, I have issues with the sample text link. Avoid “click here” is good, but then the title attribute contains “click for”. This somewhat of a moot point as the title isn’t needed at all. Traditionally, the title attribute is only needed for additional supplementary information (not required for user). The mighty Steve Faulker, in his article Using HTML title attribute, suggests that title only be used in a couple rare cases.

For images, I would not recommend the title attribute here either (due to lack of support). For even more on that, check out this recent article about title attributes on the RNIB site.

About the link underline, of course I agree that text links (in main content especially) should be underlined. The sample CSS adds the underline, but it’s much better to do this by not removing it in the first place. The underline does not have to be added; it should already be there by default.

The abbreviation example is simple and solid, but there’s more to it than that. Because of poor support, the title attribute doesn’t work typically with the keyboard and some assistive technologies (see links above). Therefore, I strongly suggest that the full text of the acronym or abbreviation is written out when it first appears on each page.

Final Thoughts

I don’t have much to say about the audio/video section; I’m just wondering where the keyboard shortcuts listed for the HTML5 media controls comes from.

It’s great to see that Visual Studio 2012 has ARIA support. I know it’s still a popular application, but I don’t have much experience with it myself.

The MSDN article Designing Accessibility with HTML5 has a lot of good information and tips. But many times, especially with accessibility, the devil is in the details. It is quite a tricky topic and there are many nuances and gray areas. I hope this response has cleared up some of those.

Podcast #96: WordPress, Events

Dennis and Ross are back! It’s been a while since the last podcast, and the guys catch up on events, news, and lots of great things happening with accessibility on WordPress.

Download Web Axe Episode 96 (WordPress, Events)

[transcript of podcast 96]

New Song!

So besides a new website, there’s a new Web Axe theme song! The vocal track isn’t added yet, so this episode will have an instrumental version.

The original WebAxe Theme Music is composed and produced by Jeff Ensign a.k.a. Evolution Noise Slave. Check out his work at glafizya.com.

Goings On

News

WordPress

Links

Events

Book Review: Pro HTML5 Accessibility

Recently I finally made time to read the book Pro HTML5 Accessibility by Joshue O Connor (@joshueoconnor), released in late March 2012 by Apress. Let’s take a look at each chapter.

book cover

Chapter 1, Introduction to HTML5 Accessibility, covers exactly that. First, the differences between HTML5, HTML4, and XHTML are explained. Then the basics of web accessibility and theory are discussed including the four principles of WCAG 2.0 (POUR). Legislation is also discussed including Section 504/508 and ADA (US) and PAS78 and DDA (UK).

Accessibility should enhance your design—not destroy it.

Chapter 2, Understanding Disability and Assistive Technology, describes different types of disability, and goes into more detail about visual impairments. Assistive technology (AT) is explained such as screen readers, screen magnifiers, and switches; the most popular screen readers JAWS, VoiceOver, NVDA are discussed in more detail.

Chapter 3 is about JavaScript and ARIA, and sure covers a lot. Nice to see progressive enhancement (PE) explained first; along with semantic markup, PE is a grounding technique which still many developers do not practice, unfortunately. The chapter then discusses event handler best practices, use of tabindex and no script, and references WCAG2 scripting techniques and failures. The DOJO, jQuery UI, and FLUID JavaScript libraries are mentioned, but surprisingly not YUI.

The next section in this chapter provides great information on ARIA (Accessible Rich Internet Applications) including the explanation of the following important attributes: live region, label/describedby, menu, and landmark roles. An ARIA state and role reference is also included.

Accessible drag-and-drop is mentioned briefly at the end of the chapter, but would have liked to see more on this topic. I guess everything can’t be included! For more on this topic, start with Accessibility & Native Drag and Drop by the HTML5 Doctor.

Chapter 4, API and DOM, is a shorter and a bit dryer chapter, but definitely contains interesting and necessary information. The off-screen model (OSM) and accessibility APIs are defined, and how they work with browsers and AT. Accessibility APIs discussed include MSAA (the “older brother”); IAccessible 2; and the Apple, Webkit, and Linux versions.

Chapter 5 gives explanation and references to new HTML5 semantic elements and attributes. A lengthy list of event handler attributes is provided. The chapter also includes an interesting mapping of new elements against the implied ARIA role. In addition, I like that the importance of headings is explained; this is a very basic and vital practice that if often overlooked. The hgroup element is discussed a fair amount, but the rumor is that it is being dropped from the HTML5 specification.

Chapter 6 is titled Images, Rich Media, Audio, and Video in HTML5. The first half of the chapter alone (about 21 pages) discusses alternative text for images. This lengthy section is great because even though this is a basic requirement, implementing alt text can be quite tricky depending on the how an image is used (or not used) and is often done incorrectly if at all.

It’s great that the author is a supporter of the longdesc attribute which is now made obsolete in HTML5. I also advocate the longdesc attribute which points to an off-page resource; this behavior cannot be replicated with ARIA. Longdesc is not only used much in academia as the book states, but also for government websites and comics. A good example of alt text using describedby is given, but no solution for an external long description. Read more about this in my two-part article Longdesc & Other Long Image Description Solutions.

Although ARIA is great and HTML5 has made advances in many areas, neither currently provides a fully-functional replacement for @longdesc

I would have liked to read more on sprites as this is a popular design technique which causes many accessibility problems. For more on this topic, check out Notes on accessible CSS image sprites by Steve Faulkner.

The second part of Chapter 6 covers HTML5 audio and video. Issues with Flash for video are presented, and then the HTML5 media elements and attributes are covered. I’d like to point out that the autoplay attribute is bad for accessibility and usability as it automatically starts the media on page load and therefore removes control from the user.

A solid video code example is provided for embedding media and creating custom controls. I noticed that the fallback example was not what I expected as it didn’t include Flash nor a simple file download link. For more on this topic, start with Creating Your Own Accessible HTML5 Media Player by Terrill Thompson.

It’s great to see the Track element explained as it’s great for captions, audio description, etc. Although it’s not supported quite yet, many of us are in great anticipation and is definitely worth learning now.

Lastly, Chapter 6 suggests some great media encoding tools and explains the media types and supporting browsers.

Chapter 7, HTML5 and Accessible Data Tables, provides a great explanation and many code examples of basic and complex data tables, including the headers attribute technique. The author disagrees with deprecation of summary attribute, but I do not so much. The summary attribute is often not implemented correctly and is difficult to maintain; the content can be in the table caption or main content; screen readers can give the same information about a table that the summary attribute is originally intended for (an overview of the structure of the data table). But a great alternative method to summary is provided, using aria-describedby, which I do advocate.

In Chapter 8, HTML5 and Accessible Forms, a thorough explanation is given of the basics and complexities of accessible web forms. For form element labels, three techniques are described. I agree with the author in that explicit labeling (for/id) should be used over the implicit (wrapped) method. Or over any other method (such as title or placeholder) for that matter. Also discussed are many of the new HTML5 form elements (output, progress) and input types (tel, email, date, time) including a few details on browser support, or lack thereof.

However, in terms of making your forms more bulletproof and working with older legacy AT, I recommend sticking with the for/id method for now.

Useful tidbits are included such as the inconsistent screen reader support of optgroup element; how to style placeholder attribute for Webkit and Mozilla; and suggests to help the accessibility of the autofocus attribute. Speaking of placeholder, although the book points out that the placeholder attribute “represents a hint”, I had hoped it would more directly state that the placeholder attribute is not a replacement for the label element, as it’s often misused.

Error recovery and form validation is also discussed. The jQuery form validation plugin is mentioned; for details check out Paul Adam’s related article.

In Chapter 9, HTML5, Usability, and User-Centered Design, great information is given, but I wonder a little of how this content fits into the scope of the book. The chapter mostly discusses user testing and the 7 principles of universal design: equitable use; flexibility in use; simple and intuitive; perceptible information; tolerance for error; low physical effort; and size and space for approach and use. In addition to details from the book, you can also check out my article from last year on this topic, Popular Mistakes in Universal Web Design.

Chapter 10 discusses numerous tools and tips for accessibility testing, or “Assessing Your Accessible HTML5 Project”. Some popular tools are mentioned including WAT-C, WAVE, and Colour Contrast Analyser. Other notable tools not mentioned are aViewer, Accessibility Evaluation Toolbar, and Worldspace FireEyes.

In summary, Pro HTML5 Accessibility is a comprehensive and important book for any web developer and web designer. The read was excellent and contains many references and appropriate code examples. I highly recommend it. And now that you’ve read my review, you’re ready to buy the book!

Placeholder Attribute Is Not A Label!

Just so we’re all clear on this, the HTML5 placeholder attribute in a text input is not a replacement for the label element. Period. The placeholder should only be used as a brief example of the text to be entered.

Besides inconsistent support for screen readers, using a placeholder as an input label can create usability problems and issues for those with cognitive impairments. For example, how does one review the information entered if the placeholder is now gone?

The placeholder should be used like a title attribute (tooltip); it provides only supplementary information. If the information is required for the user (such as a strict text format) then this should be conveyed in the main content of the page, not in an attribute.

The W3C HTML5 placeholder specification specifically states it should be a “short hint…intended to aid the user with data entry” and also states:

The placeholder attribute should not be used as a replacement for a label.

Supporting articles:

Bonus!
On @a11yMemes, check out this humorous take on placeholder.

Addendum (more references):

Also see Web Axe follow-up post: Floated Labels Still Suck.

Related Tweet Jan 2016:

AAP Provides Longdesc Feedback to W3C

There’s a debate over whether or not the longdesc attribute should be made obsolete in HTML5. I wrote a bit about it a few months ago in the article Longdesc & Other Long Image Description Solutions.

Recently the Association of American Publishers (AAP) submitted feedback on longdesc to the W3C HTML 5 Working Group. It’s very well written and thought it should be shared. I obtained permission to publish the response (thanks Suzanne and Ed). Here is the main part of it:

Use of structured text as a text alternative for an image is supported in HTML through the longdesc attribute. Though there are other options for presenting structured-text, the longdesc attribute provides following benefits:

For User Experience

  • The longdesc attribute is a dedicated mechanism for just this purpose, and it always works in the same way:
    • Students and instructors will find the same user interface throughout all materials, so they will not need to learn new interfaces product-to-product, which takes time and attention away from the learning content.
    • The longdesc attribute can be revealed programmatically through browser extensions, providing access for users who do not use screen readers. Many users benefit from text alternatives, especially users with low vision.
    • The longdesc attribute does not impact the visual design. So, authors do not have to worry about how the text might impact the visual user experience. Authors can, therefore, focus on the experience of students and instructors with visual impairment while they write text alternatives. This focus on the primary audience helps authors create text that is well-suited for its purpose.

For Production Processes and Quality Assurance:

  • The longdesc attribute is easy to code. There is no need for custom scripting.
  • The longdesc attribute works with assistive technology today. If the longdesc attribute continues to be supported, content that works well for users today can be used in future products without editing.
  • The longdesc attribute can be programmatically recognized and tracked, allowing publishers to locate existing long descriptions and to test for the presence of long descriptions.

We are using longdesc increasingly in our products. Unless a different mechanism is created that meets all these requirements, we urge the W3C to keep the longdesc attribute in HTML specifications moving forward.

We do acknowledge that user agent support for the longdesc attribute should be improved. In particular, users who have low vision or who find image descriptions helpful for any reason should be able to set their user agent to reveal the descriptions. The HTML 5 specification should clarify that user agents should provide this functionality in addition to passing information to assistive technologies. In this case, publisher documentation for products with numerous longdesc attributes might include tips about use of these user agent settings.

Evaluating Other Solutions

We discuss the aria-describedby attribute following to illustrate that solutions that at first seem to duplicate the qualities of the longdesc attribute may not actually be as useful when implemented.

The aria-describedby attribute takes the unique indentifier (“ID”) of another object on the same page as its value. In other words, it points to another object (e.g. a paragraph or a link) on the page. This attribute could become an effective way for developers to indicate that the information provided by an image is actually redundant with other information on the page.

Screen reader developers might implement this attribute so that it is silent in screen readers when used on an image by default. They might also allow those who want additional information to set their screen reader to announce aria-describedby and to provide a way to jump to the object indicated by the attribute. An instructor, for example, might choose this setting to be aware of what sighted students will be experiencing.

But, the aria-describedby attribute falls short as a mechanism to link to a separate page of structured text. The aria-describedby attribute could point to a link on the same page as the image, but:

  • Hiding the link visually would require custom CSS or scripting. The mechanism for hiding the link would therefore differ product-to-product, making browser extensions or features to show the links more complex to code and less reliable for users.
  • The link would have to be present on the page for screen reader users, creating redundancy for those users.
  • Since the aria-describedby attribute points to a link or to other content on the same page, its structure implies a two-step process to reach the text alternative. Compared with longdesc, the two step process is more tedious:
    • The user moves to the object that aria-describedby references.
    • If the object is or contains a link or a button, the user interacts with that object to move to the text alternative.

If the issues above are resolved and aria-describedby is used as a way to access descriptions that are otherwise hidden from all users (including screen reader users), another problem emerges. In that case, aria-describedby cannot be silent by default in screen readers when used on images, compromising its use to illustrate that the content of an image is already available on the page. Developers may not realize the distracting and frustratingly circular user experience that this would cause and might use aria-describedby to point to, for example, a paragraph just above the image. Users would then likely follow the aria-describedby announcement, expecting to find additional content, but they would arrive, instead, at a paragraph that they have likely just read.

We urge the W3C HTML Working Group to write out the expected implementation and user experience details of any proposed replacements for the longdesc attribute to be sure that they will be at least as effective as the longdesc attribute in practice.