Joe Dolson: Accessible Web Design

Giving a talk is an interesting experience. In this case, with a time limit of 15 minutes, the biggest challenge was figuring out what I had time to cover. With a subject like web accessibility, I firmly believe that every aspect is critical — anything I leave out is something that somebody needs to know.

But it’s 15 minutes. You can’t really be effective if you try and cover the entire scope of a subject in 15 minutes.

The first challenge is figuring out the audience. In this case, I was speaking to a group of internet marketing professionals and site owners. For the most part, no programmers, no interface developers — not even people who necessarily have any direct access to the code of their sites. What can you teach them which they’ll be able to apply and understand immediately?

I’ve already given the speech, so I’m not trying to solicit suggestions for this particular event. However, I’m curious to know what you think are the most key issues.

For your reference, I covered three general areas:

• Navigation which can be used by non-visual, non-mouse using groups.
• Content which can be read sensibly by text-aware devices
• On-page navigation which can make the page easier to navigate

I completely ignored HTML validation, web standards, accessibility guidelines, and anything about following technical specifications. For this audience, this didn’t strike me as an actionable conversation. Instead, I focused on practical investigations of site problems: whether the site can be used with a mouse; whether the site makes it’s content available to screen readers (or search engines); and whether standard methods have been employed which will enable disabled users to quickly and easily get around the page.

So I’m curious: what would you have talked about?

Perfecting a web site is a long and involved process. There’s no getting around the fact that if you want every aspect of your site to be right — - accessibility, search optimization, and just all-around pizzazz, you’ve probably got some significant work to do. However, that’s not to say that there aren’t things you can check quickly and efficiently to make sure you’re not making some of the more egregious errors!

Here are 8 speedy checkups (in no particular order) which you can easily perform on your site to inspect it for problems. No methods suggested require special knowledge of HTML or web programming. Excluding acquiring and installing software, these tasks shouldn’t take more than a few minutes for most sites.

That doesn’t include fixing any problems found, of course…

Read more: Web site Tune-up: 8 Quick Checkups

Thanks to an off-hand comment from Steve Green while discussing a forthcoming Accessites article, I’ve spent some time today thinking about what it takes to write for accessibility.

Most of the time, the primary focus of information about accessibility has to do with making non-text information available as text. Captioning and audio description for video, transcriptions for audio, simple text alternatives for static images. Next in the list tends to be availability of functionality: progressive enhancement for client-side scripting, ability to navigate the page via skip links or semantic HTML headings, and so on.

But what about the content itself?

Disregarding issues concerning the use of abbreviations, typography, headings, and other semantic structures in HTML, the simple use of punctuation can be a significant barrier. This is a problem which applies to all text content for any user of a screen reader, in particular, although following these suggestions will benefit any reader of your content.

The issue isn’t precisely correctness. A sentence can be punctuated with perfect correctness but still lose clarity when spoken by a screen reader. It’s a matter of the lack of refinement in screen reader voice interpretation.

As a human speaker or writer, aware of the meaning and context of a sentence, it’s easy to speak a sentence and convey the meaning you expect in that sentence. A slight emphasis on one word or another is highly significant. However, in HTML, as in normal writing, there’s no means to indicate this kind of special emphasis which is readily understood by current screen reader technology. As important as strong and emphasis are semantically, they are not interpreted meaningfully by screen readers.

Punctuation is left as the sole means to refine and polish the meaning of a sentence for screen readers.

How do screen readers use punctuation?

Screen readers read most punctuation by default, such as parentheses, dashes, asterisks, and so on, but not all screen readers choose to read the same pieces of punctuation. Some do not read asterisks by default, for example. Periods, commas, and colons are usually not read out loud, but screen readers generally pause after each. Users can set their preferences so that screen readers read every punctuation mark and character. Web AIM, “Designing for Screen Reader Compatibility”

So common sentence punctuation marks, such as periods and commas, are indicated by pauses. However, special punctuation, including dashes and parentheses, are read as characters. This should immediately tell you how difficult it could be to understand a sentence containing numerous subclauses or parenthetical statements!

