W3C home > Mailing lists > Public > public-html@w3.org > July 2009

RE: Nothing is really hidden

From: Justin James <j_james@mindspring.com>
Date: Thu, 2 Jul 2009 15:32:30 -0400
To: "'HTMLWG WG'" <public-html@w3.org>
Message-ID: <0dbe01c9fb4b$d6e23e00$84a6ba00$@com>
> -----Original Message-----
> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On
> Behalf Of Jonas Sicking
> Sent: Thursday, July 02, 2009 12:27 PM
> To: Shelley Powers
> Cc: HTMLWG WG
> Subject: Re: Nothing is really hidden
>
> If the term is called 'hidden', or 'in reality seen by very few'
> matters little to me. Ultimately what matters is that very few
> authors/QAs do look at it, and that the result of that is that the
> data is often out of date or unhelpful.

I agree. I feel that this thread has done nothing but make a mountain our of
a molehill. Many (if not most) people on this list call certain types of
data "hidden" by virtue of the fact that the typical Web user with a typical
Web browser will most likely never see it (metadata fields), or if it is not
there, they will probably never notice it (like the little lock icon
denoting SSL encryption). This entire thread hinges around a bugaboo about a
piece of linguistic shortcut. Everyone on this list know that no data is
ever truly "hidden", and we all know that there is a good amount of data
that is "visible" to users of certain tools (particularly accessibility
tools, non browser UAs, etc.) that the typical user with a typical Web
browser will never see.

Quite honestly, this thread and many like it lately, feel almost vindictive.
Like, "I'm angry with the development of HTML 5, so I'm going to tie up the
mailing list splitting hairs." When the folks who want to work on HTML 6
mine this mailing list trying to find out the underlying logic behind HTML
5, would we *really* be proud to have our names on these emails?

In other words, this is a plea to the chairs... can we *please* move on? Do
we really need to have a nasty discussion over the way some people use
certain words?

> You stated in another reply in this thread that recent court rulings
> might make people pay attention to accessibility more in the future. I
> don't think that will happen. Possibly a few governmental websites
> will be authored such that they are accessible, but on the whole I
> don't think courts are going to affect the behavior of the masses.

With the exception of companies (typically only megasized companies) with
giant legal and compliance departments, government law is not even *known*
to Web developers by and large, let only adhered to. Who has the time to
keep track of laws and be able to do their jobs? So yes, don't count on the
force of the law changing things on a widespread basis.

> I don't have data to back this up though. So unless someone else does,
> we'll simply have to wait 10 more years and see.

No one will ever have data on this, just like we don't have real data on 95%
of the things we discuss here, and when we *do* have the data, it is not a
true "study" 95% of the time (note the tongue-in-cheek usage of
unsubstantiated numbers). 

> I would strongly prefer that we build solutions that fall into what I
> referred to as category two solutions. I.e. solutions where we don't
> have to rely on authors specifically authoring for AT users. Someone
> brought up in a separate thread if it's possible for UAs to auto
> generate a summary. That sounds like a very interesting idea to me. If
> we can make something like that possible, then I believe we've helped
> AT users orders of magnitude more than if we simply stick @summary on
> <table> again.
> 
> If that is not possible, then I'm much more interested in a solution
> like ARIA which is a more comprehensive category 1 solution, rather
> than the one-off that @summary and @longdesc is. I don't know if
> there's a reason to think that ARIA will work better than @summary
> has, but at least I'd imagine it will help make a small set of sites
> AT friendly (where authors do in fact author for AT users). Which is
> better than nothing.

I could not agree more.

Folks, if you are interesting in usability and accessibility (and I believe
everyone on this list is), then you need to accept a few truths:

1. There is no possible way to force every (or even "many") HTML authors to
not only provide data for any given attribute or element, but even if you
could, there is no way to force them to provide useful values.

2. The HTML 5 specification, for the most part, will reflect a standardized
version of the state of the art amongst Web browsers. Ian has made it
perfectly clear that existing implementations carry an extremely high
premium compared to non-implemented ideas (this is what he refers to as "dry
science fiction"). If you do not like it, you have a few recourses:
   2a: Wait until HTML 6
   2b: Start editing sections of work yourself and check it into the system;
Ian has been begging for help anyways for literally years
   2c: Write an implementation of it (I suggest you fork one of the existing
open source browsers) and present it to the group
   2d: Work with a browser vendor to have them implement it and present it
to the group
   2e: Work to have Ian replaced as the editor
There really are no other options. You can work within the framework of this
group according to the process that Ian says he uses (regardless of what
various charters, W3C documents, etc. say), you can wait until the next
version, or you can find a way to get an editor with a different process.
End of story. But to continue to waste my time and the time of everyone else
on this list complaining about the process is worse than a waste of time. It
actively drives people away from participating on this list. Again, think
about what these archives will look like in 10 years: a bunch of people
complaining about the process instead of trying to improve the product.
Every place I worked that ran like that never made good products, nor did
they ever have good processes.

3. Anything done for the sake of accessibility needs to meet certain
criteria:
   3a: Actually be a good way to solve the problem it addresses
   3b: Be implemented in a way that encourages HTML authors to use it
appropriately
   3c: Not be implemented in a way that allows HTML authors to "hijack" it
for other purposes or use it incorrectly or inappropriately

My understanding of the @longdesc situation, for example, is that Ian does
not feel that it meets 3a or 3b, and that @summary is not working on 3c (he
says "polluted"). On the flip side, ARIA meets 3a, 3b, AND 3c. It's a winner
from where I sit.

I know that the chairs have asked that these kinds of "metadiscussions" be
ceased. But to be honest, there are people on this list who are being
acrimonious in a manner that cannot change a thing given the parameter of
the situation.
 
Am I happy with the HTML 5 spec? Not in many aspects. I would have much
rather seen it be more of a "document" spec and leave out things like Web
Workers and other RIA type items. At the same time, I recognize that it has
done a great job at cleaning up the vagueness in the HTML 4 spec that led to
so many problems, where different browsers could be HTML compliant and do
radically different things at the same time.

I am not asking for disagreement to cease, nor am I saying that all is well
in HTML 5 land. But I *am* saying that the pollution of this list by
pointless arguments (hint: when you start arguing over things like "strawman
arguments" and start discussing the terms of the debate, you are engaging in
a pointless argument) is a massive waste of the time of the people who are
engaged in it (since you have neither power nor authority to change
anything) and the time of the rest of us on this list.

J.Ja
Received on Thursday, 2 July 2009 19:33:27 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:47 UTC