hAccessibility, one year on

Andy Mabbett reminded me that it’s been a year since James Craig and I published hAccessibility— a look at the accessibility problems inherent in some unsemantic design patterns used in some microformats.

The main problem is that the title attribute of the abbr element is misued to “hide” machine data, such as in this example.

<abbr class="dtstart" title="20070312T1700-06">
March 12, 2007 at 5 PM, Central Standard Time
</abbr>

For screenreader users who have elected to have their assistive technology expand abbreviations, the human date is replaced by the unintelligible string “Twenty million seventy-thousand three-hundred twelve tee seventeen-hundred dash zero six”, which makes it inaccessible.

We were accused of spreading fear and doubt, told we were wrong and we must prove our case to an openly hostile microformats crowd. The burden of proof was so great that we decided to have a life instead.

Mike “Isolani” Davis resurrected the issue this weekend. He takes issue with the microformatters’ assertion that the scenario I describe above is not a problem because most screen reader users do not change their default settings.

I agree with Mike about this (although I don’t think Jeremy is the bad guy).

Mike writes “there are no published studies or investigations available that document how most screen reader users have their screen readers configured”. The only study I know of that comes close is a 2003 paper called Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers by Theofanos and Redish, who write

Many users do not know or use all the features of the software. Given the mental load of browser, Web site, and assistive device, it should not be surprising that many of our participants did not know all the features of the screen reader software

Most of our JAWS participants regularly used the Links List (Insert-F7). A few regularly checked the Window Title to see what page they were on (Insert-T). Only a few used the Headings List (Insert-F6) or moved from heading to heading by pressing H inside a document. No one used the JAWS command, N, to skip links. No one jumped directly to a form on a page. Only one of our participants, a JAWS trainer, used the Virtual Viewer (Insert-F1), a JAWS feature that displays a description of a Web page, so that the user can immediately find out how many headers, tables, links, and other screen elements are on a page.

While this might be taken as supporting the idea that no-one really configures a screenreader (extrapolating from the conclusion that few even know the out-of-the-box features, let alone buried configurationm options), note that the paper also suggests “to make screen readers read an acronym or abbreviation as letters rather than attempting to read it as a word, use the <ACRONYM> and <ABBR> tags”, although doesn’t mention the expansion of abbreviations.

To be perfectly frank, I’m sick of the whole subject now. Even if it is unlikely that someone expands abbreviations (and I don’t believe it is unlikely), it is still very possible that someone using an assistive technology in the wild might want to expand an abbreviation, and hence find a microformat inaccessible.

Some in the microformats community want to find a way round this and work to make hCalendar and associated specs useful to all. I applaud those people. James, Patrick and I are working with those people.

Yet there are others who I know genuinely care about webstandards and semantics, and who would never dream of laying out a page with tables, and yet who are are nevertheless entirely happy to risk inaccessible content rather than amend their specifications to completely remove that risk.

Why? It’s genuinely baffling to me.

24 Responses to “ hAccessibility, one year on ”

Comment by Mo

My guess is, and it’s something I’ve experienced plenty in the course of my job, is that some semantics are considered more important than others. Things like CSS are easy to pin down: they make maintenance easier, they make pages search-engine friendly, and so on. When you start delving into the actual difficult stuff, you’re into uncharted territory, and very few people actually care about it enough for reasoned, logical, arguments to have much sway.

Probably the most obvious example, which is in part related to this, is the old alt versus title attribute debacle: I see people continually stick stuff in alt attributes which in no way, shape, or form is a reasonable alternative to the image for when it isn’t loaded or presented. Indeed (and I know experiences vary), I tend to find that the vast majority of the time, the alt attribute is best left (present but) empty. The title attribute, on the other hand, is *different*.

But, I’m told, IE 6 renders alt values as though they were titles, and the undercurrent is often “and it’s no big deal if we take advantage of that to the detriment of those using assistive technologies, because they’re unimportant”. Ultimately, lots of web developers like talk about semantics, but really just pay lip-service to accessibility. (In the interests of balance, I should probably note that I’ve been guilty of selectively ignoring an accessibility constraint when the pressure’s on, though it’d be a lot harder to do that if I didn’t feel that I had to fight to have them taken seriously in the first place).

