WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Strikethrough Content with Screen Readers

for

From: Cliff Tyllick
Date: Nov 22, 2010 4:33PM

<rant>As you might be able to tell if you follow @clifftyll on Twitter, I am baffled by the decision process that seems to be used by some of the teams (well, one of the teams) involved in setting Web standards. Specifically, decisions seem to be made on the basis of looking backwards, not forwards.

By "looking backwards," I mean basing decisions on the results produced by people who have already used these tools. In making these decision, they focus on the answers to three questions (perhaps more, but I can think of three quickly):
- Did authors and developers have reasons to use this tool -- in other words, were there use cases in the "real world"?
- Have they used the tool frequently?
- Have they used it in the way we intended?

By "looking forwards," I mean looking ahead to all the reasons people might use the Internet. This approach would ask questions like these:
- What kind of content do people need to publish?
- What use cases arise with that content?
- What features do we need to create to support that content?
- How can we teach people to use those features properly?

If we don't look ahead and prepare the way for the content people produce, either they will never use the Web for that content or, more likely, they will misuse whatever we do prepare as they try to retrofit it to their content.</rant>

Now in this case, that means we need to think of all the potential use cases for strikeout and insert:
- As in Vieky's example, in advertisements, to show price reductions.
- Authors and their editors, perhaps?
- How about people who are working out contract language with their attorneys?
- Teams of people who are drafting international standards and guidelines?
- And redline and strikeout -- the word-processing equivalent of <del> and <ins> -- are the standard convention for legislation, rule development, and other similar processes throughout the United States and, I imagine, many other countries.

There might be others, but those are a good start. So do the first question is, "Does markup language need tags to support these use cases?"

Bevi suggested that we might not, at least not in all cases, if we rewrite the content: "Was $30; now $20." That might work in an ad, but even there it would be problematic. $<del>30</del>20 could be much more compelling visually, so I have a hard time believing that every advertising executive would be okay with softening the punch by using words instead.

And I hope it's obvious to us all that rewriting is not possible in the other cases. It would be hard to do, and it would be even harder for both humans and software to interpret the results. So we need some kind of markup.

The <del> and <ins> tags exist and would meet this need. Later let's consider whether we need attributes to associate with these tags. So now let's think of how assistive technology should handle it.

One option is for screen readers to change the tone. As Randall pointed out, this would not help people who are deaf/blind. And considering the number of different tones that would be needed, this approach would place an undue cognitive burden on the listener. I count at least these 12 conditions:
- Four kinds of original text: plain, with emphasis, strong, and with strong emphasis.
- The same four kinds of deleted text.
- The same four kinds of inserted text.

So assistive technology will need to convey several different kinds of information to the listener for each deletion and insertion:
- the location where the change begins.
- the type of change.
- the wording associated with the change.
- the type of formatting change, if any.
- the location where the change ends.

So it seems that attributes of the <ins> and <del> tags would be useful.

There might be comments or questions associated with the changes, too. I don't know if HTML5 has a tag for comments other than footnotes and endnotes. I would have to read the spec to figure it out.

And just as people using Word have a variety of options for displaying an edited document -- just the original; the original plus changes; just the final; the final showing changes -- and a number of ways to interact with the document -- for example, to read only the edits and skip from one edit to the next; or to do the same with the comments -- I think it would be important to support those capabilities for all people in HTML5.

Indeed, it sounds like stuff a working group should consider carefully. If more people are going to use HTML as an authoring tool, then we are going to need for HTML5 and assistive technologies to robustly support the kind of work those people need to do.

And <ins>/<del> is just the beginning.

Ok, so maybe I misplaced the </rant> tag. But now I'm done.

Cliff


Cliff Tyllick
Usability assessment coordinator

Agency Communications Division
Texas Commission on Environmental Quality
512-239-4516
<EMAIL REMOVED>