Re: Reasons of using Canvas for UI design

In thread.



On Aug 15, 2011, at 10:16 AM, David Singer <singer@apple.com> wrote:

> 
> On Aug 15, 2011, at 19:10 , Richard Schwerdtfeger wrote:
> 
>>  The browser has all the path transformation information 
>> > to do the job
>> > All true -- if the assumption holds.
>> 
>> I am not sure what is missing. Are you concerned about a coding error? That can always happen.
>> 
> No, I am pointing out your assumption is that there are objects with well-defined path boundaries.  I am not sure that's always true.

Such cases are beyond the scope of this basic work. At preset, we're merely trying the achieve parity with existing interfaces and practices. They are no different than they were a decade ago. We're simply trying to populate the accessibility APIs present and reasonably uniform in Mac, Windows and Linux/BSD.

The philosophical questions about communication are a different issue.

By and large, bounding boxes are use to describe spatial areas on 2d displays. I saw it on the movie, the Terminator, so it's clearly a solution that will work in the long term. Amiright?

Seriously though, opencv has quite a few bounds detection algos which would work well with video+canvas HUD. The point is not that bounds are Exact, with a capital E. It's the they are useful, for purposes of communication.


>> Being able to support the basic accessibility APIs is essential. Right now we do not have that. The need to indicate where an object is on the drawing surface is an essential requirement. 
>> 
> Again, an assumption of visually discrete objects with well-defined locations and edges.

Assumption that author define locations are sufficient based on the authors intent and subsequent usability testing. More-over, this is all standard practice an has been for over a decade. There is no invention here, we're just playing catchup on something that was missed when the canvas tag was introduced.

I appreciate your eagerness to invent and come up with new means of expressing accessible data.

>> What we need to avoid here is the statement that "well you have not fully boiled the ocean so you can't do anything."
>> 
> But we also need to avoid "you can only solve the use cases when someone uses canvas when they could and probably should have used existing HTML and CSS UI elements". 

> 
Fixing this glaring issue in canvas subtree a11y in no way inhibits authors who are not using canvas or who otherwise do not present a11y data.

The thing it does do, and this is important, is that it enables existing authors, the thousands of canvas-based projects out there, to make their apps more accessible for pointer-based/spatial navigation.

We are solving existing problems, there is an existing a11y API hole (accLocation) and there are existing applications and vendors looking to fill that hole as part of WCAG.

I'm happy to see attention on a11y and brainstorming about future interfaces, but that's far-off from the present condition of supporting existing infrastructure, in the major operating systems.