native rendering of video and communication with AccessAPI

My task from the Nov 11, 2007 telecon [1]: Make a proposal for new
checkpoint related to native rendering of video and communication with
AccessAPI etc.

During the meeting we discussed the <video> element in HTML5 [2]. <video> is
to be rendered natively by the UA. I shared information about the alpha
version of Opera that was demonstrating native rendering of the <video>
element [3] and the associated controls (stop, start, volume, seek, etc.).
Video controls are an attribute (@controls) of the video element [4] and are
to appear in the DOM.

During our discussion, we (KF, GJR, PP, JR, JA) agreed that if something
with controls is rendered natively by the UA then the controls become part
of the 'chrome' of the UA. Then all of the guidelines pertaining to the
device independence, operation, navigation, and exposure to AT apply to the
natively rendered controls. 

There are issues:
a. "Rendered Natively" is a cause for concern, as UAAG does not have a
definition. This definition would also apply to UAs that have native support
for SVG, MathML, etc.  
b. In addition to the DOM, should the UA explicitly communicate the role and
state of controls to the appropriate accessibility API or platform
accessibility mechanism? I think YES. 
c. How does the UA reveal the keybindings, if any, to the user? I think this
can be covered in techniques. 
d. The author may provide scripted controls in place of the native controls.
Should the user be able to override or toggle between the author supplied
controls and UA supplied controls? I think yes.
f. Need for a proposal for a new checkpoint...not sure. 


Jim Allan, Webmaster & Statewide Technical Support Specialist 
Texas School for the Blind and Visually Impaired 
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264
>>> Share to Win! <<<

Received on Thursday, 6 December 2007 18:57:20 UTC