Re: [media] Addressing "3.1 Keyboard Access to Interactive Controls"

Hi Sean,


On Wed, Jun 30, 2010 at 1:58 AM, Sean Hayes <Sean.Hayes@microsoft.com> wrote:
> 1 & 2 I think what this may have been trying to say is the requirement to have the same functionality be present in the scripted controls as in the built in, and have them go through the same platform level accessibility framework (where it exists), so that a user presented with the scripted version is not shut out from some expected behaviour. I agree however that the section needs a re-write.

Yes, agree with that analysis.

In addition, I also think there is more in the introductory section
than just making scripted and declarative controls go through the same
platform level accessibility framework.


> 3. I think that's a good addition, but not I think the original intention (but I could be wrong)
>
> 4. We should prefix all keyboard and focus requirements with something like "on systems where a keyboard is (or can be) present, and where a unique focus object is employed..."
>
>
> Overall I agree that this needs the larger group to discuss.


OK - I will make a list of all the things we have identified to
discuss in the larger group and forward.


Cheers,
Silvia.


> -----Original Message-----
> From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com]
> Sent: Saturday, June 26, 2010 12:00 AM
> To: Sean Hayes
> Cc: HTML Accessibility Task Force
> Subject: [media] Addressing "3.1 Keyboard Access to Interactive Controls"
>
> Hi Sean,
>
> (copied to TF for documentation purposes)
>
> Am now looking at the feedback on section 3.1. of media requirements:
> Keyboard Access to Interactive Controls / Menu http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Keyboard_Access_to_interactive_controls_.2F_menus
> http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq12
>
>
> 1.
> The requirement is sound, but the introductory text is strange.
>
> "If the author chose to create a new interface using scripting, that interface MUST map to the native controls in the user agent, so the user can ignore author controls and use accessible native controls."
>
> Scripted controls do not "map" to native controls, rather they both control ("map to") the same underlying interface. However, this is completely unrelated to the possibility of ignoring author controls. I suggest removing the section completely and adding a requirement that it should be possible to enable native controls regardless of the author preference (stated through the controls attribute on <video>)
>
> Reply: it seems to me that the point of this section was not understood. In my understanding, the point of the section is to provide a rich set of controls to the user and to ascertain that they are keyboard accessible; further if custom keyboard controls are run through a JS interface, these should be accessible, too. It seems the introductory text needs a complete re-write.
>
> Discussion: Apart from the above comment, it almost seems to me that the introductory text has more requirements than the requirements list
> - we could turn many of them into actual requirements.
>
>
> 2.
> I don't understand "If the author chose to create a new interface using scripting, that interface MUST map to the native controls in the user agent". Controls implemented with scripting should *use* the same interface to control a media file, but they do not use the native controls. Like Philip, I suggest we add a requirement that it must be possible to enable native controls even if a page has custom controls.
>
> Reply: I think we need to discuss with the a11y group if that is really what was meant by the requirement, or rather whether there was just a general requirement to make controls accessible (see also 1.
> above).
>
>
> 3.
> In the introductory text, could say like "MUST NOT interfere the native controls" instead of saying "MUST map to the native controls"?
>
> Reply: sounds good - accept?
>
>
> 4.
> Question: How do mobile devices operate these controls without a keyboard? Are you going to require that devices support a keyboard to access controls/menus? I would investigate this issue with the mobile device manufacturers.
>
> Reply: this is a good point - needs to be discussed with larger a11y group
>
>
> 5.
> Seeking confirmation from UAWG that this is the only keyboard support requirement that needs to be referenced?
>
> Reply: back to a11y group - any more feedback available?
>
>
> ===
>
> In general, I think this section needs a discussion with the larger media a11y group to determine what was actually meant and make sure we express that well.
>
> Cheers,
> Silvia.
>
>

Received on Sunday, 4 July 2010 11:09:44 UTC