W3C

- DRAFT -

HTML Accessibility Task Force Teleconference

08 Dec 2014

See also: IRC log

Attendees

Present
janina, +1.617.319.aaaa, MarkS, JF, ShaneM
Regrets
Chair
SV_MEETING_CHAIR
Scribe
MarkS

Contents


<janina> Hi, trying to get on

<janina> Hmmm, I have no audio. Will try and try again ...

<janina> trackbot, start meeting

<trackbot> Date: 08 December 2014

Chair+ Janina Sajka

Identify Scribe

<scribe> scribe: MarkS

<ShaneM> http://lists.w3.org/Archives/Public/public-html-a11y/2014Dec/0020.html

BBC Comments

SM: these are great comments
... 3.6, comment about CC-10 about rendering background colors in full range of opacity

[reads]

scribe: enable background area to extend to a preset distance relative to the foreground text...

JF: Overall I agree. sounds overly prescriptive about how much padding should be applied. Don't think we should have a physical measurment

SM: I don't think he is saying that. just that it should be expandable.

JF: who is responsible that the padding exists? author, user agent? both?

SM: i think it would be both

MS: depends on if the controls are rendered by the UA or the author

JS: developers are reminded that readability is enhanced when padding is provided... etc.

JF: this would be a should requirement, right

SM: not specified in the comment

<JF> SHOULD as in RFC 2119, and not a MUST

JF: lets wordsmith it offline.

SM: I'm happy to do that and add it at the end of the CC section
... CC-11, rendering text in a range of colors

[reads]

scribe: recommend that full color customization is available
... I think we are kind of saying that already

JS: I like what he says

SM: I agree. its well written

JF: I believe that the requirement is already there.
... this adds some justification
... but doesn't change the requirement

JS: Maybe add to the explanatory tex.t its very well written. worth capturing

SM: JF thinks that there is already a requirement for this, but I don't think there is. There is a note about this.
... I would probably add this to that note

JS: do we want to elevate this?
... get it out of the note

JF: We can take out "Note" then its just a continuation of the requirement

JS: I'm happy with that

JF: me too
... WebVTT uses standard CSS, which aids this.

SM: CC-12 Thicker outline to allow for better contrast

[reads]

scribe: preferable to not use drop shadows

JS: so it should be user customizable...

SM: which is what I am assuming with use of the word enabled.

JS: Happy to accept this clarification

SM: should clarify that its enable able by user

[agreement]

SM: CC-13 preferable to keep the caption background when frequent captions, but should fade away when captions are infrequent
... proposal, remove this requirement,
... alt proposal, change it is preferable to it should be possible.

[agreement on proposal 2]

SM: I was surprised we had this as a MUST
... CC-14 paint on with pop up captions
... proposal to add a 2 notes to the section:

[reads]

JS: Makes sense to me now that its brought up

SM: final words are available for enough time that they can be read.
... i don't want that to be a note. should be a requirement....

[agreement]

scribe: take the first proposal and make it a note. the 2nd should be included in the base requirement
... this happens to me at the gym all the time due to commercials interrupting the captions
... CC-15, lowest line of captions, 1/12 of the total height above the bottom
... not global, as the measurement appears to be arbitrary. specificity should be removed.

JF: I tend to agree. don't like to be overly prescriptive

SM: I think we should say "a reasonable gap e.g. 1/12th, etc."

[agreement]

JF: Its a hint/suggestion, not a requirement

<ShaneM> crap

<ShaneM> I was being briliant too

<janina> Zakim lost you!

is that how they spell it in England?

SM: the next comment is a proposal for new req.
... my reaction is that this is covered by CC-9

JS: If we want to add any explanatory, just add it there re screen sizes and differences

JF: the end user should be able to adjust this.

JS: Happy to expand the one that is there. don't think we need to add a new one

SM: often beneficial optimized for the technology used on device, e.g. on android, helvetica doesn't render well, so roboto font should be available
... optimized for readability to use font that is preferred when they are available

JF: I think that comment goes back to the comment on styling. To do this, you would load a different stylesheet based on media query.
... author requirement not a user requirement,

SM: I don't see it that way. I want the platform to offer this
... a preferred font, based on what it knows about itself

JS: I think we agree that this should happen and should be supported

SM: CC-11 says user has control. isn't this already covered?

JS: We could expand 9 like we did with 11

SM: to agree with JF, it would be nice to advise authors to do this, not to leave it up to user
... is it valuable for us to say that in the context of CC 11
... or somewhere else?

JF: sounds like a production note to me
... in WCAG we have SC requirements and techniques that allow
... propose a technique
... we don't really have techniques in there (yet)

SM: a note that says while users have control... preferable that authors tune their content to target device as well using media queries, etc.

JS: I'm happy with that

JF: lets wordsmith this. I think we're all on the same track here. just needs to be worded carefully

SM: Can I run a draft by you JF?

JF: yes

SM: 4.7 use of the viewport
... VP-5 lower third, where controls are usually rendered. avoid conflicts, esp if controls available on command.
... i thought that was really strict

JF: its saying we don't want controls to be obscured by captions or vice versa

SM: or you can imagine a situation where those things fight, because there is so much captioning
... also important to avoid conflicts with other essential content
... strongly disagree with the stacking requirement in the note
... our note suggest stacking
... comment is that the best place is likely at the top of the video, where it won't obscure
... suggests edit to suggest this

JF: I say replace the existing note with that

SM: he means away from important parts of underlying video

JS: we should get clarification on that

SM: i lik the phrase "editorially important"

JF: I'm not opposed to this. I think consistency is the important thing
... just saying we want to avoid overlapping content
... maybe some wordsmithing is required here, but this is pretty good start

http://transition.fcc.gov/cgb/dro/cvaa.html

JS: I will be unavailable at this time next week
... still have to review all this wordsmithing and then tweak the responses to commenters. then we are done.
... ok to meet without me?

SM: so we're adding a couple of requirements, these will need to trickle down to the checklist. JF, can you do this>?

JF: I can do that, just let me know when you're done adding those
... there is a must, should, may component that will need to be verified as well

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2014/12/08 22:06:26 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/platform/user/
Found Scribe: MarkS
Inferring ScribeNick: MarkS
Default Present: janina, +1.617.319.aaaa, MarkS, JF
Present: janina +1.617.319.aaaa MarkS JF ShaneM

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 08 Dec 2014
Guessing minutes URL: http://www.w3.org/2014/12/08-html-a11y-media-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]