Re: Formal Recorded Complaint

I'm trying a new quoting approach for accessibility reasons (feedback  
is welcome). I'm using two single lines starting:

> Quoting <name> <email>
>> Unquoting <name> <email>

to indicate the start of quoted text and the end of the quoted text  
respectively. The end quote is always indicated with a quote of a  
quote (double >> in plain text). The start quote is just a single  
quote (>). This makes it harder to visually scan for new text which  
is not offset on every line, but it may make it easier for screen  
reader users to read. (It sure would be nice if we had actual  
semantic HTML support in the email world).

With that said, here are my comments:


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

> 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.
>> Unquoting John Foliot

> 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.
>> Unquoting Maciej Stachowiak <mjs@apple.com>:

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.
>> Unquoting Maciej Stachowiak <mjs@apple.com>:

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.
>> Unquoting John Foliot <foliot@wats.ca>

> 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.
>> Unquoting Maciej Stachowiak <mjs@apple.com>:

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.
>> Unquoting Maciej Stachowiak <mjs@apple.com>:

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.
>> Unquoting Maciej Stachowiak <mjs@apple.com>:

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

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.
>> Unquoting Maciej Stachowiak <mjs@apple.com>:

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.
>> Unquoting Maciej Stachowiak <mjs@apple.com>:

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.
>> Unquoting Maciej Stachowiak <mjs@apple.com>:

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.
>> Unquoting Maciej Stachowiak <mjs@apple.com>:

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.
>> Unquoting Maciej Stachowiak <mjs@apple.com>:

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