- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Sun, 4 Jul 2010 23:08:31 +1000
- To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Hi all, Sean and I have discussed our topics and I have extracted the following list of issues to return to the larger group for discussion. 0. General Point Sean pointed out that the document needs a Glossary of Terms. ======= 1. Captioning Section Feedback was provided at: http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq7 for the text at: http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Captioning Discussion thread between Sean and I starts at http://lists.w3.org/Archives/Public/public-html-a11y/2010Jun/0198.html The following need to be discussed in the larger group: (1) Philip's feedback on positioning (CC-5) Support positioning in all parts of the screen. Philip's issue: Is this a requirement for pixel-perfect positioning, or relative positioning? Must it be possible to give a bounding box for the text, or is it enough to say where it starts? Sean: CC-5 is for positioning of regions of text, e.g. to disambiguate multiple speakers or to avoid some information in the underlying media. Therefore the min requirement is a bounding box (with an optional background) into which text is flowed, and that probably needs to be pixel aligned. The absolute position of text within the region is less critical, although it is important to be able to avoid bad word-breaks and have adequate white space around letters and so on. Silvia: I further think with "all parts of the screen" we mean either the bounding box of the video or a randomly provided bounding box on the web page into which the caption cues are rendered. I think by default the caption format should provide a min-width/min-height for its bounding box, which typically is calculated from the bottom of the video box, but can be placed elsewhere by the Web page, with the Web page being able to make that box larger and scale the text relatively, too. The positions inside the box should IMHO be into regions, such as top, right, bottom, left, center. ISSUE: What are the positioning and size requirements for captions on screen? (2) I don't think there are any other issues to discuss on captions, but there are changes to be made according to the discussion between Sean and myself. ======== 2. Extended Captions Section Feedback was provided at: http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Extended_Captioning for the text at: http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq8 Discussion thread between Sean and I starts at http://lists.w3.org/Archives/Public/public-html-a11y/2010Jun/0215.html The following need to be discussed in the larger group: (1) Philip's feedback on activation mechanisms (ECC-2) Support hyperlinks and other activation mechanisms for supplementary data for (sections of) caption text. Philip: I would like to see links, but "other activation mechanisms" is again much too vague. What are the actual requirements and use cases? Silvia: improve ECC-2 by replacing it with "These enrichments may be provided as additional timed text tracks, or inline in the captions as comments, or as hyperlinks on the terms that are being described further. Sean: Hyperlinks is still vague, since it could have multiple meanings. The other parts seem fine. We need to flesh out exactly what is required by 'linking' in the larger group since this could go well beyond anything that has been deployed to date. ISSUE: What do we mean by "linking"? (2) Eric's feedback on overlapping captions (ECC-4) Support captions that may be longer than the space to the next caption and thus provide overlapping caption cues - in this case, a feature should be provided to decide if overlap is ok or should be cut or the media resource be paused while the caption is displayed. Eric: How does this work? Who decides if "overlap is OK ..." Silvia: If an author provides extended captions, then overlap has to be expected to play back those captions with the media resource. A user could always overrule the default behaviour, i.e. decide to ignore caption extensions, or control them better with from keyboard, etc. Sean: Not necessarily for a very fast reader. So again I think this needs more thought. ISSUE: Who decides which overlap is ok? (3) Richard's feedback on smaller font (ECC-4) Support captions that may be longer than the space to the next caption and thus provide overlapping caption cues - in this case, a feature should be provided to decide if overlap is ok or should be cut or the media resource be paused while the caption is displayed. Richard: Regarding ECC-4 what about providing a feature to configure wrapping text with smaller fonts? This seems better than cutting off the text. Silvia: it still needs to remain readable, so smaller font is probably not a good idea. Sean: It should be up to the user to decide what is OK; so defining a smaller font is a possibility, although I agree maybe not universally desirable. Silvia: I think there may be a misunderstanding about what this requirement is referring to. I do not think this requirement refers to the lack of physical space to display the caption text. IMO, the idea of ECC-4 is that captions may be provided for a longer time than is available to them (from the media resource timing). Giving them the time they need is an alternative to shortening their text. Thus, the problem is that the text is too long for the time period to read fully and the caption will be provided longer and overlap with the next one. This is possible, because the UA can pause for the time that the caption cue needs before moving the media resource and the caption on to the next. Thus, making the font smaller will not have any effect on the readability of the caption cue. ISSUE: What did ECC-4 refer to? (4) Sean's feedback on what extended captions mean (ECC-2) Support hyperlinks and other activation mechanisms for supplementary data for (sections of) caption text. (ECC-4) Support captions that may be longer than the space to the next caption and thus provide overlapping caption cues - in this case, a feature should be provided to decide if overlap is ok or should be cut or the media resource be paused while the caption is displayed. Sean: ECC 2 - split into two requirements, one for additional information that can be displayed in the same time as a caption (Ruby for example could be considered this kind of information); and another for information which is presented independantly outside the timeline of the media. ECC-4 - needs to be distinguished from the normal caption case of two speech acts that overlap in time (e.g. an interruption). Also the required display time of extended text information is dependant on the users reading speed. user should have a means to control the display time and size so that if they can keep up they avoid pausing the video Silvia: are overlapping captions necessary for the "normal case"? Sean: I think it is important to distinguish between caption annotations which won't imply changing the underlying timeline of the media, and those that will. Since the latter requires a lot more mechanics to support and may not be acceptable, while the former should be. Silvia: That may be the case. Maybe there are two types of extended captions that we are dealing with, which may also relate to your issue of what to call them. Sean: Yes, there are overlapping captions, though obviously not all the time; but this is a common occurrence in real media. Silvia: I see - you are there talking about e.g. conversation where captions overlap in time, but not in space. Indeed, there needs to be a distinction. It sounds like it will be worth a discussion to identify how to distinguish between the cases and what groups of cases we have and what we can call them. ISSUE: are we subsuming too many different types of "extended captions" under that term? Should we separate out different types and what should they be? ======== 3. Keyboard Access to Interactive Controls Section Feedback was provided at: http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Keyboard_Access_to_interactive_controls_.2F_menus for the text at: http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq12 Discussion thread between Sean and I starts at http://lists.w3.org/Archives/Public/public-html-a11y/2010Jun/0232.html The following needs to be discussed in the larger group: (1) Philip & Eric's feedback on the section: (KA-1) Support operation of all functionality via the keyboard using sequential or direct keyboard commands that do not require specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (e.g., free hand drawing). This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation. Philip's feedback: 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>) Eric's feedback: 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. Sean: 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. Silvia: Yes, agree with that analysis. In addition, it seems to me that the introductory text has more requirements than the requirements list - we could turn many of them into actual requirements. In particular to provide a rich set of controls to the user and to ascertain that they are keyboard accessible. ISSUE: Did the requirement relate to having the same platform level a11y framework for scripted and declarative controls or for requiring native controls? And do we want to extend the set of controls that should be required? (2) Masatomo's concern about native controls: Masatomo: In the introductory text, could say like "MUST NOT interfere the native controls" instead of saying "MUST map to the native controls"? Silvia: sounds good - accept? Sean: I think that's a good addition, but not I think the original intention (but I could be wrong) ISSUE: What was the original intention? (3) Richard's feedback on mobile devices Richard: 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. Sean: 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..." ISSUE: what to do about keyboard accessibility on mobile devices? ======== 4. Requirements on the use of the viewport Section Feedback was provided at: http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Requirements_on_the_use_of_the_viewport for the text at: http://www.w3.org/2002/09/wbs/44061/20080526_media-requirements/results#xq17 Discussion thread between Sean and I starts at http://lists.w3.org/Archives/Public/public-html-a11y/2010Jun/0236.html The following needs to be discussed in the larger group: (1) Philip's feedback on dimensions: (VP-1) If alternative content has a different height or width to the media content, then the user agent will reflow the viewport. (UAAG 2.0 3.1.4). Philip: Text tracks don't have dimensions, they depend on the video track. If there are text formats where this is not true, those formats will not be used on the web. Remove this requirement. Silvia: UAAG 2.0 states the following: "3.1.4 Rendering Alternative (Enhanced): Provide the user with the global option to configure a cascade of types of alternatives to render by default, in case a preferred type is unavailable. If the alternative content has a different height or width, then the user agent will reflow the viewport. (Level AA)" Text tracks may have dimensions, but they should be provided relative to the video viewport rather than as absolute sizes IMO. Alternative content could also be other videos, so this makes reflowing the viewport still a requirement. It is, however, a question whether reflowing the viewport is acceptable, in particular if the dimensions of the media were fixed by the author. May need to discuss this in the media a11y group. Sean: I disagree. An audio only player with captions/lyrics etc is an important use case; I can definitely see the need for the 'overlay' to exceed the media display size. Silvia: I did forget about the audio use case. For video, I started from the TV background, which is the full-screen condition, where everything is rendered in relation to the video dimensions. I actually think we may need to distinguish two cases: one where the author has created the overlay in relation to the video viewport and wants it scaled with the viewport, and one where the author has created the overlay with stand-alone dimensions and doesn't want any media-related scaling - maybe only media-related positioning. If the position is as an overlay and the overlay is larger, that would result in a need to reflow the layout (not so much the video viewport, but the web page IMHO). Technically, this may create a need to provide an author hint to the Web page when embedding alternate content so as to tell the Web page how to render the content: scale with the media resource, or scale independently. And when scale independently, then a position hint needs to be provided. ISSUE: See also captioning feedback above - how to deal with the mapping of caption dimensions to Web page layout? (2) Philip & Eric's feedback on video resizing: (VP-3) Provide the user with the ability to adjust the size of the time-based media up to the full height or width of the containing viewport, with the ability to preserve aspect ratio and to adjust the size of the playback viewport to avoid cropping, within the scaling limitations imposed by the media itself. (UAAG 2.0 4.9.9) Philip: Can this be made more specific? Is it about being able to scale overlay sign language video tracks, or also about some other kind of track? Eric: Need details about how this is supposed to work, eg. does the video pop up over the page content or does the rest of the page reflow? Is page zoom enough? "with the ability to preserve aspect ratio" - when would the user ever not want to preserve aspect ratio? Silvia: The intent of this criterium as per UAAG 2.0 is "User needs video larger but still needs access to other application (take notes during playback), fullscreen does not allow that. Content should reflow as user adjusts playback viewport." It seems it is about scaling the video by the user beyond its current size, but not to fullscreen. This may also relate to sign language, but it seems not the primary concern of UAAG. We should make it more specific and talk about the intent of the criterium, e.g. the need for a resizing functionality on the video viewport. Sean: I can see the need here, but there isn't any requirement to scale other parts of the flowed document (e.g images) independently, so this seems a bit out on a limb. Theoretically one could use viewport scrolling and scaling of the entire page to achieve this I guess. ISSUE: How to deal with the UAAG requirement on user adjustable video size? (3) Philip's feedback on contrast & brightness control (VP-4) Provide the user with the ability to control the contrast and brightness of the content within the playback viewport. (UAAG 2.0 4.9.11) Philip: Is not currently possible since the <video> can be drawn on a <canvas>, where the colors cannot be altered because of user preference. No UA has such an option for images, why is it a requirement for video? Suggest to remove this requirement. Silvia: should discuss this with the larger media a11y group. I also wonder if the need to change contrast and brightness is attached at too low a level with the video and should just be done for the whole screen, which is already possible through other means. Sean: Brightness and contrast of video are likely to have different characteristics than other content, often for example webcams offer control over this; so I can see the need, agree this should be open for larger discussion. ISSUE: How important is it to separately control contrast and brightness on video? ===== Cheers, Silvia.
Received on Sunday, 4 July 2010 13:09:24 UTC