Only a few years ago, it was common to see pages that explained quote this page best viewed in Internet Explorer quote left paren or Netscape right paren. Web AIM, “Designing for Screen Reader Compatibility”, as rendered by Fangs

Although this is a relatively simple example, containing a single quoted passage and a single parenthetical statement, it could readily be very confusing to follow a more convoluted sentence structure, regardless of the correctness of the sentence.

So what’s the solution? Simply speaking, to write simply. Keep your sentences on the short side, avoid excessive parenthetical statements, and avoid excessive subclauses. Above all, try reading the sentence without giving any particular emphasis to the terms and see how easy it is to understand the statement. It’s easy to write an ambiguous sentence if you’ve assumed it will be pronounced in a particular manner.

Ultimately, the expectations when writing with a screen reader in mind aren’t that hugely different than without. After all, it’s not as if you intend to write confusing and ambiguous statements. However, the line drawn between “confusing” and “clear” is not necessarily in the same place for a computerized reader.

The grand old question concerning techniques and choices in web accessibility which, while common, are not necessarily helpful is a popular subject which is always around in accessibility circles. It’s certainly not a new topic for me to write on, but one which (for whatever reason) I’m going to go ahead and write about again.

In this case, I’m going to take a single commonly implemented method: the text-resizing tool, and discuss the advantages and disadvantages in some depth.

This article isn’t intended to espouse the use of text-resizing tools, but it is intended to try and describe how you can best implement a text-resizing tool to provide for your users.

Read more: Developing an effective text-resizing widget

In the comments from my most recent article, “Supporting Standards that Support Accessibility,” a number of interesting thoughts were raised concerning the requirement (or lack thereof) of the alt attribute in HTML 5.

It’s a difficult issue.

I’ve seen numerous articles around the web which discuss the fact that HTML 5 does not require the alt attribute. To some degree, this is true: HTML 5 provides exclusions to the requirement. In situations where an image is significant but no alternative text can be provided, HTML 5 recommends that the alt attribute be left off as an indicator that the image is significant (not a purely decorational image).

It’s actually quite a bit more complicated than that — - the specification describes detailed guidelines for when the alt attribute should be left off, when it should be given a value, and when it should be provided without a value.

My complaint, and the complaint of many others involved in the web standards world is against the concept of providing any reason that the alt attribute may be left off. Ian Hickson states:

Empty alt text means the image is unimportant (decorative) and should be ignored. Missing alt text means that the image is important, critical even, but that there is no fallback text provided. The user agent is expected to treat the two cases differently.

At least, that’s what the HTML5 spec says at the moment.

I believe that it is important to provide a way to distinguish the two cases above; putting both of them into the empty alt=”” category would be, IMHO, bad for the accessibility of the aforementioned pages.

He’s right, of course — - it is quite important to distinguish between insignificant images such as decorational graphics and between significant but undescribed or undescribable images. The challenge, then, is to come up with a solution to the problem which allows the alt attribute to remain.

So…what are some possible alternatives?

The first thing that comes to mind is to add a signifier attribute. Something which indicates whether an image is significant or non-significant. This would require some revision to HTML generating tools, but certainly no greater a change than that expected for new elements. It would be best to assume a default value when the element is not provided which assumes the image is significant, for backwards compatibility.

A second possibility would be to introduce a key term available to the alt attribute which would indicate significance. This strikes me as a bad idea, since it would have relatively poor backwards compatibility, and would require selecting a term which would become unavailable as normal alt text. Nah, that’s not really going to work.

Third…I’m struggling to come up with another idea…

I’m very open to any thoughts on the subject. Problems with these ideas are welcome, as are suggestions of any off-the-wall idea you may have!

Quietly released on the Saturday before Christmas, (what, are they trying to hide this news?) Google announced that their latest Toolbar release supports the Windows Accessibility API.

This is (obviously) a Windows-specific release, and even further, it’s just an Internet Explorer release. However, it’s definitely a step in the right direction! I was particularly glad to see the comment:

