Still stuck on Use Cases

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.