Category: articles

My Comment on “Tackling Accessibility on The Web”

Here is my comment on the blog Tackling Accessibility on The Web by @Treehouse.

An OK article, but a few of the techniques are incorrect/outdated. The data table caption is for a *title*, not a description. Never use tabindex (except 0 and -1 for keyboard focus with JavaScript interaction). Title attributes on links (and in general) is no longer recommended; screen readers usually don’t read them, browsers don’t support them for keyboard users, and it’s not supported (hardly) on mobile. Most implementations just have redundant information anyway. Also note that ARIA landmark roles are a good place to start learning ARIA, but there is much, much more to learn.

Another comment also states that the title attribute on links is not a great practice and provides a couple great links. Also note that the title attribute is still a must for an iFrame to describe its content.

Leave Accessibility to the Experts Please

There’s a fine line between inducing conversation and creating havoc. In the field of web accessibility (which is very complex and fragile already), it seems that this line has been crossed at least a couple times lately.

Recently, renowned CSS expert Chris Coyier (@chriscoyier) wrote the blog Navigation in Lists: To Be or Not To Be. The blog re-evaluates, again, whether lists (UL element) should still be used for navigation menus or just remove them and use only the remaining anchor text. Much unnecessary debate was generated from this. Most of it regarding use with screen readers, an area in which the author is not an expert.

The straight answer? Continue to use lists.

Just because one screen reader user gives an opinion, doesn’t mean that’s the way to go. Lists are beneficial in many ways: they’re semantic; they provide info to users of assistive technology; they provide hooks for developers to implement design and interaction; and it’s a convention.

A day after the Coyier blog, web standards guru Jeffrey Zeldman (@zeldman) on A List Apart published the blog titled on alt text about the use of the alt attribute and its impact on screen reader users. Topics in the comments include its use in HTML5, confusion with the title attribute, and using a space or not when empty value. This sparked a lengthy debate in the comments and on Twitter.

The straight answer? Use alt text; if an image is decoration then implement with CSS; if a decorative image is still inline or has no added value, use alt="", with no space. (Hint: repetitive content has no value.) If an image is linked, it must have alt text conveying the meaning of the link (and not necessarily the image itself).

Web celebs have created confusion when the answer was already agreed upon by most web accessibility professionals. So, I won’t write about NodeJS and Spring if you other experts stick with your area of expertise. Many times, we should leave accessibility to the experts. Agreed?

PS: I am indeed a fan of Coyier’s work and I greatly respect the invaluable foundation that Zeldman helped build for web standards.

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.

Reponse to Journey to Universal Accessibility–Part 1

I got an error when trying to comment, so here’s my response to the recent article Journey to Universal Accessibility–Part 1 by @Pathbrite. In general, the article is pretty good, but several of the techniques given are outdated.

  • For #3, I say don’t use tabindex; it’s no longer considered good practice as content can be same in code order as visual order. The CSS part is a must (adding focus in addition to hover state). 
  • For #4, it’s important to clarify that page titles (and H1) should be unique for each page.
  • For #5, it’s even better to use the scope attribute on TH elements. Also, the summary attribute is good but hardly ever used correctly; it’s also being made obsolete in HTML5.
  • For #7, I like title attributes, but unfortunately titles aren’t very accessible to all; browsers don’t support the rendering with keyboard use, most screen readers have it off by default,  nor does it help on mobile devices.
  • Lastly, I suggest increasing the text size on your site for better readability/accessibility.

Response to 15+ Tips to Improve Web Accessibility

I gave feedback in the form of a comment for the article 15+ Tips to Improve Web Accessibility of a Website. But, yet again, my blog comment was not published. The article is not bad, just needed some clarifications. So since my comment wasn’t approved (after several days), here it is:

Great points, although 4 have to do with forms. Some clarifications:
  • For alternative text on images, decorative images should have empty value (alt=””) and linked images must have alt text describing target of link.
  • Relative sizing in CSS not as important as it used to be. [Most browser do page zoom by default and all browsers but IE can zoom text set in pixels.]
  • CSS vs table layout doesn’t have any direct impact to accessibility.
  • Use ABBR tag for acronyms as well as abbreviations (acronym tag is deprecated).
  • For skip links, see end of this article for JS fix for functionality on some browsers: http://terrillthompson.com/blog/161

And now that I think about it, the article overlooks pretty basic techniques such as data tables, captioning, and ARIA. For a more complete list of tips, see my 25 Ways To Make Your Website Accessible.