Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wide Review Comment 2017: default background colour #372

Closed
nigelmegitt opened this issue Sep 27, 2017 · 30 comments

Comments

Projects
None yet
3 participants
@nigelmegitt
Copy link
Contributor

commented Sep 27, 2017

Copy/paste from https://lists.w3.org/Archives/Public/public-tt/2017Sep/0080.html - raising as an issue for tracking/disposition purposes.

The default background colour's opacity of 0.8 may cause accessibility problems for some users, especially for bright patterned video behind the text. This can easily be fixed by setting it to 1.

@silviapfeiffer

This comment has been minimized.

Copy link
Member

commented Nov 10, 2017

That is an authoring issue. Through the ::cue and ::cue-region settings, a WebVTT author can change the background color to what is best given the video. We have to choose a default and 80% black is still really really dark without fully obstructing what it going on behind it.
I'd like to close this as "works for me".

@silviapfeiffer

This comment has been minimized.

Copy link
Member

commented Nov 10, 2017

Also please note #395 - I think that addresses this issue also.

@dwsinger

This comment has been minimized.

Copy link

commented Nov 11, 2017

We will be able to author-override, and users can usually user-override in UAs...works as is

@silviapfeiffer

This comment has been minimized.

Copy link
Member

commented Nov 11, 2017

  • user-overwrite is possible through UA settings
  • author-overwrite is possible through CSS ::cue
  • most cases will be readable at 80% black background, very few won't
@silviapfeiffer

This comment has been minimized.

Copy link
Member

commented Nov 11, 2017

@nigelmegitt I'd like to close this issue

@silviapfeiffer silviapfeiffer added WR-pending and removed WR-open labels Nov 11, 2017

@dwsinger

This comment has been minimized.

Copy link

commented Nov 13, 2017

Note we need to document in Wide Review Report that the commenter still disagrees.

@nigelmegitt

This comment has been minimized.

Copy link
Contributor Author

commented Nov 27, 2017

Through the ::cue and ::cue-region settings, a WebVTT author can change the background color to what is best given the video.

I do not agree with this, since there is no control of cue position relative to video, only relative to video viewport.

  • most cases will be readable at 80% black background, very few won't

Those "very few" are what we should be worrying about. The 'nudge' should be in favour of making all cases readable, not most cases. If authors think that 80% will work, they should be able to set that. This is also a possible case for allowing some kind of system setting for default opacity, but in the absence of any explicit setting it should be 100% black if the text colour default is 100% white.

Note we need to document in Wide Review Report that the commenter still disagrees.

This remains true.

@dwsinger

This comment has been minimized.

Copy link

commented Nov 27, 2017

@nigelmegitt

This comment has been minimized.

Copy link
Contributor Author

commented Nov 28, 2017

I would only contemplate it to fix something broken, not for aesthetic reasons.

I'm saying it is broken. The main purpose of this is to make content accessible, and it is in some cases failing when it could easily be fixed. Permitting the user to break it deliberately for their aesthetic reasons, or even permitting default system settings to do so is acceptable.

say in the spec. that authors should consider being explicit with their foreground and background colours

Yes, we should, but that's not enough by itself.

@dwsinger

This comment has been minimized.

Copy link

commented Dec 1, 2017

I think you and I have a different meaning of broken. By broken I mean unimplementable, results in non-interoperable behavior, and the like. Might not be optimally visible by some participants in a minority of cases, which can be addressed by suitable author-choice of over-ride, does not constitute broken to me.

@nigelmegitt

This comment has been minimized.

Copy link
Contributor Author

commented Dec 1, 2017

Yes, I meant broken with respect to the requirement to present text accessibly. If it failed any of your tests I'd also agree it was broken!

@dwsinger

This comment has been minimized.

Copy link

commented Dec 1, 2017

But it's not even broken in presenting text accessibly. Some people when viewing some captions overlaid on some video might have some increased difficulty in reading some of the text; and in the cases where this might happen, both the author (if they are aware that the visual content might increase this risk) or the user (if they are aware that their visual acuity might increase this risk) can supply explicit overriding background colours. This is miles away from broken.

@silviapfeiffer

This comment has been minimized.

Copy link
Member

commented Dec 2, 2017

Let's actually be concrete here.

@nigelmegitt have you looked at what 80% black means? YouTube uses 75% black for their caption background. I've attached a picture below of what that looks like on a relatively white background (that background is rgba(8, 8, 8, 0.75) - the WebVTT one is rgba(0,0,0,0.8) so it's a little darker, but not much). I don't think it has the effect of making the text non-accessible - it's almost the same as black. The small difference from black is making the captions stand our less harshly and gives the human eye a chance to complete the picture behind it. It provides a much easier to view experience than 100% black while still providing full readability. I think we're chasing a red herring.

screen shot 2017-12-02 at 7 39 49 pm

@nigelmegitt

This comment has been minimized.

Copy link
Contributor Author

commented Dec 4, 2017

@silviapfeiffer that image demonstrates the wrong, i.e. easy, end of the difficulty range. I'm looking for examples that demonstrate the point better - they will have high contrast pattern background behind the cue text, so that it interferes with the foreground text pattern. That is the case I have seen before, especially causing trouble for people with additional factors that make reading complex, like dyslexia, Irlen syndrome etc. where reading and tracking can both be affected.

@silviapfeiffer

This comment has been minimized.

Copy link
Member

commented Dec 4, 2017

@nigelmegitt could you share an image that represents the problem you're referring to so we can run an experiment? I'd like to be concrete.

@nigelmegitt

This comment has been minimized.

Copy link
Contributor Author

commented Dec 5, 2017

Yes, will do - that's what I meant by "I'm looking for example", i.e. I am actively looking for examples to post. Waiting for assistance from colleagues, hence the slight delay.

