Re: Formal Recorded Complaint

Hi James,

On Jul 31, 2007, at 4:29 PM, James Graham wrote:

> Note that the underlying philosophy I have in taking this position  
> is that accessibility is very important and that we should be  
> working hard at the language design level to ensure that  
> accessibility features are used widely, not just by the well- 
> informed minority. I think that means sometimes foregoing the  
> "obvious" explicit solution in favour of designs that work better  
> when human factors are taken into account.

"Working hard on the language design level to ensure that  
accessibility features are used widely" has historically meant (with  
HTML) making more semantic facilities. That is, we design HTML as  
accessible by default by ensuring authors have access to the most  
commonly needed semantics. By providing a sufficiently rich semantic  
vocabulary, it makes it easier to create UAs that are prepared to  
present those semantics in whatever conventions will be familiar to  
their users. For example, if the elements B and I are needed for a  
host of semantics that get presented as bold and italics  
respectively, we should look to see if any of those semantics are  
widespread enough to warrant their own element or other semantic  
facility. This would be in contrast to the current approach that just  
tries to redefine B and I (and SPAN) to be a mixture of all of those  
common semantics. Of course,, those catch-all elements will be needed  
to handle those cases where we decide to cut-off the semantic  
vocabulary at some point. However, things like TERM or PROPERNAME or  
SCAREQUOTE or whatever, could all make the vocabulary richer.  
Obviously we have to cut off semantics when they become too obscure.  
We don't need to have  
IRONYINTHEWAYSHAKESPEAREUSEDITINTHE2NDACTOFAHMLET. There are several  
commonly needed semantics that HTML lacks. There are other commonly  
needed semantics that HTML4 has, but HTML5's current draft lacks. We  
should consider rounding-out the document semantics capabilities of  
the language. Often times the same voices opposed to accessibility  
specific features are those opposed to extending and rounding out the  
language's semantics.

>> Often times (like in the case of @headers) the attempt to purge  
>> accessibility features from HTML has even extended to features of  
>> HTML that are not even particularly about accessibility but  
>> instead about explicitly expressing semantics within complex  
>> documents (just because it may have some accessibility implications)
>
> I would argue that semantics-for-the-sake-of-semantics is not  
> Solving Real Problems (c.f. the design principles). There are  
> already languages that allow for rich author expressiveness (e.g.  
> Docbook); HTML has traditionally taken the path of poorer  
> expressiveness in favour of ease of learning and understanding. I  
> believe that semantic elements should only be included in HTML when  
> they permit the development of useful features in UAs without  
> additional agreement between the UA user and the content author  
> (that is probably poorly expressed; I mean we should not introduce  
> functionality that is only useful in walled-garden situations where  
> the content author has some influence over, or special knowledge  
> of, the UA).
>
> Pretending, for a moment, that we agree that semantic markup for  
> its own sake is a bad idea, what about @headers?

I don't even know how to interpret this sentence. Semantic markup for  
the sake of semantic markup is a bad idea? This strikes me as a lot  
like saying: writing that means something just to mean something is a  
bad idea. I would take the exact opposite position. Writing that  
means nothing (non-semantic writing) is the bad idea: it wastes the  
readers time. Likewise, markup that means nothing is also a bad idea.  
That is not to say that marking up text with bold and italics means  
nothing. Rather its meaning is less precise and require greater  
heuristics to interpret than markup that includes semantic  
constructs. RTF and TeX for example have many facilities for marking  
up meaning in a non-hierarchical fashion using common typographic/ 
visual conventions. That is a very different approach than HTML where  
the document is usually markedup with precise device independent  
semantics that are then styled using different device dependent  
presentation idioms. So we definitely do not agree that semantics for  
the sake of semantics is a bad idea. Non-semantics for the sake of  
semantics is a bad idea. Semantics for the sake of non-semantics is a  
bad idea. Non-semantics for the sake of non-semantics is a bad idea.  
However, semantics for the sake of semantics is a very good idea. The  
only question for me is how large and rich the semantic vocabulary  
should be: i.e., where do we cut it off.

> Clearly this does permit the development of a useful feature - it  
> enables aural UAs to speak the headings for a cell with the  
> underlying purpose of allowing users with visual impairments to  
> build up a picture of the data relationships in a table.

I've said this before, but I'll repeat it again: @headers on its own  
is not about accessibility. The @headers attribute is about  
explicitly marking up the semantics of complex tables. It has  
accessibility benefits. However, it is not a inherently accessibility  
feature (except for backwards compatibility with the way existing  
accessibility oriented UAs behave).

