Re: Still stuck on Use Cases

I encourage everyone to have at least a dialog with their respective 
accessibility testing groups
about how these APIs interact. I'm glad that you're making yourself 
available at TPAC to give a crash course.

Though aged, this simple screen shot demonstrates an accessibility 
object inspector:
http://www.ehealth.va.gov/508/terms/object_inspector.html

For everyone: testing, regardless of host (be it flash, html, aria, some 
kind of mix)
at some point involves looking at the accessibilty tree, to see that 
items are reported correctly.

In the case of canvas, we're missing location, but otherwise, things are 
working well.

Now, flash is a much more "complex" set of UIs than Canvas; it's 
certainly been a trendsetter
for items that eventually make it into W3C standards.

This is over-kill -- it's more low level than we need:
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/accessibility/AccessibilityImplementation.html



-Charles

On 7/28/2011 2:59 PM, Richard Schwerdtfeger wrote:
>
> Thanks Charles.
>
> What I think I really need to do is give them a crash course in 
> accessibility infrastructure and how all this stuff needs to map to 
> platform accessibility APIs. I could do this at TPAC.
>
> Rich
>
>
> Rich Schwerdtfeger
> CTO Accessibility Software Group
>
> Inactive hide details for Charles Pritchard ---07/28/2011 02:41:30 
> PM---It appears the WHATWG has taken some interest in the clCharles 
> Pritchard ---07/28/2011 02:41:30 PM---It appears the WHATWG has taken 
> some interest in the clickable region issue lodged by Richard:
>
> From: Charles Pritchard <chuck@jumis.com>
> To: "public-canvas-api@w3.org" <public-canvas-api@w3.org>
> Date: 07/28/2011 02:41 PM
> Subject: Still stuck on Use Cases
> Sent by: public-canvas-api-request@w3.org
>
> ------------------------------------------------------------------------
>
>
>
> It appears the WHATWG has taken some interest in the clickable region 
> issue lodged by Richard:
>
> Issue 13176:_
> __http://www.w3.org/Bugs/Public/show_bug.cgi?id=13176#c5_
>
> Log:_
> __http://krijnhoetmer.nl/irc-logs/whatwg/20110728#l-53_
>
> # [00:21] <jamesr> i don't know if you want to start going down the 
> 'can we get use cases' path
> # [00:21] <timeless> i don't mean use case as in `tell me that you 
> need accessibility`
> # [00:21] <timeless> i mean `show me a site that's trying and has 
> something so i can see how the problem really manifests`
> # [00:21] <timeless> problems you can't touch, grasp, or hold are much 
> harder to address properly
> # [00:22] <jamesr> 
> _http://lists.w3.org/Archives/Public/public-canvas-api/_is full of 
> people asking them (richard schwesdflkjsdlkfj and charles prichard) 
> for exactly that and them writing novellas that don't quite give 
> concrete use cases but sure do use a lot of words
>
>
> I've indeed written "novellas", with many citations, in an attempt to 
> give some formal explanation. It's been a lot of work.
> I started with simple messages, direct and tech-based... they've been 
> lost in meta-discussion about "wrong" and "right"
> uses of Canvas.
>
> Doug Schepers has compiled use cases based on work from various people 
> on the list:_
> __http://www.w3.org/WAI/PF/HTML/wiki/Canvas_Accessibility_Use_Cases_
>
> As for the request that timeless lodges, Steve Faulkner started a 
> thread with lists of Canvas-based UIs:_
> __http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0182.html_
> _
> __http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0150.html_
> "To remedy the situation, we've proposed: setElementPath(element);
> allowing authors to support spatially aware assistive technologies such
> as Apple's VoiceOver for Mobile Safari"
>
> I've made more progress in private discussion than I have in public 
> discussion with Tab Atkins about
> the issue, so I'll be addressing the WHATWG members privately. Having 
> already gone to the WHATWG
> in relation to caret tracking (now: scrollPathIntoView at the WHATWG), 
> I do not want to jump
> into the public fray again.
>
> .........
>
> I made an appearance at the SVG F2F on Weds July 27th to discuss 
> Canvas+SVG integration as well as A11y issues
> we've discovered in Canvas that may apply to SVG._
> __http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda_
>
> During the SVG F2F, we explored the regions issue (per the bug report) 
> as well as Richard's proposal for setClickableElement.
> I'm confident that everyone in the SVG F2F room is now aware of the 
> reasons and interfaces behind Issue 13176.
> I'd like for those members of WHATWG in the IRC channel from 20110728 
> to have a similar awareness. How do we make this happen?
>
> As scribed by Tab Atkins at the SVG F2F:_
> __http://www.w3.org/2011/07/27-svg-irc_
> 23:58:31 [TabAtkins__]
>
>     shepazu: So I think on the surface it seems reasonable, though it
>     verges into a retained mode. You already have a retained mode with
>     the fallback as well. 
>
> 23:58:39 [TabAtkins__]
>
>     shepazu: But where does this end? 
>
> 23:58:59 [TabAtkins__]
>
>     pritchard: It seems like this is the end. Based on the OS AT APIs
>     so far, these fill in all the information necessary. 
>
> 00:00:03 [TabAtkins__]
>
>     pritchard: We have focus position, caret position, and clickable
>     regions. That's as far as all the ATs go anyway. 
>
> 00:01:08 [TabAtkins__]
>
>     heycam: These seem more reasonable than the permathread suggests. 
>
>
>
>
> Two things I've taken away from that SVG F2F meeting: a11y authors 
> were calling the fallback content in canvas subtree
> the "canvas shadow dom". This is confusing to most vendors: it should 
> be referred to as the canvas subtree.
> A11y used the term "drawFocusRing", which is confusing to many 
> vendors, as the term has other semantics.
>
> A focus ring may be the order in which tab navigation occurs. A shadow 
> dom may be an inaccessible dom
> which the browser uses to render a widget/component.
>
>
>
>