- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 26 Jun 2007 11:06:09 +0300
- To: John Foliot <foliot@wats.ca>
- Cc: "'Gregory J.Rosmaita'" <oedipus@hicom.net>, "'HTML WG'" <public-html@w3.org>, <wai-xtech@w3.org>, <w3c-wai-ig@w3.org>
On Jun 25, 2007, at 21:33, John Foliot wrote: > Henri Sivonen wrote: >> >> I wasn't referring to any particular language feature. I was saying >> that we should be informed and even be swayed by how markup gets used >> in practice even if you consider the usage "poor". It would be >> foolish to ignore actual usage. > > Based upon this thinking, automobiles 25 (or so) years ago should > never have > installed seat belts... 'cause even when they were installed, > hardly anyone > used them. This is a "rump-forward" way of thinking: just because > current > usage is poor is not a reason to continue to advocate and support > accessibility enhancements. No, based on this thinking of observing actual usage, the design of a door in a high-traffic public building has failed if it can be observed that most people don't know whether to push or pull when they walk up to the door. Educating people by adding a sign "Push" or "Pull" (around here often in three languages!) doesn't fix the basic design failure. Putting a pullable-looking handle on the pull side and putting a slab you can only push on the push side is a much better solution. >> If we apply the curb-cut analogy to HTML, the conclusion I draw is >> that we should move to markup with built-in accessibility roles as >> part of the routine authoring process instead of advocating after- >> the- >> fact chiseling with role=''. That is, we should push <progress> >> instead of a bunch of divs and spans with role='wairole:progressbar'. > > But what is the difference really? No offense intended, but I think we're going to have even more cases of people talking past each other in this WG if you really don't see the difference. The difference is that when you make a progress bar using <progress> in a world where UAs implement HTML5 and properly communicate with AT, the author gets AT support for the progress bar for free when she uses the simplest markup for getting a visual scriptable progress bar. With role='' and similar afterthought annotations, enabling AT support requires another authoring pass over the markup specifically for the purpose of enabling AT support. It should be a no-brainer that the way that makes things Just Work is more likely to result in an overall improvement of accessibility than the way that requires authors to jump through extra annotation hoops— particularly if they don't see if they jumped through them correctly. > Adding a whole slew of new elements (with the learning curve > involved there), The usage of <progess> is really not that hard for authors once it is implemented and authors are aware of it. It is much simpler to author than a bunch of divs and spans annotated with role='' and tested to see that the role='' was on the right div or span to actually work with AT in the intended way. > or adding a universal attribute > such as @role, that can be incorporated into many of the basic > elements > already being used (the notorious paved cow paths)? The "could" isn't the problem. The extra authoring work suggests that the "would" is in danger *on the Web scale*. > WYSIWYG editors then > can expose the ability to enter the appropriate role perhaps from > either a > dropdown list of standard roles, or with the added ability to "custom" > create. We currently have *today* (on my cow path of life) WYSIWYG > editors > that allow similar functionality with CSS. I still find it curious how accessibility experts have faith in authoring software gaining all manner of features while at the same time assuming explicitly or implicitly that AT will be more or less frozen to its current state. >> I'm not making market *share* arguments. I'm arguing that we should >> be informed and potentially swayed by how markup features are used in >> practice. That is, how they are doing in the "market". Pretending >> that the design accessibility features cannot fail when exposed to >> the people out there (i.e. the market) makes no sense. > > Neither does *not* including the ability to do so, simply due to > poor usage. > This is where the fundamental difference lies between the two > "camps": Many > of the HTML WG contributors are talking in terms of lowest common > denominator, where-as the accessibility advocates are pleading to > reach for > the sky. That depends on what constitutes reaching for the sky. I think settling for afterthought band-aid like role='' isn't reaching for the sky. Elements with built-in accessibility roles and DHTML fanciness moved to XBL is a more ambitious way of addressing the problem for the long term by shifting the burden to a handful of UAs than settling for a short-term solution that puts the burden on countless authors who don't have the competence to deal with the burden. > What I cannot understand is how the camp that pushes for new and > advanced > HTML code such as <canvas>, (which is currently experimental or > proprietary > at best) see no issue with pushing these advances forward (even > though their > current usage is, shall we say, poor at best); yet when the > accessibility > camp asks for the same types of considerations, they are constantly > argued > down due to either "complexity" or lack of general usage today. Roughly the same "camp" that is pushing for <canvas> is also pushing for new elements with built-in accessibility roles. It isn't like the "camp" was anti-accessibility or anything. It's just that people disagree about the technical solutions for addressing use cases. > Nobody is forcing anyone to use @role, Actually, those identifying themselves as accessibility experts are rather quick to flash the scare of the legal stick. Even you did in the message I am now replying to: "and many laws in many lands say just that." > *you* might want <canvas> for your perceived needs, I want @role > for my perceived needs. Why should my > needs have any less sway than yours? People aren't really disagreeing on the needs on the use case level. For example, the need of blind users to query a table cell for its headers has not been disputed. However, the accessibility expert clique and the WHATWG clique have different views on what kind of technical solutions best address the use cases. The general pattern is that the accessibility expert clique goes for explicit accessibility annotations that put the maximal burden on authors and the minimal burden on UAs and the WHATWG clique goes for extracting accessibility information from markup that has other purposes as well while trying to shift the burden away from authors. In a technical working group we should be able to discuss different technical solutions for the same use cases without knee-jerk implications that someone is anti-accessibility (and, therefore, immoral) for questioning a technical solution. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Tuesday, 26 June 2007 08:06:34 UTC