W3C

- DRAFT -

HTML Accessibility Task Force Teleconference

20 Nov 2014

See also: IRC log

Attendees

Present
janina, Joanmarie_Diggs, ShaneM, Liam, JF, David_MacDonald, paulc, LJWatson, SteveF, Cynthia_Shelly
Regrets
Chair
Janina
Scribe
JF

Contents


<trackbot> Date: 20 November 2014

Identify Scribe http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Scribe_List

<JF> scribe: JF

No meeting next week--27 November?

JS: Question for the group - suspec that most US based attendees will be eating turkey :-) - do we meet next Thursday?

[crickets]

JS: seems that most agree to miss next week thanks to Thanksgiving

RESOLUTION: no meeting week of Nov. 27th, 2014

Identify Scribe http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Scribe_List

Alt Note Next Steps Discussion; Shane and Liam

<liam> http://lists.w3.org/Archives/Public/public-html-a11y/2014Nov/0021.html

LQ: Shane and Liam met to review and discuss the alt text doc. Agreed on some basic principles
... recapping email message

JF: argues that the guidance is useful for more than just use in HTML

<Zakim> ShaneM, you wanted to mention that steve committed to keep it in sync

SM: spoke with Steve who has agreed to keep the Note and HTML Spec in sync

LW: won't that make things complicated - 2 versions

LQ: agree, but Steve F has agreed to monitor that

SM: in other words this won't be diffiuclt for "us" but it will be for Steve F

PC: There was a Formal Objection that this document contained normative text - Was removed when the content was merged with HTML5
... if you attempt to put this on RC track then it would liikely re-open the FO

LQ: worth noting that point 3 in the email has remaining issues

SF: agree that this should work in browsers. If things don't work in the browser, we need to know that - this is intended to be practical guidance

LQ: agrees
... asks 'what of techniqeus that DON'tWork'?

i.e. @title

SF: understanding that this (in the HTML5 Rec) would also point to WAI Techniques
... need to work out how they work together

