Re: Still stuck on Use Cases

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



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.