Comment by Isofarro

“Some in the microformats community want to find a way round this and work to make hCalendar and associated specs useful to all. I applaud those people.”

Undoubtedly there has been time and effort invested in fixing this, but in a year there has been no visible progress. Are these people being stone-walled by other members of the microformats community, either deliberately, or through sustained apathy?

Its not like hCalendar is a little-used microformat. How many Barcamps and back-networks has it already been used on?

Comment by Chris Heilmann

He’s dead Jim…

No seriously, the only thing you are missing there, Jim, is that the whole idea of microformats is that you mark up all things visual for re-use by machines. If you start adding content that you hide then you are actually not building on what is already in the document but you add new content which is what RDF would be about.

This is a big issue with the date pattern.

Comment by Isofarro

Jim, this example means that for a microformat to be accessible, it is dependent on CSS to be available and not impede accessibility. CSS cannot, or rather, should not, be relied on.

Since this is really about inserting machine-readable information into a document that isn’t human friendly, why not use a hidden input field?

Comment by bruce

Mike asked

Are these people being stone-walled by other members of the microformats community, either deliberately, or through sustained apathy?

I don’t know, I’m afraid—I don’t follow what happens on the microformats lists anymore.

Is anyone here active on those lists and would care to comment?

Comment by steve faulkner

Note that this issue does not only affect “screen reader”. Users of screen magnifier/readers such as Zoomtext, get this stuff, either visually or aurally or both when they mouse over it. In zoomtext there is an option to “read tooltips” which is a general option setting.

Comment by Jim O'Donnell

Mike: “Since this is really about inserting machine-readable information into a document that isn’t human friendly, why not use a hidden input field?”

I think an input has to be the child of a <form> and forms require an action, using either GET or POST, so it all gets very messy and complicated if you use an input field.

Chris: “This is a big issue with the date pattern.”

Not just the date pattern – locations too. Suppose I had also wanted to mark up the postcode of the church in my example with a lat/long point.

TEI solves the date problem by storing the properties of a date (calendar, ISO value and precision) in attributes:
http://www.tei-c.org/Guidelines/P4/html/ref-DATE.html
Perhaps it would make sense to add a new HTML attribute to store semantic data, which can then be read and used by microformats parsers or other tools without being exposed to the reader?

The argument against the latter approach is that new attributes aren’t supported in HTML today, but Steve’s talk on Friday showed that WAI-ARIA already uses new attributes with existing HTML. Why not take the ARIA approach and use custom attributes?

Comment by Mo

@Jim:

The problem is, (current) Microformats were essentially developed as a way to mark up certain kinds of metadata without going to the trouble of employing mark-up designed explicitly to support extensibility (I.e., XML, and specifically, XHTML).

Adding custom attributes (and in some cases, elements) for particular applications basically brings us to the point where HTML ends up being like a poor cousin of XHTML, except with dirty hacks instead of namespaces.

As more and more proposals of this ilk crop up, I’m increasingly wondering what on earth the point is—are the proponents of microformats, et al, (who, let’s face it, are smart people) really that afraid of XML+namespaces? This is exactly what it was designed *for*. In other words, this is a completely solved problem.

Comment by Isofarro

Hi Jim,

Jim says: “I think an input has to be the child of a “

That’s what I thought until it was pointed out to me earlier this week that this is not true :-)

Looking at the HTML 4.01 DTD, all input elements are of named entity grouping “formctrl”, and that is part of “inline” elements, so anywhere an inline element can go, so can an input field.

HTML 4.01 Strict DTD:
http://www.w3.org/TR/REC-html40/sgml/dtd.html

Jim: “Why not take the ARIA approach and use custom attributes?”

Regarding Custom Attributes: ARIA can add in new attributes because they work within an organisation that effectively controls what is and isn’t part of the HTML recommendation. Its much safer for ARIA to introduce new attributes because of the lessened risk of clobbering other people’s custom attributes.

For Microformats to adopt custom attributes, they really need to be working within the W3C. Its risky for independent groups to make up their own attributes, because of the chance of clobbering.