JS: believe it is reasonable to note current best practice (i.e. with @title - don't use it)

SF: there is a section that already saya essentially that
... if you have an image with no @alt but does have @title it will throw an error
... the decision was to keep the guidance in the HTML5 spec, as it appears to be referenced frequently

LW: Content authors generally look at WCAG / WAI

LQ: case being made to keep both

SF: There is a reference to WAI guidance in the alt text doc, and in the HTML5 Rec

SM: agrees that the word Alternative does not show up in HTML5 Rec

LQ: seems we have a yes to question 5
... when reading the HTML5 spec, noted that nothing there that tells user-agents what to do with @alt
... (listing numerous questions)
... nothing appears clear in the HTML5 Rec

JS: also the issue of displaying alt text when images are turned off

LQ: (wondered aloud about filing bugs)

SF: there is lots there about how the @alt should be rendered, but it is written in simplistic language for people to understand
... there is a few hard requirements in the Spec, such as @alt and @title cannot be rendered in the same way
... but in general, the way it is left to display is left to the browser - whether that is good or bad that is part of the HTML5 design philosophy

CS: to note that this behaviour stopped in IE7

SF: exactly, but that is also why it was put in there
... however all the other rendering issues are left to the browser
... could provide advice in the HTML5 Rec, but disagree with putting it in the guidance Note
... so if we want to get rendering rules, then HTML5 is the place, not the note

LQ: Item 7 was something that wasn't too clear
... HTML5 seemed clearer (issue around security)
... this was an old phishing technique
... not that 'old"

SM: agree that Notes do not have nomrative requirements in them

so if we find a case where normative specs require more/better/revised content, then we must file a bug against the spec, not the Note

SF: Agree, but believe that we should also keep the 2 documents in sync - if something is added to HTML5, then Steve would file a bug against the Note, for further discussion, etc.

JS: this would also address Paul C's concern - there is no intent of returning this document to normative status
... instead we file bugs directly against the spec(s)

SM: will this cause issues if we add techniques for @longdesc in the Note?

SF: This will clearly not leave everyone happy, but it will be 'legit'
... my goal was also to provide practical advice - pros and cons - and that would remain in the notes
... witness the <details> guidance - which notes that not supported in all browsers and needs polyfills
... so would take same approach with @longdesc

SM: not worried - we will all work together well. Need to address the few editorial changes that need to be made

SF: my view is taht the bulk is good - always room for impovement - but it is workable
... for example, the advice on imagemap is sub-optimal, because the support in browsers isn't good. Browser bugs have been filed
... but AT handling of imagemap is not very good either
... so that would be a good place to start working (filing bugs, tightening Note, etc.)

SM: asking if @longdesc content was ever in the document

SF: no. initially the document started with @alt, but then started to expand to include other ways, but never included @longdesc

JS: will take things as they go - thanks to Liam and Shane to getting this finished

Media Subteam Update -- Janina, John, Shane

JS: subteam is active, and are processing comments on MAUR
... asked COGA TF to review, but all of the other comments have either resolutions or work happening - chance that this will finalize before year end
... Meeting times have switched from 10:00 AM Boston to 4:00 PM Boston
... remains on the Monday

Canvas 2D Update -- Mark

JS: Mark is not here today - will presume work is still happening, but have no specifics

PC: waiting for editors to process a bug that Mark filed
... will follow up, but have not seen any progess over passt 7 days

JS: questons?

Transcript Update -- John

https://www.w3.org/html/wg/wiki/User:JFoliot/Issue194_Recap#Change_Proposals

<ShaneM> scribenick: ShaneM

JF: Various change proposals from June 2012. There was a WBS survey but we didn't do anything with it.
... some different ways to approach transcripts. child element. @kind value of transcripe. @transcript for the video element.
... talked to some people. least favorite was adding @transcript.
... adding transcript value for @kind seems cleanest. clear authoring experience
... some pushback that @kind is for timed documents. but really a transcript is "timed"
... it is inferred though - not explicit.
... Introducing a transcript element had some traction. Sylvia wrote something up. Needs work. Media subteam has it on the todo list once the MAUR is done.
... But this is a big gap in HTML5 - there is no way to associate a transcript to a video.

JS: Why couldn't a transcript have more time information?

JF: There are examples in the wild where transcripts are timestamped.
... in the real world though, in production environments, the definition of a transcript vs. captions vs. described video tend to be a little loose.
... we don't have a hard definition at the W3C.
... we are seeing a thing called "the transcript" as a merger of captioning and described video
... you end up with text blocks split screen with the video. highlights the words as the dialog progresses.
... We should have better definitions of our terms.

DM: I am attracted to the element. People have trouble meeting WCAAG with captioning etc.
... seems useful and clean to have it as a subelement of video.

<Zakim> liam, you wanted to ask relationship to TEI work

<liam> TEI transcriptions of speech - e.g. - http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TS.html

liam: How is this related to the TEI work on transcription?
... there is information that gets encoded via the TEI work.
... the TEI work could end up going inside of a transcription element.
... if would be nice if we coordinate with it.

JS: there is also the Apple usecase. You should be able to get a transcript off line, independent of the video.

JF: Using an element rather than an attribute gives it more flexibility.
... you can always add attributes to elements. You can't add attributes to attributes.
... It is possible to put the transcript element outside of the video element
... should get it on the subteam agenda.
... and this sounds like a new extension spec.

JS: Yes, this is probably the way to proceed.

<JF> scribe: JF

JS: thanks everyoine for attending. Befoe we go, any burning questions/comments?
... no meeting next week, next meeting on Dec. 4th

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2014-11-20 16:59:28 $

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)

Found Scribe: JF
Inferring ScribeNick: JF
Found ScribeNick: ShaneM
Found Scribe: JF
Inferring ScribeNick: JF
ScribeNicks: ShaneM, JF
Default Present: janina, Joanmarie_Diggs, ShaneM, Liam, JF, David_MacDonald, paulc, LJWatson, SteveF, Cynthia_Shelly
Present: janina Joanmarie_Diggs ShaneM Liam JF David_MacDonald paulc LJWatson SteveF Cynthia_Shelly
Found Date: 20 Nov 2014
Guessing minutes URL: http://www.w3.org/2014/11/20-html-a11y-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]