Re: Formal Recorded Complaint

On Jul 31, 2007, at 1:30 AM, Robert Burns wrote:

> I'm trying a new quoting approach for accessibility reasons  
> (feedback is welcome). I'm using two single lines starting:
>
> [...]
>
> With that said, here are my comments:

Several members wrote me privately to say they could not follow this  
quoting format. I've reformatted into a traditional format and I'm  
resending it so that it will be more readable. (so much for  
challenging received wisdom :-) )


>> Quoting Maciej Stachowiak <mjs@apple.com>:
>>> It's important to keep in mind that when people disagree, there are
>>> often different perceptions on different sides of the argument,
>>> especially in media like email and IRC that don't convey emotional
>>> cues very well. What you see as process abuse, others may see as
>>> vigorous discussion that ultimately leads to a better spec.  
>>> Similarly,
>>> sometimes individuals may perceive a conversation as a series of
>>> unwarranted personal attacks on them, where others may see that
>>> individuals remarks as trolling or needlessly disruptive.
>>>
> Quoting John Foliot <foliot@wats.ca>
>> Maciej, I agree that often the emotional and visual cues of the  
>> written word
>> are lacking, however, please do refer to Tina's earlier response
>> [http://tinyurl.com/293sry]:  there can be no mistaking the intent  
>> of the
>> comments made about her - there is no ambiguity in those written  
>> words.
>>
Quoting Maciej Stachowiak <mjs@apple.com>:
> I agree that people said some not-very-nice things about Tina, but  
> this was during an earlier phase of the working group when it  
> seemed to me there was more hostility and argumentation in general.  
> So I would not necessarily assume things are the same today. I will  
> also note that Tina's emails to the group were seen by some as  
> disruptive at the time.

I think that's a major part of the problem Dissent or merely  
disagreement is often seen as disruptive by some members of the WG.  
While, on the other hand, genuine disruption is seen as "manly" or  
"showing technical prowess" or whatever phrase is used to justify the  
disruption. It may simply be borne of a defensiveness that  
"outsiders" may not appreciate the work of the WhatWG (I've tried to  
calm that fear in the past). However, his disruptive attitude has  
been leveled against others whether they are affiliated with the W3C  
or simply invited guests here to the WG. Disagreement is not  
disruptive. However, rudely dismissing disagreement or opposing  
viewpoints is disruptive. It squelches dissent.

Quoting Maciej Stachowiak <mjs@apple.com>:
> While we still have some heated discussions in the group, I think  
> we are generally in a more peaceful era, and I see a lot of  
> productive work taking place. But still, it's best for all of us to  
> try to be kind and courteous as much as we can, and also to  
> understand that there will be lapses.

I think the peace you're talking about has been won through chasing  
away many dissenters. We have achieved relative peace by chasing away  
those who would disagree with the general thrust of the current draft.

> Quoting John Foliot <foliot@wats.ca>
>> Some might think they are the extreme, or taken out of context,  
>> but if you
>> care to follow the full thread of this conversation, there are  
>> others who
>> have felt the same "chilling effect" [Sam Ruby @ IBM
>> -http://tinyurl.com/28ae6u]: the superior tone and argumentative  
>> attitude
>> that brow-beats dissenters on list, and as witnessed by Tina's  
>> archived
>> comments, ridicules them off list.
>>
Quoting Maciej Stachowiak <mjs@apple.com>:
> Now I'm going to contradict myself a little. It's generally good to  
> be nice, but it's also good to be able to forcefully disagree if  
> you don't accept someone else's argument. Too much  
> argumentativeness can have a chilling effect, yes. But chasing away  
> or banning people who seem too argumentative can create another  
> kind of chilling effect. People become afraid to point out problems  
> in other people's proposals for fear of being seen as one of the  
> mean people. Ultimately, being too afraid to criticize will result  
> in a lower quality spec. The difficult thing here is to provide the  
> appropriate balance.
The issue being raised here is not necessarily about "being nice" or  
"forcefully disagreeing". Rather, it's about how one should  
forcefully disagree or conduct oneself in a WG that should be about  
building consensus: and not building consensus by chasing away  
dissent. We can all forcefully disagree with one another without  
dismissing others viewpoints. To use the idea of a use-case in good  
faith, we need to understand how opposing viewpoints might be trying  
to solve a particular use-case: one perhaps already addressed in the  
draft. We also need to understand that we are dealing with a very  
rough draft: one that is not always clear about addressing use-cases.  
So if someone proposes an enhancement for HTML or a change to the  
draft, that person may not understand the draft or the current state  
of HTML5. It's equally likely that even for someone that does fully  
understand the HTML5 draft, they may not have considered all possible  
use-cases or problem statements surrounding the state of HTML and  
therefore may easily misunderstand a new proposal.

Quoting Maciej Stachowiak <mjs@apple.com>:
> As long as we stick to criticizing the idea, not the person, I  
> think we're more or less ok.

No, I don't think that is OK. It's not enough to simply avoid ad  
hominem attacks (though those should be avoided certainly). It's also  
important to understand opposing viewpoints. No one joins this WG  
because they want to bring down the web (at least I hope they know  
there's other more effective ways to do that). They devote their time  
to this WG in order to improve the situation on the web for author's  
and user's alike. So by all means criticize ideas, but criticize  
ideas in constructive ways. Criticize other's ideas without the  
attitude that has often gone along with those criticisms.

If someone presents an idea you think is crazy or misguided or even  
stupid expect that you are probably misunderstanding something about  
that idea, because I doubt there are very many crazy misguided or  
stupid people participating in this WG.

Quoting Maciej Stachowiak <mjs@apple.com>:
> I think this may be the heart of the misunderstanding, and I think  
> the feelings of disagreement may be partly more about style than  
> substance. When I read the transcript, I saw in it some sentiments  
> that I can relate to myself.
>
> First, I think most of us here, even those who do not see  
> themselves primarily as "accessibility advocates", would agree that  
> it's important to support accessibility. No one has disputed that  
> part of the design principles.
>
> However, I do think there are some disagreements on how to best  
> achieve good accessibility for the web. Here's the major divide I  
> see, and these are somewhat extreme statements of the two positions:
>
> [Position A]: Accessibility is important. Therefore we should have  
> a lot of HTML features that are there specifically to aid  
> accessibility for some classes of users. Authors should be required  
> to add as much accessibility stuff as possible to their markup.

This, so-called, extreme statement of the position is just the sort  
of straw man that has been used to silence dissent on this list. For  
example when the issue of equivalent alternate fallback was raised,  
you brought up your own personal flickr account and suggested it  
would not be right (fair or just or whatever) to require you to  
include a @longdesc on photos for your friends and family. However,  
that was not the topic anyone was discussing. We didn't even know  
about your flickr account. We were discussing: including features in  
HTML5 that had already been included in HTML4: features that  
<em>allow</em> authors to add fallback content to images (not require  
authors). In this way various accessibility advocates have been  
repeatedly badgered (into silence?) with straw man arguments like this.

Quoting Maciej Stachowiak <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.

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.

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) This, to me,  
attacks the heart of what HTML is about. In the archives there are  
several places where Maciej suggested others might be better off  
working on XHTML2 than HTML5. However, for those who don't want to  
provide authors with an ability to explicitly express semantics in  
their HTML documents, I'm often left wondering why they're not just   
working on bringing better RTF support to existing browsers and  
forgetting about HTML entirely.

Quoting Maciej Stachowiak <mjs@apple.com>:
> Notice that there is no debate here about whether accessibility is  
> important. The disagreement is solely over the best way to address it.

Well from your statement of the extremes (position A and position B),  
it does indeed look like there's a disagreement over the importance  
of accessibility. Your statement of position B was basically that  
HTML should not include facilities if they would only be useful for a  
disadvantaged web user. Laclan has made similar arguments: insisting  
that documents should only include elaborations of non-text media if  
those elaborations would be useful to non-disadvantaged users (in  
other words those who can already consume the non-text media).

Quoting Maciej Stachowiak <mjs@apple.com>:
> When advocates of Position B argue for accessibility solutions that  
> work automatically with standard markup, and against explicit  
> accessibility-specific markup, sometimes advocates of Position A  
> see this as being against accessibility. At this point, they may  
> criticize advocates of Position B as being against human rights.  
> They sometimes argue that instead of making normal markup work  
> well, we should force authors to add more accessibility-specific  
> markup; it is sometimes claimed that various laws may require this.

Well I think the most important criticism of position B for our  
purposes is that they do seem to oppose accessibility related markup  
and often times even simply oppose explicit semantic markup just  
because it may have an accessibility side-effect as a benefit (like  
@headers).

Quoting Maciej Stachowiak <mjs@apple.com>:
> I hope you can see how this may be frustrating. I think advocates  
> of Position B are mostly sincere in their belief that their  
> approach is the better way to improve accessibility. Many of them  
> have been in the trenches of slogging through bad markup, and have  
> little faith in the likely benefit of complex authoring  
> requirements, compared to heuristics that can work on general- 
> purpose content. But simply because of their disagreement about  
> technical they are labelled as being against accessibility.

This is not merely a technical disagreement. Both positions agree  
that UAs should follow accessibility guidelines. Both positions agree  
that text should be spoken in aural browsers (as an example). The  
disagreement — as you yourself have posed it — is over whether HTML  
should do any more for authors and users. In other words is there any  
semantic features that HTML can include that will improve the  
experience of disadvantaged users when compared to other non-HTML  
approaches. I've said this before, but it bears repeating. HTML's  
focus on semantics is what makes it a a leader in providing  
accessible content. The goals of semantic markup and accessibility go  
hand-in-hand: because semantic markup presumes nothing about its  
presentation (whether aurally, tactilely or visually). Adding a few  
other features like TABLE@summary, TD@abbr, and non-text media  
fallback, is just a minor extension of the semantic capabilities  
already inherent in HTML.

Quoting Maciej Stachowiak <mjs@apple.com>:
> It is my sense that this is the frustration that was being  
> expressed in the IRC log you cited.

Those logs do not exhibit what I would call frustration. Those logs  
exhibit contempt.

Quoting Maciej Stachowiak <mjs@apple.com>:
> On the other hand, sometimes it seems that advocates of Position B  
> ask advocates of Position A to jump through a lot of hoops to  
> justify accessibility features that are already in HTML4. And it  
> may seem that these kinds of hoops are not always required for  
> features that aren't related to accessibility.
>
> I think in some ways this is a fair criticism. But I think the best  
> way forward is to carefully examine and justify all HTML features,  
> to make sure we have a solid basis for our working group decisions,  
> and a record of the reasoning. Also, for accessibility features  
> where a key part of the justification is the way such features are  
> handled in existing assistive technologies, it's likely that it was  
> difficult to do the necessary testing because, for example, screen  
> readers are much less readily available than general web browsers.

Again, this sounds like you're saying that lets justify the features  
not included in the present draft and leave those features in the  
present draft (and not justified) alone. This sounds like the same  
double standard we here again and again, just expressed in an  
escalating Orwellian language.

Certainly we have the resources and the volunteer support (if we do  
not chase them all away) to text a handful of HTML4 accessibility  
features.

Though I am trying very hard, it is difficult for me to even begin to  
understand the position that would advocate the removal of these few  
small features of HTML that benefit both authors and users. Many of  
these features already have (at least limited) implementation  
support. Even the requirements that authors must provide equivalent  
fallback for non-text media is so easily circumvented (unless laws  
and other mores intervene) that it's hared to imagine what possible  
costs could be involved in including these features. If there really  
is a concern that including accessibility features in HTML will only  
make authoring more difficult because of legal ramifications, then  
that's a conversation we should have openly here on this forum. It  
shouldn't be dealt with by fostering and proliferating an attitude of  
contempt for accessibility throughout the web community.

Take care,
Rob