- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 11 Dec 2014 17:10:27 +0000
- To: "public-pfwg-comments@w3.org" <public-pfwg-comments@w3.org>
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 > > >
Received on Thursday, 11 December 2014 17:10:57 UTC