On gaming accessibility, was: Re: canvas example

On 12/24/11 7:52 AM, Jonathan Mcdougall wrote:
> 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.
>

When you're just using ARIA, the browser does nothing more than pass the 
information to the OS -- if the user has something special installed, AT 
software, then that software will do something special.

Now, if you're using semantic HTML, like <input type="checkbox"> instead 
of <div role="checkbox">, the UA does have an opportunity to use that 
data. But, I don't think any UAs will do that any time soon.

We are working on a means of binding a Canvas path directly to a 
sub-tree element so that mouse events can go directly to the element. 
With something like checkbox, it's likely that it would have appropriate 
click() semantics.

Right now, IE is the only one to allow .focus() events to target 
sub-tree elements.
http://www.w3.org/TR/2dcontext/

That example is just temporary, in section 11, with the checkbox 
implementation, but it does show that focus() semantics help. With 
focus, you can press spacebar and it'll fire the usual events (a click() 
as well as keypress and change).

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

We are still talking about the realm of web techs; so I'd suggest they 
look over at WCAG.

It's a very practical document, in my opinion. They can start by looking 
at Level A and seeing which items they can reasonably scope.

No, they should not need to hire experts at this point, there's plenty 
of resources on the net. Experts certainly help for training, and they 
certainly help for auditing, but they're not necessary to make an effort.

Guideline 1.4, Level A, seems a pretty reasonable set of items to 
achieve in game settings.
http://www.w3.org/TR/WCAG/#visual-audio-contrast
"Guideline 1.4 Distinguishable: Make it easier for users to see and hear 
content including separating foreground from background"

There's a very full understanding document here, for everyone to use:
http://www.w3.org/TR/UNDERSTANDING-WCAG20/

There's a very full list of techniques here:
http://www.w3.org/TR/WCAG20-TECHS/

A fast paced game like Call of Duty, with the budget it has, could 
certainly afford to include additional levels of sound effects to assist 
users with low-vision and/or to provide an eyes-free interface. We all 
realize that the CoD genre is just one type of game play amongst many, 
many other types. First person shooters are commonly used as an example 
in arguments against the applicability of WCAG to the gaming genre in 
general.



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

Cheat codes are a common means of doing testing, whether automated, 
semi-automated or done by a QA tester.
They may or may not end up in production.

It's often the case that those codes might change settings to make 
things easier to see, or to expose more data.
They are often taken out of the production release, without considering 
accessibility.

My argument is that, if accessibility were considered, more of these 
testing techniques would be released as settings in the game.


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

Browsers expose and check their internal rendering and automation trees. 
The webkit unit tests are a good example of that technique.

Screen shot comparisons are ok; they're definitely a type of testing. 
But you also want to know if the screen has expressed that buttons are 
available. To do that, yes, you can check against bitmaps, visually or 
with a program. But, you also can check the render tree and the 
automation tree. You have a similar "dump" mechanism in canui.

Here is someone going to a bit of an extreme, but he's doing a great job 
at it:
http://graphics.stanford.edu/~mdfisher/D3D9Interceptor.html

All of that data he is using for his AI, he is first making more 
accessible for himself.

His AI is an automated testing bot, in a sense.


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

You can say the same about secure programming/security/memory leaks. But 
given experience, it's been realized that they are part of good 
practice. Identifying accessibility, and exposing data, is part of good 
programming practice. Now, you can certainly have bad code, undocumented 
APIs, and so forth. I've certainly had undocumented APIs for a long time 
in my projects, because I simply haven't had the stability, budget or 
reached the point of maturity in those projects to do better. But I 
don't consider documentation a feature. It's a part of the maturity of 
the project, and one that I just haven't been able to reach.

But I'm a lowly little guy. With a reasonable budget, and when scoped 
from the onset, it makes these things very achievable.

When they are not scoped from the onset, you end up underestimating the 
project.

I've found accessibility to be a very good part of initial scoping, 
because it includes things like saying: "let's make sure the keyboard 
works", "let's make sure this works in multiple screen sizes". You don't 
have to spell those out in the scope, if WCAG is adopted as part of 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.
> 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.
>

True, it's optimistic. But color management is quite similar to language 
management. You turn your hard-coded strings into variables and you use 
a dictionary. Perhaps you include an additional pixel shader or batch 
processing step as well. I'm more interested in the cost of making font 
size and colors flexible, not adding a complete theme engine to change 
every aspect of the UI. And I have that scope thanks to WCAG.


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

Well, you're taking extremes here. But if you're looking at players who 
may have challenges with language, that is part of WCAG, and it applies 
as well to players where the language of the game may not be their 
native language. When you look at an a11y issue, it's not just about one 
group. It affects many groups. Larger text means that someone might be 
able to play your game on a small tablet, whereas they otherwise would not.

http://www.w3.org/TR/UNDERSTANDING-WCAG20/

Now you're looking at: 2.2, Granting enough time, 3.1, Readable, and 
1.4.4, Resize Text.

As someone who uses a computer for TV, I like having all three of those 
options. It makes things much easier on me.

Game developers often work with different window sizes, volume controls, 
resolutions, and so on. It's a big part of the low-level and high-level 
work they do. If they were able to go to a sheet and say yes, I achieved 
this, it's a good thing. That's a standard sheet now. Kind of like 
building codes are standard and can be referred to.



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

I noticed. It's just list.js. You can see it in my first commit.

Your code is fine.

>> 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 :)
>

They don't need to be dotted. They're not dotted in Chrome, for example. 
You can see the example in the w3c Canvas spec of drawing focus rings on 
a checkbox.

The thing is, they'd be a lot easier and more effective with vendor 
support. Working around it is quite a bit of work. I'll be documenting 
the work-around techniques and submitting them to WCAG-TECHS.

Vendors are supportive of drawFocusRing. I think we'll get it in there.

We've also been pushing for a setElementPath (though the name could use 
some work); it'd bind the current path to an element in the sub-tree for 
capturing mouse events. drawFocusRing works quite well for keyboard 
events, as the user presses the tab key or other keys to navigate.


-Charles

Received on Saturday, 24 December 2011 20:57:07 UTC