Re: canvas example

On 12/23/11 6:11 PM, Jonathan Mcdougall wrote:
> On Fri, Dec 23, 2011 at 3:07 PM, Charles Pritchard<chuck@jumis.com>
> wrote:
>> On 12/23/11 5:57 AM, Jonathan Mcdougall wrote:
>>> I still think reimplementing single widgets in canvas is a bad
>>> idea, aria or not. Using a custom user interface in a canvas as
>>> part of a larger application is fine, but then aria couldn't be
>>> applied to individual widgets.
>> What do you mean about ARIA not being applicable to individual
>> widgets?
>>
>> Keep in mind, a single widget may be<input type="color">  [...]
> We're still having trouble talking about the same thing. I was under
> the impression that this mailing list was about<canvas>  and this is
> what I'm talking about.
>
> When I say aria can't be applied to individual widgets, I'm talking
> about having multiple widgets in the same canvas, which was the whole
> point of canui.


So here is what you have:
http://canui.sourceforge.net/

<div id="ui"
      data-layout="new ui.horizontal_layout()"
      width="200" height="200">
<div data-type="label">Name:</div>
<div data-type="textbox">here</div>
</div>

There are standard means of expressing some of those data-* types, 
specifically, the textbox and label.
They are simple types so they also exist in semantic HTML.

This is what you would change it to:
<div id="ui"
      data-layout="new ui.horizontal_layout()"
      width="200" height="200">
<div data-type="label" id="textboxlabel">Name:</div>
<div data-type="textbox" role="textbox" 
aria-labelledby="textboxlabel">here</div>
</div>

Subsequently, when you boot up the canvas, you'll just pop that data 
into the canvas sub-tree. That sub-tree was originally thought to be 
useful for fallback content for old implementations of browsers. Turns 
out that's only half the story. When the Canvas is live, the sub-tree is 
still useful.
canvasElement.appendChild(document.getElementById('ui'));

Note that we changed nothing in your program, everything works as is, we 
just kept the scene exposed to the DOM.
There are additional states that can be exposed in the DOM, such as 
hooking onmousedown to setAttribute('aria-pressed').

ARIA works for individual and composite widgets.

I'm bringing it up on a Canvas list, because it applies to your UI examples.
http://canui.sourceforge.net/examples/index.html


>> The purpose here is to expose information. When it's not exposed,
>> then things are not accessible. When it's exposed, people have a
>> chance to adapt and use that information in complex ways.
>>
>> I'm happy to explore your understanding here.
> Okay, I'll bite.
>
> I don't find accessibility in games, for example, to be particularly
> important. It is a costly feature to implement: development of a
> proper technology, planning, training (few people are aware of
> accessibility), development and testing. All of this for not much in
> return. This also applies to<canvas>  when used in the same context.

Games are highly structured -- they often use GL, these days, requiring 
quite a bit more finesse and discipline than Canvas. There are various 
tests that may be important for game developers, to help their users. 
They often have settings to toggle resolution, to change color schemes, 
and so forth.

Consider testing and text content development:

I certainly agree that accessibility is not on the priority list for 
many companies. They are missing out on some of the benefits. 
Accessibility APIs are often referred to as automation APIs. Using 
accessibility means easier and more standard routes for testing. Let's 
say you setup an automated test to walk through some part of the game -- 
if the UI is accessible, you can programmatically read what's on the 
screen as part of your testing requirements. Now, this happens in 
testing anyway, but it involves arbitrary classes and APIs which the 
tester has to learn. They can avoid that overhead by simply looking at 
the end-result.

Often, there are tester settings, designed to make testing easier. They 
can quite often be something that would help some users to engage the 
software.


Consider audience and scope:

Simple games where users match up blocks or the like, well they're 
simple. Some accessibility testing might mean that there's a theme where 
the blocks have better color contrast or are more easily visible to 
people who have trouble distinguishing red and green. The cost is minor, 
it involves a little bit of code to switch color schemes. Without 
accessibility, the thought of themes might just be totally out of scope. 
It's a feature. But with accessibility, it's very much within scope, and 
the code base benefits from a needed layer of flexibility. While a game 
may have really neat but difficult to read text, is there any reason not 
to have an option to make the text more legible? If it's thought of as a 
feature, yes, there's a reason, it'd be scope creep. If it's thought of 
as part of best practices, it's easy to justify including the option.


AT testing -- that is, opening up assistive software or devices and 
trying out software, well that's certainly costly, and it's 
accessibility only for the sake of accessibility. That's something that 
is required of some software development projects, but only a minority. 
That's not something I see being of large importance to game makers.

That said, I believe developers benefit by using ARIA and WCAG, to 
define scope, to enhance testing and interoperation.
http://www.w3.org/TR/WCAG/

With those checklists, there are standard items that should be part of 
project scope, and there is a standard vocabulary for some of those APIs 
that are typically locked away in the code environment.


> I find that specifying semantics works fine when working with
> structured data so that both people with disabilities and automated
> tools can access the information. Using images or videos without
> transcripts is for me an unfortunate (but necessary) evolution of
> of the way we represent data. Youtube is a treasure trove of
> unretrievable (and ultimately lost) information.
>
> That being said, trying to come up with accessibility features for
> <canvas>  does not strike me as being a priority. It is not structured
> information, it is merely a bitmap. SVG is a much better target for
> this.

The information is structured in the scripting environment; the purpose 
is allowing the scripting environment to share that structured data.

It's certainly possible to program UI in SVG; your project could have 
both an SVG and a Canvas output mechanism -- but that would be a costly 
investment. Whereas simply re-using the <div> tag scheme you already 
support is a relatively inexpensive method.

You have a button at the bottom of your examples which dumps structure 
from your <canvas> app:
http://canui.sourceforge.net/examples/index.html

The useful parts of that structure can be shared with the operating 
system, through the canvas sub-tree. In doing so, the Canvas is made 
accessible.

Does that make sense?

-Charles

Received on Saturday, 24 December 2011 03:00:11 UTC