> However it is less obvious that it is the _best_ way to accomplish  
> this task (where "best way" is roughly defined as "way most likely  
> to accomplish the underlying goal as frequently and as reliably as  
> possible"). There are several reasons it might not be, for example:
>
> It is very much an explicit way of marking up the data; @headers is  
> not useful for most users so authors are likely to neglect to  
> include it.
>
> Even for authors who want it, it's hard to author (it requires the  
> headers to be specified on _every_ cell; increasing the possibility  
> of authoring mistake).
>
> It may encourage authors to use over-complex tables. By making the  
> tables over complex, authors may prevent visually disabled users  
> from forming an accurate view of the relationships expressed in the  
> table even with the cell-headers association. This may also prevent  
> some other users (without visual impairment) from correctly  
> understanding the table.

This sounds to me like saying that the large number of words in the  
English languages is a bad thing because it may encourage authors to  
rely too much on nuance and subtlety in their prose. Holding back  
some of these words will improve the situation. Certainly authors  
should consider their audience when composing tables or when  
composing prose. However, that is for the authors to consider and not  
us, as drafters of an HTML recommendation, to consider. We should  
provide authors with the ability to express complex relationships.  
That way the authors have a choice and a vocabulary to draw upon to  
communicate to their targeted audience.

> The first two points above suggest that we should develop simpler- 
> to-author mechanisms for associating table cells and data that can  
> be used by aural-UAs. We already have some of these; an algorithm  
> for walking the table to find relationships and @scope. If my  
> hypothesis is correct and these will be more widely used than  
> @headers, overall web accessibility will be improved far more by  
> spending time refining these algorithms than devoting the same time  
> to @headers. However, there are some tables for which these  
> mechanisms will not work. Is including @headers for these tables  
> then a good idea? Quite possibly. It has the very strong advantage  
> that it works in some existing UAs, although its penetration onto  
> actual sites seems to be relatively small. As I recall, no one has  
> yet suggested a solution that covers the same range of tables but  
> is easier to author. However, consider the third point. Maybe the  
> type of table that /requires/ @headers is intrinsically an  
> accessibility liability. Is this true? I don't know and I have no  
> way to test. But if it is true then it would be the case that the  
> spec should either exclude @headers entirely or include text like  
> "authors SHOULD avoid creating tables which require the headers  
> attribute to associate data cells and headings; such tables are  
> better replaced by simpler tables that convey the same data".

No, I think what you're suggesting is beyond the scope of a  
recommendation such as HTML. It is not our place to tell a group of  
physicists (for example), that you think too much about too complex  
of topics. Please refrain from considering such complex relations in  
the future. Does that mean some content will be authored that is not  
accessible to non-physicists? Yes. Will tables be created that  
require some secondary or even tertiary schooling to comprehend? Yes.  
However, those things should not concern us here. We should provide  
tools for expressing semantics that are accessible to whatever  
audiences an author targets. Targeting one audience may make the  
content unaccessible to another audience. That sometimes can happen.  
However, if we include the facilities needed to communicate to these  
various audiences, then authors will be empowered to compose HTML in  
just the way they need.

Moreover, prohibiting an author from creating a table that is complex  
doesn't solve the problem. Now the idea the author wants to convey  
has to be expressed in one or more simple tables or in general prose.  
The ideas are just as complex, but now the preferred method for the  
author — using a complex table employing @headers — is taken away.  
This may have indeed been the simplest way to express the idea (as  
complex as it is). However, now it has to be expressed in a way that  
is not as clear and not as succinct. This makes the idea even less  
accessible than simply allowing complex tables.

> Perhaps not everything I've said above is watertight and I  
> certainly don't claim to have covered all the points that have been  
> made for or against @headers. However I hope I have demonstrated  
> how in principle one can be pro-accessibility and against  
> "accessibility features".

Again, @headers is not inherently an accessibility feature. It's just  
that for backwards compatibility reasons we need it for many  
accessibility-oriented UAs. IMG@longdesc, TABLE@summary, OBJECT  
fallback and TD@abbr are specifically accessibility features. They  
are also accessibility features that no one has yet offered an equal  
method for, except forcing authors to include equivalent description  
for all audiences. This again takes control away from authors.  
Sometimes for visual effect an author wants to keep the page simple  
for visual users and still provide a mechanism for other non-visual  
users to consume content (just as an example).

Take care,
Rob

Received on Wednesday, 1 August 2007 01:02:54 UTC