Version 5 comes as a part of our ongoing efforts to enhance accessibility in our client-side and web applications, which is a matter I hardly need to mention is very important. Jonas Klink, Software Engineer, Accessibility

(Emphasis added.)

Now, as many have commented, the accessibility level of much of Google’s code is atrocious. I like the idea that Google is actively invested in improving the accessibility of their products; but I have yet to see any serious evidence of this effort!

Still, in the holiday spirit, I will raise a glass to Google to encourage their accessibility efforts. (And if, as a side effect, I end up a little bit drunker, I will accept that.)

The justification that a web site is accessible because it “follows standards” contains a serious fallacy. Specifically, the assumption that standards support accessibility.

One root of current standard accessibility practice is conformance to the HTML or XHTML standards set by the World Wide Web Consortium (W3C). This is a fine practice, and certainly should be maintained. Using correct syntax and following a standardized method of communicating information is always a solid best practice. However, this should absolutely not be taken to mean that following these standards is the same as applying the principles of web accessibility.

Web standards only provide accessibility to the degree that they have been designed to do so — - and the guiding principle behind standards development (excluding accessibility-specific standards, of course) has not generally been to support accessibility. Web standards have been designed purely to establish a set, correct method of using the underlying code — - whether presentational (CSS), structural (XHTML) or behavioral (ECMAscript.)

In many (most) cases, web standards do not in any way require best practices — - they merely require conformance. Take HTML, for example. Web standards would permit the usage of table elements for layout, because they do not define semantic usage for the table element. Web standards also permit a variety of presentational elements, such as font, strike, or u. It all depends on what standard you have chosen to follow.

HTML5, most recently, is considering such contrarian steps as removing the requirement that alt attributes be required for images. This ensures the existence of a valid HTML5 web site which can radically fail basic accessibility guidelines. On the other hand, it may reduce the likelihood that some so-called “accessible” web sites will be littered with alt="this is a spacer graphic".

Does this necessarily mean that the standard is wrong or right? No, not as such. Different standards support different needs — - it is important to keep distinct the purpose of the standard. Conforming HTML is just that: Conforming HTML. It means nothing more.

Nonetheless, as an accessibility advocate, I feel that it’s important to support accessibility issues within the development of new standards. Taking the alt attribute issue in HTML5, for example, the lack of any perceived benefit to not requiring the attribute suggests to me that the better path would be to continue to require it. There are numerous examples of important accessibility aspects in HTML5 which are not yet included.

There seems to be a strong element of specious judgement: elements which are not supported by current user-agents are considered not to be needed. This seems a ridiculous expectation: after all, if unsupported elements aren’t needed, than why develop a new specification at all? What we’ve got must work just fine!

Practically speaking, user-agent support and developer use should both be only marginal issues when trying to decide what elements are most needed in a specification. The fact that elements are unused on either end are not a judgement on the value of that element; merely a judgement on the awareness of the element, on the clarity of the existing specification, or on the complexity of the implementation.

Nobody (or almost nobody) uses the q inline element. Does this mean that the element isn’t valuable, and should be discarded? No. It means that Internet Explorer should add appropriate support for it. The same is true for accessibility issues. The standards should support them to their best abilities: if an element or attribute could hypothetically add to the accessibility of a site, then the fact that it is little used or poorly supported should be entirely irrelevant. Support should follow the standards; not the other way around.

At the root of things, my stance is that I am unwilling to support a standard which specifically excludes features which are needed in order appropriately provide best-practice accessibility. HTML5 is still a long way from being done; and even further from being implemented (if it ever is,) but the removal of such attributes as the header from table markup, the inclusion of defined non-semantic elements such as b1, and the “WYSIWYG exemption” on the font element strike me as decisions badly in need of reconsideration.

1. In point of fact, I can accept the inclusion of one inline non-semantic element (span) and one block level non-semantic element (div). I feel there’s ample justification to allow elements which are not specifically defined on the grounds that not all situations can possibly be covered by the specifications of the language. I see no justification, however, for the inclusion of additional explicitly non-semantic elements.