Re: canvas example

On Fri, Dec 23, 2011 at 9:59 PM, Charles Pritchard <chuck@jumis.com> wrote:
> On 12/23/11 6:11 PM, Jonathan Mcdougall wrote:
>
> 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'));

Now *that* is something I never thought about and I now understand
your point. Would a browser overlay the canvas with native controls or
is the information enough to be able to interact with the canvas? Is
there any browser right now that handles the subtree? Firefox doesn't
seem to do anything with it.

>> I don't find accessibility in games, for example, to be
>> particularly important. [...]
>
> 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.

But that doesn't help if the user can't play the game properly.
Someone with motor dysfunction or blindness can't play Call of Duty,
even if the menus are bigger or have a braille interface. Should the
developers choose which disabilities they want to support? Should the
company pay a consultant how knows more about accessibility so it can
suggest what kind of disabilities can be supported?

> 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.

This I'm not sure I agree with. The unit testing I've seen is not what
I would call "automation", it is about postconditions being respected.
It does not (and should not) allow the test to access any more
information that the normal flow would or you would be testing
something that runs differently in production.

You don't need an automation api to do unit testing. This would have
to include interprocess communication, a lot of parameter validation
and error handling and basically coming up with an additional layer on
top of the program or the library (that also needs to be unit tested.)

I've had little experience with user interface testing (which I think
you are referring to.) What I've seen is more of a playback feature
in addition to unit testing, sometimes with automated screenshot
comparisons.

However, my experience with testing is rather limited and I can't
argue too much on this, but accessibility sounds more like a costly
feature than a part of the "testing requirements."

> 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.

Again, features always start at -10 and need to be planned,
implemented and tested. Saying that the cost of theming is "minor" and
"involves little bit of code" sounds optimistic at best, unless you
really are talking about arkanoid.

> 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.

But this might imply having a user interface that is flexible enough
to adapt to different font sizes or faces, which I wouldn't call "best
practices." This is a lot of work for a few users. If I have extra
time and money after putting in all the features I want, I'd much
rather port my game to linux where I can reach more users than trying
to make it accessible to individuals with Down syndrome. Accessibility
has a rather high cost for very little reward, which is probably why
nobody but government agencies do it.

> Here I am turning the checkbox into something that will describe
> that a) it's a checkbox, and b) whether it is checked, unchecked or
> mixed.
> https://github.com/Downchuck/canui/commit/36e816198000dc08fde8c2742f7bd3624c9b8935

A fork! Yay! :)

By the way, I did a few checkins after releasing 0.7 which probably
broke at least the list control. I was in the process of separating
the selection mechanism so it could be used by the tree control and
that's when I stopped working on it. So the head of the trunk is in a
messy state right now.

> There are some other tweaks to be had, but that shows the magic
> pretty well. It took me 30 minutes to clone, boot up and edit the
> project to support accessible checkbox.

Now that I understand that canvas can have a meaningful subtree, this
makes more sense to me.

> There are additional subtleties to add, and when we see vendor
> support of drawFocusRing they'll be easy to do.

Which I did try very hard to use, until I realized firefox doesn't
support it yet. Drawing dotted lines is a pain :)

Also, happy holidays!

-- 
Jonathan McDougall

Received on Saturday, 24 December 2011 15:53:48 UTC