input type=color, was: Re: canvas example

> Please see...
> http://ie.microsoft.com/testdrive/Graphics/hands-on-css3/hands-on_transparency.htm (Color pickers)
> http://ie.microsoft.com/testdrive/Graphics/hands-on-css3/hands-on_text-shadow.htm ('Shadow color')
> ...for HTML5 examples of a developer creating new controls with canvas.
>
> I'd be interested to know what you would add to the a11y DOM inside the canvas element to represent the same content - any feedback on that?
>

TL;DR: <input type="slider" role="range" aria-valuemin min"> would be a 
big improvement.

The author was clearly not aware of either semantic, or of data-* and 
instead used a custom attribute to stash the GUI state in. They followed 
good practices, and it would be trivial for them to update the 
demonstration to follow HTML5+ARIA standards. Focus can go on the canvas 
elements themselves, with tabindex applied, with activedescendant 
pointing to the input field.


....



Frank, is this graphics project still active?

I do want to keep this thread going.

First, an inspiring short article on colorblindness:
http://www.rps.psu.edu/probing/colorblindness.html

Second: WCAG and ARIA should be reviewed by coders working on these 
testdrive projects.

It's absoluely clear that the coder of these examples was quite good at 
programming but was not aware of ARIA nor of the data-* prefix. It takes 
less than a minute to see that.

I have no doubt that, given an hour, the programmer of these examples 
would realize how to revise their use of the DOM. It would take them a 
bit more time to catch up on WCAG principles, but given the level of 
professionalism in their code, I'm sure they would take on that 
challenge with a positive attitude.

This one line is enough to see that ARIA and WCAG were not in mind, nor 
was the data-* prefix:
<span class="sliderControl" 
slideroptions="min:0;max:20;step:1;value=0;readout:none;units=px;setter=SetWidth"></span>

For what it's worth, whitehouse.gov has neglected to meet WCAG/ARIA as 
well, and they have very professional and capable programmers as well. A 
few hours with the appropriate links and I'm sure their programmers 
would understand the shortcomings in their code base.

...

I am going to continue this thread on implementing input type=color. 
Over the past four years I've seen my Michael Deal (colorjack.com / 
mudcu.be) implement several color input types. I've learned a lot about 
color theory and was gifted a thick book on the matter.

There are several levels of accessibility: authoring is one of them. In 
the case of input type=color, the user is likely to be in an authoring 
mode, not in a mode of consumption. As such, input falls under ATAG 
guidelines in addition to WCAG.

input type=color ought to have reportable / discoverable metrics for 
judging color contrast, and simple descriptions for the current color 
selection that do not require a user to parse HSL or RGB reports in 
their head.

It is quite possible to report: "the color is a light yellow, with a 
high contrast ratio to the background. The color contrast is not usable 
by users with tritanopia". The Canvas tag is presentation, the subtree 
would contain a slider/range (html5/aria), a legend and a live area 
might report on the usability of the color scheme.

As I verify licensing for various components, I'll assemble them and 
report on them for this thread. This includes conversion of RGB to HSL 
as well as estimation for color ratio and color blindness.


On this topic, Michael Deal put up a handy reference tool to simulate 
color blindness as well as a tool to emphasize color distinctions within 
an image.

http://daltonize.appspot.com/


-Charles
>

Received on Tuesday, 1 November 2011 22:28:11 UTC