@nigelmegitt

This comment has been minimized.

Copy link
Contributor Author

commented Dec 5, 2017

OK, a slightly contrived example, but one that gets the point across. Just to stress - there are videos that have strong and eye-distracting patterns that have this effect behind the subtitle/caption text.

a = 0.8:

screenshot-2017-12-5 oognnj

a = 1:

screenshot-2017-12-5 oognnj 1

@dwsinger

This comment has been minimized.

Copy link

commented Dec 5, 2017

FWIW, Apple's own DVD Player used to use translucent backgrounds by default, IIRC. See http://osxdaily.com/2014/01/20/change-subtitle-size-mac-os-x/

@dwsinger

This comment has been minimized.

Copy link

commented Dec 5, 2017

I find the contrived example equally easy (or hard) to read, by the way...

@nigelmegitt

This comment has been minimized.

Copy link
Contributor Author

commented Dec 5, 2017

I'm not disputing that lots of systems (even some of the BBC's, grr) use a 0.8 opacity, but that doesn't make it the right choice for the default.

@dwsinger I don't really want to bring your reading ability into this, and this is certainly not the place to be discussing any vision or reading difficulties that any named individuals have; the set of users who would benefit from a default of 1 would really benefit from it whereas everyone else would simply be able to read the text as normal.

@dwsinger

This comment has been minimized.

Copy link

commented Dec 5, 2017

That's what I am saying: Apple DVD Player default was (at least back then) translucent. Apple designers determined that a default of translucent (with user override possible in the system settings) was OK.

Agreed, I'd need to do tests with people with vision problems to be definitive, and what I see is anecdotal/personal, if unconvincing.

@silviapfeiffer

This comment has been minimized.

Copy link
Member

commented Dec 8, 2017

I agree with @dwsinger that even your contrived example will not pose problems for most of the population. The part of the population that will find that hard to read should always have the possibility to use UA settings to override defaults. The 90% preference is on slight translucency, as is exemplified by existing players at BBC, Apple, YouTube and many others - all these systems do it for a reason and have had many years of experience with subtitles. The harsh black only background is a thing of the past.

@nigelmegitt

This comment has been minimized.

Copy link
Contributor Author

commented Dec 11, 2017

The harsh black only background is a thing of the past.

No, it isn't, it is current in the BBC's subtitle guidelines and it is like that for a good reason.

will not pose problems for most of the population

This may be the case, but is irrelevant to the argument I am making, which is that the default should pose no problems for all of the population, and if anyone (including system or platform providers, subtitle authors or users) wants to override that deliberately, that should be their choice, not the other way around.

@dwsinger

This comment has been minimized.

Copy link

commented Dec 11, 2017

@nigelmegitt You yourself say that "lots of systems (even some of the BBC's, grr) use a 0.8 opacity". If we change it now, we have a gratuitous backward incompatibility. If you can find field report of authors or users not understanding this default, or not knowing how to override it if they wish, please point them out. Can you also explain why TTML1 has a default value of "transparent" for the property backgroundcolor?

@dwsinger dwsinger added the WR label Dec 11, 2017

@silviapfeiffer

This comment has been minimized.

Copy link
Member

commented Dec 20, 2017

https://www.webaccessibility.com/best_practices.php?best_practice_id=2374 - the standard in the US is different from what you're suggesting, @nigelmegitt - it merely requires a high contrast between text and background.
The same here: https://www.digitalgov.gov/2014/06/30/508-accessible-videos-how-to-caption-videos/
To be complete, WCAG says nothing about captions and their background color.
Also, like David, I'm curious why TTML1 would have a default background color of "transparent".

I can't see current standards agreeing with your points and we've not had any reports from users that this poses a problem, @nigelmegitt

@nigelmegitt

This comment has been minimized.

Copy link
Contributor Author

commented Feb 14, 2018

Can you also explain why TTML1 has a default value of "transparent" for the property backgroundcolor?

@dwsinger @silviapfeiffer No I can't, however note that backgroundColor applies to many elements, and actually the only one where I would propose a different default is span, so the problem space is different in TTML. TTML also does not specify a default text colour, so implementations are in principle able to select whatever colour works against the background to get adequate contrast.

@nigelmegitt

This comment has been minimized.

Copy link
Contributor Author

commented Feb 14, 2018

The same here: https://www.digitalgov.gov/2014/06/30/508-accessible-videos-how-to-caption-videos/

@silviapfeiffer did you see the part of that page that says:

Instead, use high-contrast color combinations, such as black letters on a solid white background or white letters on a solid black background.

I take "solid black background" to be 100% opacity. Since the default text colour in WebVTT is white, following this US government page's guidance would mean adopting the default that I am proposing.

@dwsinger

This comment has been minimized.

Copy link

commented Feb 19, 2018

OK, this is one that we knew that we were unlikely to reach consensus with the commenter

@silviapfeiffer

This comment has been minimized.

Copy link
Member

commented Feb 25, 2018

In the example at #372 (comment) - what does a user do who wants to actually read the text in the video when it's overlaid with a black box? We satisfy the "high-contrast color combination" requirement sufficiently while at the same time allowing the original content to be available to the viewer.

I'm going to close this issue and agree with @dwsinger that we just have to agree to disagree.

@nigelmegitt

This comment has been minimized.

Copy link
Contributor Author

commented Feb 26, 2018

what does a user do who wants to actually read the text in the video when it's overlaid with a black box?

@silviapfeiffer It's a contrived example to show the effect of a highly patterned background with that opacity, not intended to be a real world one. However I would say that it is really stretching the point to suggest that with an opacity of 0.8 and foreground text the text in the background can somehow be read.

We don't have to continue arguing this with no prospect of agreement, but I note that in closing this you haven't addressed that the US government's guidance appears to support my position.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.