- From: Janina Sajka <janina@rednote.net>
- Date: Sun, 14 Dec 2014 21:11:18 -0500
- To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Forwarding Nigel's response to our edits ... Nigel Megitt writes: > Dear PFWG, > > Thank you for processing our review comments so promptly. I would like to > highlight one edit that appears to be a small misunderstanding of our > comment, albeit with a large impact: > > For VP-5 in section 4.7, our proposal was: > > "If there are several types of overlapping overlays, they should be > positioned as far as possible to avoid obscuring editorially important > parts of the underlying video such as burned in text, mouths etc. Users > typically expect controls to appear at the bottom of the viewport. > Controls should not be prevented from becoming usable due to > repositioning." > > The edited result is: > > > "If there are several types of overlapping overlays, they should be > positioned as far as possible from editorially important content. In > particular, they should avoid obscuring video components such as mouths, > "burned in text" (embedded captions or other annotations in the main video > stream), etc. Users typically expect controls to appear at the bottom of > the viewport. Controls should not be prevented from becoming usable due to > repositioning." > > > > Looking at the first sentence: it was not our intent that the distance > between the rendered position of overlays and the editorially important > content should be maximised. Rather, we meant that, in a constrained > environment in which it is not in general possible in all cases to avoid > obscuring all editorially important parts of the underlying video, all > possible efforts should be made to avoid it. In other words, maximise the > avoidance of obscuring editorially important parts of the video, not > maximise the distance. > > Maximising the distance does have a negative effect in that it means that > the viewer's eyes may need to track a longer distance. Some experiments (I > can't provide a reference) have demonstrated that putting captions as > close as possible to the mouths of the relevant speakers hugely enhances > the experience and helps viewers to feel connected to the editorial > content. > > However advising that the distance should be minimised seems too strong a > statement at the current time. > > Kind regards, > > Nigel > > > > On 04/12/2014 14:59, "Nigel Megitt" <nigel.megitt@bbc.co.uk> wrote: > > >Dear PFWG, > > > >Please see the following review comments from the BBC on the MAUR document > >[1]. > > > >[1] http://w3c.github.io/pfwg/media-accessibility-reqs/ > > > >========== > >General comment: the writers may wish to consider this user experience > >good practices document drafted by BBC: > >http://www.bbc.co.uk/guidelines/futuremedia/accessibility/subtitling_guide > >s > >/online_sub_editorial_guidelines_vs1_1.pdf > >========== > >General comment: The BBC would like to commend the activity of creating > >this very useful document. > >========== > > > > > > > > > > > >Section 3.6 Captioning > > > >========== > >[CC-10] Render a background in a range of colors, supporting a full range > >of opacity levels. > > > >Comment: It enhances readability if the bounding box of the background > >area is not tightly aligned with the text edges, i.e. that some background > >space is visible especially at each end of a line area, for example the > >equivalent of the width of half a space in the selected font. > > > >Proposal: Add a new requirement:- > > > >"Enable the bounding box of the background area to be extended by a > >present distance relative to the foreground text contained within that > >background area." > > > >========== > >[CC-11] Render text in a range of colors. > >NOTE > >The user should have final control over rendering styles like color and > >fonts; e.g., through user preferences. > > > >Comment: A default palette of colours suitable for colour blind users > >should be available to distinguish editorial concepts, such as speakers. > >There are likely to be conflicting requirements between different users > >with differing cognitive conditions to maximise the accessibility of > >content, so full colour customisation should be available. For example > >users with cognitive conditions such as dyslexia (itself an umbrella label > >for a variety of conditions), ADHD and Asperger's may find that viewing > >content that is given a particular colour cast, akin to viewing through > >blue spectacles, say, helps them to read presented text. Whilst further > >research is needed in this area, we should recommend that full colour > >customisation is available. > > > > > >========== > >[CC-12] Enable rendering of text with a thicker outline or a drop shadow > >to allow for better contrast with the background. > > > >Comment: It's correct that this should be enabled however it should not be > >presented as a suitable general alternative to displaying text on a > >non-transparent background, from a legibility perspective. For example, > >white text with drop shadows on a transparent background is not readable > >over a white video, such as footage of snow. > > > > > >Comment: The use of drop shadows increases the sense of 'busyness' that > >can have negative impacts for viewers with some cognitive conditions. > >In general it is preferable not to use drop shadows for the purpose of > >improving text legibility. > > > >========== > >[CC-13] Where a background is used, it is preferable to keep the caption > >background visible even in times where no text is displayed, such that it > >minimizes distraction. However, where captions are infrequent the > >background should be allowed to disappear to enable the user to see as > >much of the underlying video as possible. > > > > > >Comment: this is a cultural/editorial feature that is not accepted > >globally and is likely to result in unnecessarily obscured video. > > > >Proposal 1: Remove this requirement. > > > >Proposal 2 (in case Proposal 1 is rejected): Change 'it is preferable' to > >'it should be possible'. > > > >========== > >[CC-14] Allow the use of mixed display styles‹ e.g., mixing paint-on > >captions with pop-on captions‹ within a single caption cue or in the > >caption stream as a whole. Pop-on captions are usually one or two lines of > >captions that appear on screen and remain visible for one to several > >seconds before they disappear. Paint-on captions are individual characters > >that are "painted on" from left to right, not popped onto the screen all > >at once, and usually are verbatim. Another often-used caption style in > >live captioning is roll-up - here, cue text follows double chevrons > >("greater than" symbols), and are used to indicate different speaker > >identifications. Each sentence "rolls up" to about three lines. The top > >line of the three disappears as a new bottom line is added, allowing the > >continuous rolling up of new lines of captions. > > > > > >Proposal: Add a Note to this section: > > > >"The comprehension and appreciation of captions and subtitles depends on > >how well matched they are to the related video content, editorially. In > >particular the pacing of the content should be reflected in the caption > >text; for example a fast paced drama or is likely to benefit from > >relatively short captions that change more often in comparison to a slow > >paced one. In extremis very fast changing short subtitles do cause > >readability problems because they can prevent viewers from having enough > >attention to consider the video; such extremes should be avoided." > > > >Proposal: Add a Note to this section: > >"When displaying captions in the paint-on style care should be taken to > >ensure that the final words that are displayed are visible for enough time > >that they can be read." > > > >========== > > > >[CC-15] Support positioning such that the lowest line of captions appears > >at least 1/12 of the total screen height above the bottom of the screen, > >when rendered as text in a right-to-left or left-to-right language. > > > > > >Comment: this rule is not global and, in the measurement of 1/12 appears > >to be arbitrary. We agree that a gap does help readability, but propose > >that the specific distance requirement should be removed. > > > >========== > >Comment: The legibility of rendered text depends on the size of the text > >as perceived by the viewer, which is in turn dependent on the display size > >and the distance between display and viewer. I propose adding: > > > >Proposal: Add a new requirement:- > >"Enable responsive choice of text size based on display size and expected > >distance between display and viewer." > > > >========== > > > >Comment: To maximise readability of text it is often beneficial to use a > >font that is optimised for the technology used within the platform and > >display. For example the approach to handling multiple screen sizes in > >Android means that unmodified general purpose fonts such as Helvetica do > >not always render well - in that case the Roboto font may be preferable. > > > >Proposal: Add a new requirement:- > >"Enable fonts optimised for readability on the display in use to be > >preferred where they are available." > >========== > > > > > > > > > >Section 4.7 Requirements on the use of the viewport > > > > > >========== > > > >[VP-5] Captions and subtitles traditionally occupy the lower third of the > >video, where controls are also usually rendered. The user agent must avoid > >overlapping of overlay content and controls on media resources. This must > >also happen if, for example, the controls are only visible on demand. > > > >NOTE > > > >If there are several types of overlapping overlays, the controls should > >stay on the bottom edge of the viewport and the others should be moved > >above this area, all stacked above each other. > > > > > >Comment: It is also important to avoid captions and subtitles overlapping > >editorially important content areas such as mouths, burned in text etc. > > > > > >Comment: We strongly disagree with the stacking approach described in the > >Note. In many cases the best location for the captions/subtitles in this > >scenario is towards the top of the viewport, where it is less likely to > >obscure mouths etc. > > > >Proposal: Remove or edit the note to reflect these comments, for example > >resulting in: > > > >"If there are several types of overlapping overlays, they should be > >positioned as far as possible to avoid obscuring editorially important > >parts of the underlying video such as burned in text, mouths etc. Users > >typically expect controls to appear at the bottom of the viewport. > >Controls should not be prevented from becoming usable due to > >repositioning." > > > >========== > > > > > >Kind regards, > > > >Nigel Megitt > > > >-- > >Nigel Megitt > >Lead Technologist, BBC Technology, Distribution & Archives > >BC4 A3 Broadcast Centre, Media Village, 201 Wood Lane, London W12 7TP > > > > > > > -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net Email: janina@rednote.net Linux Foundation Fellow Executive Chair, Accessibility Workgroup: http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Protocols & Formats http://www.w3.org/wai/pf Indie UI http://www.w3.org/WAI/IndieUI/
Received on Monday, 15 December 2014 02:11:40 UTC