One example, Yahoo! Mail used the custom attribute ‘action’ on form input elements – since action is only valid on the form element itself. This is now being clobbered in Opera because they have implemented bits of HTML5 where they’ve introduced action as an attribute on form input elements.

Mike

Comment by Jim O'Donnell

That’s interesting to know about form input fields. Here’s a quote from the HTML 4 spec itself.

The elements used to create controls generally appear inside a FORM element, but may also appear outside of a FORM element declaration when they are used to build user interfaces.

http://www.w3.org/TR/html401/interact/forms.html#hidden-control

Markup geeks can find more about HTML content models at blooberry.com:
http://www.blooberry.com/indexdot/html/tagpages/shorthands.htm

Re. what Christian said about microformats building on existing content, rather than adding new content. As soon as you add a title to an abbreviation, you are adding new content to the page that wasn’t there previously, so microformats are going to have to deal with that.

In fact, since title and <abbr> are accessibility enhancements in HTML 4, what an author should be doing is spying a bit of incomprehensible jargon, going “oh, this may confuse my readers, I’ll clarify it to improve accessibility” then adding an accessible clarification via <abbr> (or <acronym>) with a title. It’s really hard for me to square up the microformats use of <abbr> with the intentions behind adding that tag to HTML in the first place.

Comment by Frances Berriman

@bruce re: lists

There’s been somewhat of a stand-still because no one, in my opinon, is willing to make a call on this without a significant chunk of research data. You’re all right – you can’t rely on anecdotal evidence etc. and being the pseudo-intellectuals us microformateers pretend to be – we need data! I mean – look at what little we have:

http://microformats.org/wiki/assistive-technology-abbr-results

Or should I say – is that too little?? Is there enough there to make a sensible, well-educated, conclusion and change the patterns based on these? I don’t think I’m qualified to say so – but I’d love it if some lovely accessibility qualified folk would like to drop me and email and we’ll work out how to decide that.

We’re trying to get a batch of testing done at the Beeb, but things move slowly in this monster. Ugh!

Comment by Eric Meyer

Frances says what I’ve been thinking about posting: that the problem for many (like me) is not apathy, but uncertainty. Is the current pattern accessible, or not? There have been claims made both ways by experts in accessibility, and evidence both ways derived from actual testing.

And those who feel the strongest on each side seem to believe those on the other are being willfully destructive, obstructive, or just plain evil. None of which helps anyone.

It rather reminds me of the HTML5 arguments, actually. (Both those about accessibility in HTML5 and the wider topic of whether HTML5 is a good idea, or not.)

Comment by Mo

@Eric:

Surely if there’s evidence in both directions, that implies that there is an accessibility problem, just not one which occurs for everyone (as with most)? To my mind, something working in many situations doesn’t cancel out the fact it’s broken in others, and if it’s a case of “six of one, half a dozen of the other” as it seems to be here, then it’s a simple choice: have accessibility problems, or find some other solution.

Comment by Isofarro

Eric says: “Is the current pattern accessible, or not?”

Given the pattern [abbr title="1998-03-12T08:30:00-05:00"]12 March, starting at 8:30[/abbr] reads out as “nineteen ninety-eight dash zero three dash twelve T eight thirty zero zero dash five o’clock” [1],

1.) Do you find the quoted string easy to understand?

2.) What is the most likely interpretation of “five o’clock” to someone who hasn’t heard of microformats?

[1] http://lab.dotjay.co.uk/tests/screen-readers/microformats/datetime-design-pattern/

Comment by Eric Meyer

Actually, I do find it fairly easy to understand (and would quickly find it trivially easy if I encountered it on a semi-regular basis), but I’m the first to admit I’m way, WAY outside the norm. Basing decisions on what I find to be easy or hard is a bad way to go.

Further, I’m not a screen reader user, so what I think is easy or hard is completely irrelevant. What matters is what’s found in real-world testing with lots of people who use readers on a regular basis. I’ve heard of minimal testing, with mixed results overall. Not exactly a clear-cut situation.

And all this assumes most users hear this stuff at all. Do they? I don’t know. Some say yes, some say no. It would seem it’s a matter of proportion. If it happens 1% of the time, that’s one thing; if it happens 15% or 50%, that’s another.

