[Media] MAUR Comments from the BBC

Colleagues:

The following comments were received via the comment mechanism
identified in our document.

Janina

Nigel Megitt writes:
> 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_guides
> /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, 8 December 2014 18:32:24 UTC