Re: Formal Recorded Complaint

Robert Burns wrote:
> I'm trying a new quoting approach for accessibility reasons (feedback is 
> welcome).

I found that incredibly hard to read. I hope (perhaps with undue 
optimism) that AT can deal with the standard mail quoting format.

(oh I see you've changed the format as I was composing this).

>> Quoting Maciej Stachowiak <mjs@apple.com <mailto:mjs@apple.com>>:
> [Position B]: Many authors won't think that much about accessibility. So 
> the best accessibility enhancements are those that work on top of 
> features that also have some benefit in mainstream browsers with no 
> added AT. In the course of making the right markup for general use, 
> accessibility comes along for the ride, and that's basically all we need.
>>> Unquoting Maciej Stachowiak <mjs@apple.com <mailto:mjs@apple.com>>:
> 
> Perhaps this is an equally extreme straw man statement of position B, 
> however it does seem more in line with what I've been reading on this 
> list. That is, we find many suggesting that accessibility should mostly 
> be just a celebration of happy coincidences where certain aspects of 
> HTML and Unicode text and the human senses just happen to be able to 
> provide a way for disadvantaged users to consume — from time to time 
>  — minor tidbits of content that non-disadvantaged users easily consume 
> completely. Perhaps it is because it is stated in an extreme way, but 
> this looks to me exactly like a statement that HTML should not have any 
> accessibility facilities.

I believe that is a mischaracterisation both of the position that Maciej 
described and the position that real people have taken. The position I 
would advocate, for example, is that the language should be designed 
carefully so that, as far as possible, accessibility arises naturally 
from things that authors do anyway. This careful design is quite 
different from the "happy coincidence" of things "just happening" to 
cause accessibility that you talk about. Indeed, making accessibility 
functionality transparent is likely to be difficult compared to making 
it explicit.

Unfortunately it won't be possible to design the language so that 
accessibility comes naturally in all cases; sometimes explicit 
accessibility features will be needed. In designing these, we should 
work hard to minimize the authoring complexity of the feature thus 
minimizing the chance of the feature being neglected or misused. To this 
end, the authoring impact of explicit accessibility features needs to be 
very thoroughly investigated (sadly, lack of access to AT makes this 
hard to do, hopefully Joshue's testing facility will help here).

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.

> 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? 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. 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.

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".

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".

-- 
"Mixed up signals
Bullet train
People snuffed out in the brutal rain"
--Conner Oberst

Received on Tuesday, 31 July 2007 21:29:19 UTC