Which loops into the question regarding whether things should change because there might be brokenness in some cases, that might be equivalent to arguing images should never be used in web design because some people might disable image loading. Or it might be more like saying sites should not be dependent on JavaScript to function, given that some users and user agents may not accept/support JS. Which is it more like? I have no idea, and there hasn’t been much to help people like me decide. What little there is argues both ways.

So it’s hard to evaluate the need for changes, let alone what changes might be best. I’m sorry, but to someone on the outside, there’s very little clarity and a whole lot of confusion.

So I say again that there’s not so much apathy as uncertainty, at least for some people, from what I’ve seen. There may have been apathy or even hostility in others, though that latter seems to occur across the spectrum of opinions on this, and so many other, topics.

Of course, nothing I say should be in any way taken to represent anyone but myself, just in case that wasn’t clear.

Comment by Ben 'Cerbera' Millard

Don’t forget sighted mouse users who don’t use screen magnifiers. They end up with data in tooltips. It’s easy to test with them because they are more numerous than other user groups. Plus, the software they use is either bundled with common operating systems or available as a free download. This is the default behaviour, so they are all affected.

As for custom attributes, HTML5’s proposal for embedding custom non-visible data. It reserves all attributes which begin data- for use by authors. They get unreadable data out of the user experience. They have no risk of clashing with standardised attributes later down the line. They will be conforming.

However, they are currently disallowed from having any special meaning to UAs. Maybe that will change. If it does, Microformats could benefit from them.

There’s a history of discussion at Accessify Forum may be of interest. But that site has been down for the past couple of days, so I can’t link you to the topic.

Comment by bruce

Good discussion, all — please keep it coming.

Eric, I take your point that there’s confusion. I hope that we can do some testing when I begin my new job in the summer.

There’s a danger, I feel, it looking too hard at numbers. I know some of the microformats list members have been terribly excited by a high-profile screen reader user telling them that he doesn’t set abbreviations to expand (“The datetime screen reader problem is almost complete bollocks“). But Robin is an individual and not a representative of all screenreader users. Not all disabled people are the same.

If I asserted that my friend Pippa never changes the default font size in her browser, therefore no-one else does, so therefore there is no need for anyone to allow for resizeable fonts in their design, and thus the ability to resize font could be commandeered into something else, you’d call me Knucklehead McSpazatron and take no notice of me.

The fact that screenreaders allow for the expansion of abbreviations (and the abbr element itself is an accessibility addition to html) means, I believe, that we must assume that people really do it, in the wild.

There are plenty of other workarounds that avoid the date-time pattern. The original conception didn’t use abbr, it used the object element and its data attribute. If that element had been better supported in Safari, we wouldn’t be using abbr now — which suggests to me that abbr is hardly the natural home for this data.

Comment by Ben 'Cerbera' Millard

Accessify Forums is back up, so you can read the most recent Microformats thread. It includes links to past threads about Microformat accessibility.

Good analogy to text sizing, Bruce.

Framing this debate as being about custom settings in screen readers is missing the point, imho. Data in title affects everyone using a device which implements HTML4 title according to the specification.

Try hovering your mouse over any <abbr>, <span> or <a href> with data in its title value. Then explain how that’s a user-friendly design choice while keeping a straight face. I can’t manage that! :)

It’s worth mentioning HTML5 <time datetime> for the time and date cases. But letting the data- attributes have meaning to UAs seems more widely useful than enshrining one particular use-case, to me.

Comment by Andy Mabbett

@Cerbera: You may not be able to “keep a straight face”, but you have also failed to respond to the challenge to come up with a better, more accessible, usable and valid method than the “data:” prefix proposal. HTML5 is, at best, a decade-and-a-half away from widespread deployment in the real world. It may be a useful fix then, but for now it’s just a red herring.

@Eric Meyer: Do you think <abbr class="dtend" title="2009-01-01">, as currently used in microformats, is accessible and understandable? Or do you think people will perhaps understand it to mean 1 January 2009, and not, as it is used, 31 December 2008?

@Bruce/ Mike: Yes, people are are being stone-walled. Stone-walling is an oft-used – and documented – tactic of the unelected cabal running the microformats “community”.