W3C home > Mailing lists > Public > public-html@w3.org > August 2011

RE: HTML.next and Rechartering

From: John Foliot <jfoliot@stanford.edu>
Date: Fri, 12 Aug 2011 10:57:08 -0700 (PDT)
To: "'Aryeh Gregor'" <ayg@aryeh.name>, "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>
Cc: "'Sam Ruby'" <rubys@intertwingly.net>, <public-html@w3.org>
Message-ID: <019501cc5919$40d4e3d0$c27eab70$@edu>
Aryeh Gregor wrote:
>
> The usual way this is handled would be to say something like "HTML5
> does not define any mechanism for authors to include accessibility
> information for media elements, but it is expected that HTML6 will do
> so."

Hi Aryeh,

I wonder how everyone would feel if instead of "accessibility" in that 
statement, you replace it with the word "security":

	"HTML5 does not define any mechanism for authors to include security 
requirements for 'foo' elements, but it is expected that HTML6 will do so."

I wonder how Google's security officers (or Mozilla's, Opera's or Apple's) 
would feel about that? Would they *really* want to launch a product/service 
with a known security defect in it?

The problem with the approach you are advocating is that you relegate 
accessibility to the status of "Feature Request", as opposed to a key and 
core requirement for completion. In a world were rolling code and running 
specs seems quite normal, this may appear to be an impediment to progress; 
from a compliance and standards perspective however it is a little less 
trivial - simply put you cannot endorse something that is willfully and 
obviously inaccessible any more than you can endorse something that is 
willfully and obviously insecure.  Unless of course Google and friends are 
willing to do just that...


>  This lets the spec get to REC, but also points readers to the
> information they need (we can have a link to HTML6 there as an
> informative reference).  There were a bunch of things in CSS2.1 that
> were changed to be undefined so that they could get it to REC.  I
> think this is all silly, but it does work after a fashion.

The 'severity' of inaccessible versus "I can't do rounded corners with CSS 
in all browsers" should be obvious to even the most casual of observers. I 
like design, design is important, heck good design can actually even improve 
accessibility for many users (including those with cognitive issues) - but 
comparing CSS to accessibility is not even in the same league.


> The bigger problem is when you have the exact same feature in HTML5
> and HTML6,

See? Once again, "accessibility" is not a feature, it is a core mandated 
requirement. It needs to be accepted as such by one and all, unequivocally.

The right of all people to have access to digital information, to be full 
participants in our digital society, is something that no-less than the 
United nations has endorsed as a global right 
(http://www.un.org/disabilities/convention/conventionfull.shtml | 
http://www.un.org/esa/socdev/enable/maniladecl.htm). The reason why many 
member organizations join the W3C and support its work is because there is 
an expectation that the W3C will oversee Standards that will meet these 
global responsibilities and requirements. Running specs might be useful to 
browser manufacturers, but for an organization such as FSTC [Financial 
Services Technology Consortium] (http://www.w3.org/Consortium/Member/List) 
they are more concerned that something rock-solid stable is available, so 
that they can advise their membership that they can now use this newer HTML 
standard without concern of hidden defects (security or accessibility) that 
might come back to bite them. This is how the real world works, whether or 
not that makes sense or seems reasonable to you or others.

JF
Received on Friday, 12 August 2011 17:57:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:37 GMT