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

Note, you can see the changes that have been made at this link:
http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Media_Accessibility_Requirements&diff=1884&oldid=1883

Regards,
Silvia.

On Fri, Jul 23, 2010 at 11:01 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com
> wrote:

> Note to all:
>
> Changes to the Keyboard Access section [1]
> according to feedback from the survey [2]
> and discussions of that feedback between Sean and myself have been
> finalised in the wiki [1].
>
> Some notes on technical realisation have also been included, similar
> to other discussions in the group on other media requirements areas.
>
> [1]
> http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Keyboard_Access_to_interactive_controls_.2F_menus
> [2]
> http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq12
>
> Best Regards,
> Silvia.
>
> On Sun, Jul 4, 2010 at 9:08 PM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
> > 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.
> >>
> >>
> >
>