Re: CfC: Publish HTML5, RDFa heartbeats and Microdata, 2D Context and H:TML as FPWDs

On Feb 17, 2010, at 2:57 AM, Martin Kliehm wrote:

> On 16.02.2010 22:26, Sam Ruby wrote:
>>> a) Doug Schepers and Eliot Graff published a split-off in October  
>>> [1]
>>> that hasn't been reflected in Ian Hickson's work. Obviously the  
>>> group
>>> disagrees here, and I haven't seen any efforts to find a consensus.
>>> While a consensus is not officially required for publication as a
>>> FPWD, I certainly do now want Google and Microsoft drift off in
>>> different directions. I would suggest trying to merge the two
>>> documents first or at least I would like to see some dialog evolve
>>> publicly between the factions.
>>
>> Martin: while I share you hopes... I must ask: are you personally
>> stepping forward and saying that you will do the work of merging  
>> these
>> two documents?
>
> I'm glad to hear that Ian has taken efforts to integrate their  
> proposal, yet I seem to have missed the public discussion leading to  
> a consensus. If both parties agree and actively support it, I can  
> review and merge the two documents or post bug reports. I'd like to  
> hear Doug and Eliot's opinion first, and because of work for SXSW  
> I'm afraid I can't start before March 22.

I don't think we want to hold publication on work that can't start for  
over a month. So if you want to continue with this objection as a  
Formal Objection, we will likely have no option but to record it and  
pass it along to the Director. If you want to do that, pleas help us  
out by writing it up with the information mentioned here: <http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews 
 >.

We did have some private discussions with Doug and Eliot, but I am not  
comfortable with putting them on the spot publicly, and I ask others  
not to do so. If anyone wants to put forward a different draft on  
their own behalf, they may do so.

>
>>> b) Accessibility support in Canvas does not exist at all. The HTML
>>> Accessibility Task Force currently is working with several browser
>>> vendors on proof of concept implementations to enable usage with
>>> assistive technologies. Publication as a separate Working Draft is
>>> giving a wrong signal of maturity and should therefore be postponed
>>> until the task force proposes an adequate solution.
>>
>> There are a number of issues that will block progress to final Rec,
>> including but not limited to the following:
>>
>> http://www.w3.org/html/wg/tracker/issues/open
>>
>> The way we handle other issues is that we mark the status in the
>> document itself:
>>
>> http://dev.w3.org/html5/spec/the-canvas-element.html#the-canvas-element
>>
>> Are there other places in the document(s) that you feel that this
>> particular concern should be noted?
>
> The status remark is fine as a note, still I'm of the opinion that  
> the document is not ready yet for the next step while the Task Force  
> is working on a solution. Ian is right that the initial  
> accessibility of the <object> and <img> elements was worse, but that  
> was before WAI, WCAG, and the UN Convention on the Rights of Persons  
> with Disabilities. Accessibility as an afterthought for a current  
> specification is shaming and in my opinion a major blocker for  
> advancement in status.

I think you're underestimating the level of accessibility support  
already in the drafts, many of them as a result of the canvas  
accessibility subgroup's work. First, in HTML5: <http://dev.w3.org/html5/spec/Overview.html#the-canvas-element 
 >

1) Authors are required to provide an accessible alternative to  
<canvas> content as a MUST-level requirement: "When authors use the  
canvas element, they must also provide content that, when presented to  
the user, conveys essentially the same function or purpose as the  
bitmap canvas."

2) Canvas provides for the "accessible DOM" idea currently being  
discussed, but currently without any special indicator: "This content  
may be placed as content of the canvas element. The contents of the  
canvaselement, if any, are the element's fallback content.  ....  In  
non-visual media, and in visual media if scripting is disabled for the  
canvas element or if support for canvas elements has been disabled,  
the canvas element represents its fallback content instead." These  
requirements have the effect of exposing the contents of the canvas to  
assistive technologies as an accessible DOM.

3) UAs are required to make focusable areas in the accessible DOM  
still be focusable: "When a canvas element represents embedded  
content, the user can still focus descendants of the canvas element  
(in the fallback content). This allows authors to make an interactive  
canvas keyboard-focusable: authors should have a one-to-one mapping of  
interactive regions to focusable elements in the fallback content."

4) HTML5 includes support for ARIA, which may be used to mark up the  
accessible DOM to represent controls: <http://dev.w3.org/html5/spec/Overview.html#annotations-for-assistive-technology-products-aria 
 >


Second, in the HTML Canvas 2D Context draft: <http://dev.w3.org/html5/2dcontext/ 
 >

5) Focus management via the drawFocusRing method is defined: <http://dev.w3.org/html5/2dcontext/#focus-management 
 >. This allows visual display and spatial identification of a focused  
control that can map back to the accessible DOM.


This has all been added as a result of the canvas subgroup's ongoing  
work. My understanding is that they are still actively working on a  
proposal that will further refine these ideas and improve canvas  
accessibility even further. But I don't think it's fair to say that  
accessibility is "an afterthought", or that "accessibility support  
does not exist at all". There is a lot of accessibility support. It's  
not perfect, and we are still working to improve it. But that's true  
of everything in the spec.

In addition, I'd like to point out three relevant facts:

(a) The canvas API has already been published by the Working Group  
many times, as part of Working Drafts of HTML5; publishing it in a  
separate document would not be an "advancement".

(b) Most accessibility considerations actually relate to the <canvas>  
element, which is in the HTML5 draft, rather than to the API spec. So  
holding back just the 2D Context spec will not keep us from publishing  
the pieces with active ongoing accessibility work.

(c) However, some accessibility features are in the API spec; thus  
publishing HTML5 without 2d context, would result in publishing a  
solution that is actually less accessible.


Considering this additional information about canvas accessibility,  
are you willing to withdraw this second objection?


Regards,
Maciej

Received on Wednesday, 17 February 2010 11:40:16 UTC