W3C

HTML WG F2F meeting (room 3A)

04-05 Nov 2010

Agenda

See also: IRC log


Introduction of attendees

We went around the room and everyone introduced themselves.

Review of WG deadlines

<myakura> Timeline to Last Call http://lists.w3.org/Archives/Public/public-html/2010Sep/0074.html

<pimpbot> Title: Timeline to Last Call from Maciej Stachowiak on 2010-09-08 (public-html@w3.org from September 2010) (at lists.w3.org)

<anne> I'm in DAP atm, guess HTML WG is starting at 9AM?

<anne> will probably miss

<anne> the start

See also http://www.w3.org/2010/Talks/1102-html-plh/#%284%29

<pimpbot> Title: HTML Working Group Update (at www.w3.org)

anne: We started at about 8:45am

<anne> ah ok

Current statistics on bugs are available at http://intertwingly.net/tmp/wgstatus.html

<pimpbot> Title: HTML WG Status (at intertwingly.net)

35 pre-Last Call bugs are still open

The Editors have until Dec 8 to resolve these bugs

We need especially to make progress on the Accessibility issues: Media Accessibility and Canvan Accessibility

Working Group charter

The Chairs and Team are discussing how to handle our charter that expires on Dec 31

Current charter: http://www.w3.org/2007/03/HTML-WG-charter.html

<pimpbot> Title: HTML Working Group (at www.w3.org)

We can either "extend" the date on the charter without changing the "scope" or do a major charter revision that would require AC review and rejoining the WG.

The Chairs and Team recommend that we "extend" the date on the charter.

plh: Extend by one year, get to LC by May + text in the covering note suggesting the WG can look at Requirements for future work starting in June 2011

Discussion topics for F2F meeting

Suggestions by email:

Kris's suggestion in http://lists.w3.org/Archives/Public/public-html/2010Nov/0045.html

<pimpbot> Title: Potential HTML WG TPAC Testing Discussion Items from Kris Krueger on 2010-11-03 (public-html@w3.org from November 2010) (at lists.w3.org)

Media accessibility in: http://lists.w3.org/Archives/Public/public-html/2010Nov/0020.html

<pimpbot> Title: Re: Media Accessibility Discussion (Was RE: Adopting the media accessibility requirements)) from Janina Sajka on 2010-11-02 (public-html@w3.org from November 2010) (at lists.w3.org)

Frank's second suggestion is A11Y bugs

<plh> Mark Vickers, Comcast

1. Testing

2. Media Accessibiloity

3. Accessibility bugs

4. Timed tracks issues (part of Media accessibility or separately)

5. IETF area director and IANA issues (preferably after coffee today)

6. Link relationships (possibly as part of #5)

7. How to participate in the Testing TF - Testing TF 101

8. How to participate in the A11Y TF

9. Applicable specification related to ISSUE-140 + vendor extension syntax

10. epub possible impacts on HTML

11. Considerations for HTML as a long term storage format

12. Guidelines for restricted devices

13.Canvas accessibility

14. Access to External video content

- how to discover locally recorded videos?

<MikeSmith> DLNA

<pimpbot> Title: Digital Living Network Alliance - Wikipedia, the free encyclopedia (at en.wikipedia.org)

Looking for an API to do this discovery.

Want to find the video elements on a page as well.

15. New features: challenges and opportunities for accessibility

16. Testing: harness, reference tests, scripting of tests

17. Digital Rights Management (fun topic)

<mjs> open and raised issues: http://www.w3.org/html/wg/tracker/issues/raised http://www.w3.org/html/wg/tracker/issues/open

<pimpbot> Title: Raised Issues - HTML Weekly Tracker (at www.w3.org)

18. Review of outstanding issues (other than those under other topics)

<krisk> This would be good to talk the test harness, especially with folks from nokia and tv based devices

Review of Raised issues:

Issue-120?

<trackbot> ISSUE-120 -- Use of prefixes is too complicated for a Web technology -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/120

<pimpbot> Title: ISSUE-120: Use of prefixes is too complicated for a Web technology - HTML Weekly Tracker (at www.w3.org)

No one expressed interest in -120

Issue-124?

<trackbot> ISSUE-124 -- nofollow/noreferrer not allowed on <link> -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/124

<pimpbot> Title: ISSUE-124: nofollow/noreferrer not allowed on - HTML Weekly Tracker (at www.w3.org)

We should do this in the Link Relationships session.

Issue-125?

<trackbot> ISSUE-125 -- Requirement to break RFC 2616 compliance with respect to single quotes not needed for legacy content -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/125

<pimpbot> Title: ISSUE-125: Requirement to break RFC 2616 compliance with respect to single quotes not needed for legacy content - HTML Weekly Tracker (at www.w3.org)

issue-126?

<trackbot> ISSUE-126 -- Requirement to break RFC 2616 compliance with respect to backslashes not needed for legacy content -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/126

<pimpbot> Title: ISSUE-126: Requirement to break RFC 2616 compliance with respect to backslashes not needed for legacy content - HTML Weekly Tracker (at www.w3.org)

No one was interested in discussing -125 or -126

Issue-127?

<trackbot> ISSUE-127 -- Simplify characterization of link types -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/127

<pimpbot> Title: ISSUE-127: Simplify characterization of link types - HTML Weekly Tracker (at www.w3.org)

We will add -127 to the Link Relations topic

Issue-129?

<trackbot> ISSUE-129 -- replace or modify the ARIA section of the HTML5 spec -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/129

<pimpbot> Title: ISSUE-129: replace or modify the ARIA section of the HTML5 spec - HTML Weekly Tracker (at www.w3.org)

Who do we need to discuss this?

<Joshue> One point of order, is there a call facility for this meeting, so others can dial in?

Can we do this without Steve Faulkner? Could we do this on Friday?

At least one person said yes to discuss -129 + accessibility api mappings

Might be hard then.

ISSUE-130?

<trackbot> ISSUE-130 -- allow tables to be used for layout purposes -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/130

<pimpbot> Title: ISSUE-130: allow tables to be used for layout purposes - HTML Weekly Tracker (at www.w3.org)

Would a session on making a list of arguments on either side would be useful?

no volunteers for -130.

Issue-131?

<trackbot> ISSUE-131 -- Should we add a caret location API to canvas, or is the focus API sufficient? -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/131

<pimpbot> Title: ISSUE-131: Should we add a caret location API to canvas, or is the focus API sufficient? - HTML Weekly Tracker (at www.w3.org)

This would be part of the Canvas Accessibility discussion.

ISSUE-132?

<trackbot> ISSUE-132 -- Drop the color input type -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/132

<pimpbot> Title: ISSUE-132: Drop the color input type - HTML Weekly Tracker (at www.w3.org)

Anyone interested in this topic?

No hands for -132.

ISSUE-133?

<trackbot> ISSUE-133 -- Add a modal attribute to html5 to indicate a modal segment of the DOM (modal dialog) -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/133

<pimpbot> Title: ISSUE-133: Add a modal attribute to html5 to indicate a modal segment of the DOM (modal dialog) - HTML Weekly Tracker (at www.w3.org)

Anyone interested in -133?

Place this in the General Accessibility topic.

ISSUE-134?

<trackbot> ISSUE-134 -- Provide tablist and tab states for menu and command elements respectively -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/134

<pimpbot> Title: ISSUE-134: Provide tablist and tab states for menu and command elements respectively - HTML Weekly Tracker (at www.w3.org)

<Joshue> +q

<pimpbot> bugmail: [Bug 11215] New: What about folders? On OSX for example some "files" are actually folders. There should be a way to drag in folders too. <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2010Nov/0184.html>

Add -134 to the Accessibility Bugs topic

Issue-135?

<trackbot> ISSUE-135 -- put back direct link to the W3C version of the canvas 2d context spec -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/135

<pimpbot> Title: ISSUE-135: put back direct link to the W3C version of the canvas 2d context spec - HTML Weekly Tracker (at www.w3.org)

No serious volunteers to discuss -135.

Issue-136?

<trackbot> ISSUE-136 -- would the <small> element be better handled in CSS? -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/136

<pimpbot> Title: ISSUE-136: would the element be better handled in CSS? - HTML Weekly Tracker (at www.w3.org)

Maybe Henri and Cynthia could do this over coffee?

There seem to be three people to discuss -136 but some suggested this is a lower priority

ISSUE-137?

<trackbot> ISSUE-137 -- Since Javascript does not support mode specifiers inside the regular expression, there is no simple way of matching a single word case-insensitively besides turning into [Ww][Oo][Rr][Dd] -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/137

<pimpbot> Title: ISSUE-137: Since Javascript does not support mode specifiers inside the regular expression, there is no simple way of matching a single word case-insensitively besides turning into [Ww][Oo][Rr][Dd] - HTML Weekly Tracker (at www.w3.org)

No volunteers to discuss -137.

ISSUE-138?

<trackbot> ISSUE-138 -- "mutate action" for issueing a GET request is misleading -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/138

<pimpbot> Title: ISSUE-138: "mutate action" for issueing a GET request is misleading - HTML Weekly Tracker (at www.w3.org)

Suggestion that this is editorial along with -139.

ISSUE-139?

<trackbot> ISSUE-139 -- HTML5 spec mentions Microdata in Acknowledgements -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/139

<pimpbot> Title: ISSUE-139: HTML5 spec mentions Microdata in Acknowledgements - HTML Weekly Tracker (at www.w3.org)

Editorial issue - no need to discuss -139.

ISSUE-140?

<trackbot> ISSUE-140 -- clarify the applicability of the term "conforming document" in cases where "applicable specifications" had been used to augment or change the base HTML5 specification -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/140

<pimpbot> Title: ISSUE-140: clarify the applicability of the term "conforming document" in cases where "applicable specifications" had been used to augment or change the base HTML5 specification - HTML Weekly Tracker (at www.w3.org)

Already on the list of suggested topics.

Reviewing the Open issues:

ISSUE-9?

<trackbot> ISSUE-9 -- how accessibility works for <video> is unclear -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/9

<pimpbot> Title: ISSUE-9: how accessibility works for is unclear - HTML Weekly Tracker (at www.w3.org)

We have a session on media accessibility.

ISSUE-27?

<trackbot> ISSUE-27 -- @rel value ownership, registry consideration -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/27

<pimpbot> Title: ISSUE-27: @rel value ownership, registry consideration - HTML Weekly Tracker (at www.w3.org)

That belongs in the Link Relation session.

ISSUE-31?

<trackbot> ISSUE-31 -- Author conformance requirements for the alt attribute on images -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/31

<pimpbot> Title: ISSUE-31: Author conformance requirements for the alt attribute on images - HTML Weekly Tracker (at www.w3.org)

ISSUE-80?

<trackbot> ISSUE-80 -- document conformance and device dependent display of title attribute content -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/80

<pimpbot> Title: ISSUE-80: document conformance and device dependent display of title attribute content - HTML Weekly Tracker (at www.w3.org)

-31 and -80 overlap and have lots of change proposals. Chairs think we need to either prune the proposals or do a survey with multiple questions.

Let's make this a separate session. Maybe part of Accessibility Issue but it might be too big.

We might try to spend time prioritizing the a11y issues.

ISSUE-56?

<trackbot> ISSUE-56 -- Bring "URLs" section/definition and IRI specification in alignment. -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/56

<pimpbot> Title: ISSUE-56: Bring "URLs" section/definition and IRI specification in alignment. - HTML Weekly Tracker (at www.w3.org)

We 3 different proposals submitted.

Let's add -56 to the IETF topic (after coffee today).

ACTION-118?

<trackbot> ACTION-118 -- Dan Connolly to reformat the document on URLs in HTML 5 as an Internet Draft -- due 2009-05-07 -- CLOSED

<trackbot> http://www.w3.org/html/wg/tracker/actions/118

<pimpbot> Title: ACTION-118: Reformat the document on URLs in HTML 5 as an Internet Draft - HTML Weekly Tracker (at www.w3.org)

Add this to Link Relation topic.

ISSUE-118?

<trackbot> ISSUE-118 -- Specification breaks semantics of existing link relations "index" and "first" -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/118

<pimpbot> Title: ISSUE-118: Specification breaks semantics of existing link relations "index" and "first" - HTML Weekly Tracker (at www.w3.org)

Ignore the ACTION mention above.

ISSUE-119?

<trackbot> ISSUE-119 -- Certain relationships take on a special meaning when repeated; other solutions may be cleaner -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/119

<pimpbot> Title: ISSUE-119: Certain relationships take on a special meaning when repeated; other solutions may be cleaner - HTML Weekly Tracker (at www.w3.org)

Also related to the Link Relation topic.

The Link Relation topic is getting quite big.

ISSUE-122?

<trackbot> ISSUE-122 -- alt text and description for Lady of Shalott example -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/122

<pimpbot> Title: ISSUE-122: alt text and description for Lady of Shalott example - HTML Weekly Tracker (at www.w3.org)

Part of Alt text topic.

ISSUE-128?

<trackbot> ISSUE-128 -- Authors should be able to use <figure> where <img> can be used -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/128

<pimpbot> Title: ISSUE-128: Authors should be able to use where can be used - HTML Weekly Tracker (at www.w3.org)

Any interest?

<Joshue> Is ISSUE 122, the @alt mood bug issue?

None heard.

Suggested topics:

1. Testing TF

2. Media Accessibility

3. General A11Y issues

4. Other uses of Timed Tracks

5. IETF IANA discussion

6. Link Relations

7. How to participate in Testing TF

8. How to participate in A11Y TF

9. Applicable specifications issue-140

10. Epub

11. HTML as long term storage (possible part of 5)

12. Limited devices and HTML

13. Canvas Accessibility

14. External video control on LAN

15. Test harness

16. Alt (issues-31, -80 and -122)

17. New features - challenges for accesibility

18. DRM

19. ARIA and API

20. <small> element (issue-136)

Scheduling: Topic 2 suggested time is 2pm

Topic 9 on Friday (Adrian is at Geo Location today)

Topic 5 is after coffee Thu morning.

Should topic 20 be generalized into what is valid?

What is the bug that relates to valid or not?

<hsivonen> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10838

<pimpbot> 1110838: kennyluck, P3, RESOLVED WONTFIX, 13Make <u> conforming.

<Zakim> oedipus, you wanted to ask if can we try and group the accessibility topics to maximize A11y TF participation

<oedipus> can we try and group the accessibility topics to maximize A11y TF participation -- members are on "stand-by" for notice of when need to be available

<Julian> dbaron, still working on it

21. HTML as a syndication format

<anne> dbaron, agenda will be on the wiki after we figured it out

<Julian> "in syndication formats"?

<anne> (not sure which wiki, mjs didn't say)

<MikeSmith> I should rightly raise my hand for everything

<MikeSmith> every topic

<oedipus> dbaron, there is an HTML5 "breakout room" in #html-wg2

<MikeSmith> but I'm only raising my hand on stuff that I'm actually prepared to talk about myself

<oedipus> kliehm, there were intros, but not minuted -- i'm playing "fly-on-the-wall" courtesy of MikeTMSmith and skype

Votes of interest:

Item 1: 7

Item 2a: 9+

Item 2b: 12+

Item 4: 7

Item 5: 8

<Marco_Ranon> +1 to 2b (I'll be there after the break)

Item 6: 4

Item 7 - fold into item 1

item 8 - fold into 2b

Item 9: 3

item 10: 9

item 11: fold into item 5

item 12: 7

item 13: 7

item 14: 2

item 15 - fold into item 1

item 16: fold into 2b

item 17: 5

item 18: 3

Item 19: 7

item 20: 4

Item 21: 1

<anne> https://spreadsheets.google.com/ccc?key=0Apvkq1IRZaQVdFItdlZoYkMxaV9HN21jQ1BHRUl0X1E&hl=en&authkey=CJmm740B

<oedipus> anne, is that URI for the agenda?

<oedipus> would it be possible to use the wiki to post the agenda -- google spreadsheets aren't accessible

<Lachy> Is there going to be telcon available for this meeting later, so I could call in for specific topics?

<MikeSmith> paulc, not oedipus on the queue

<MikeSmith> *note

<Zakim> oedipus, you wanted to ask if we can group the accessibility topics to maximize A11y TF participation -- members are on "stand-by" for notice of when need to be available

<oedipus> after agenda is set, could it be ported to the wiki, as google spreadsheets aren't acccessible

<anne> plh, really?

<anne> hmm

<anne> it's open

<anne> try again

<kliehm> I'm editing a wiki page right now to transfer the spreadsheet contents

<anne> made it public to the web

<plh> ah, I found out that's because I reject google cookies

<pimpbot> bugmail: [Bug 11213] here is coment <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2010Nov/0185.html>

<pimpbot> planet: HTML5 Testing <11http://www.w3.org/QA/2010/11/html5_testing.html>

We are breaking for coffee until 11:00 local time.

There will be two sessions at 11:00am

#html-wg will be doing General Accessibility topic

#html-wg2 will be doing IETF (item 5)

<kliehm> Agenda for today and tomorrow: http://www.w3.org/html/wg/wiki/TPAC_2010_Agenda

<pimpbot> Title: TPAC 2010 Agenda - HTML WG Wiki (at www.w3.org)

<oedipus> kliehm, thank you VERY much

<oedipus> kliehm, does room 3A accord with #html-wg and 3B with #html-wg2?

<plh> yes

<pimpbot> Title: HTML WG F2F meeting (room 3A) -- 04 Nov 2010 (at www.w3.org)

<pimpbot> Title: HTML WG F2F meeting (room 3A) -- 04 Nov 2010 (at www.w3.org)

<mjs> oedipus, +1

<mjs> IETF topic about to start in room 3b / #html-wg2

<pimpbot> bugmail: [Bug 11212] Make all the radio button group suffering from being missing (instead of only radio's with the required attribute) <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2010Nov/0189.html> 4** [Bug 11206] Presentational tag [font,b,u,i] CANNOT be removed for many reasons. Three scenarios very good scenarios: 1. HTML5 Mobile sites with BlackBerry8xxx and 9xxx support 2. HTML5 Emails 3. Legacy content 4. Injected legacy content vi

<eliot> ScribeNick: eliot

general accessibility

<oedipus> thanks to kleihm for emailing agenda to public-html-a11y -- notified silvia directly about general and media discussions

<Stevef> is there no dial in for the meetings?

this isthe general a11y session

Topic list as first item

<Stevef> MichaelC: I am on the phone

brief overview of how to participate?

a pitch for how to get people

janina: that would be helpful
...

<kliehm> ISSUE-133?

<trackbot> ISSUE-133 -- Add a modal attribute to html5 to indicate a modal segment of the DOM (modal dialog) -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/133

<pimpbot> Title: ISSUE-133: Add a modal attribute to html5 to indicate a modal segment of the DOM (modal dialog) - HTML Weekly Tracker (at www.w3.org)

Issue-133?

<trackbot> ISSUE-133 -- Add a modal attribute to html5 to indicate a modal segment of the DOM (modal dialog) -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/133

Issue-134?

<trackbot> ISSUE-134 -- Provide tablist and tab states for menu and command elements respectively -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/134

<pimpbot> Title: ISSUE-134: Provide tablist and tab states for menu and command elements respectively - HTML Weekly Tracker (at www.w3.org)

CYS: can we look at the bug list to see if there are any more?

<oedipus> longdesc

<oedipus> summary for table

cys: did alt text get rolled into this?

Issue-122?

<trackbot> ISSUE-122 -- alt text and description for Lady of Shalott example -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/122

<pimpbot> Title: ISSUE-122: alt text and description for Lady of Shalott example - HTML Weekly Tracker (at www.w3.org)

<oedipus> HTML5 lacks a verbose description mechanism: http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs

<pimpbot> Title: Verbose desc reqs - HTML accessibility task force Wiki (at www.w3.org)

assume alt is folded into this

ssue-31?

issue-31?

<trackbot> ISSUE-31 -- Author conformance requirements for the alt attribute on images -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/31

<pimpbot> Title: ISSUE-31: Author conformance requirements for the alt attribute on images - HTML Weekly Tracker (at www.w3.org)

issue-80?

<trackbot> ISSUE-80 -- document conformance and device dependent display of title attribute content -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/80

<oedipus> 2 high topic issues: verbose descriptor and summary for TABLE

<pimpbot> Title: ISSUE-80: document conformance and device dependent display of title attribute content - HTML Weekly Tracker (at www.w3.org)

issue-122?

<trackbot> ISSUE-122 -- alt text and description for Lady of Shalott example -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/122

<pimpbot> Title: ISSUE-122: alt text and description for Lady of Shalott example - HTML Weekly Tracker (at www.w3.org)

janina

<oedipus> 2 high topic issues: verbose descriptor and summary for TABLE

scribe: how to participate
... alt
... the other one.
... general overview of bugs
... can people suggest specific ones?

<oedipus> 2 high topic issues: verbose descriptor and summary for TABLE

How to be a part

if you're in html, you qualify

<paulc> Issue to be covered -133, -134, and alt (-31, -80, -122)

html mapping team

cys: how AT gets stuff

<oedipus> HTML WG Bug 10853: HTML5 lacks a verbose description mechanism http://www.w3.org/Bugs/Public/show_bug.cgi?id=10853

<pimpbot> 11http://www.w3.org/Bugs/Public/show_bug.cgi?id=10853 oedipus, P2, RESOLVED NEEDSINFO, 13HTML5 lacks a verbose description mechanism

<pimpbot> 1110853: oedipus, P2, RESOLVED NEEDSINFO, 13HTML5 lacks a verbose description mechanism

cys: subteam on canvas a11y
... subteam for bug triage w/ respect to a11y
... general discussion of issues around a11y, right before html wg call

<oedipus> HTML5 Accessibility Task Force wiki: http://www.w3.org/WAI/PF/html/wiki

<pimpbot> Title: HTML accessibility task force Wiki (at www.w3.org)

cys: wd very much like to have ppl involved in those areas
... need more people w/ less experience w/ a11y and who can provide insight
... and who can bridge between q11yTF and the broader wg

janina: thanks, cynthia
... to summarize: what works for the a11y TF is to set up subteams
... there are a lot of topics around a11y and html5
... subteams focus on particular aspects

<oedipus> HTML5 Accessibility Task Force wiki: http://www.w3.org/WAI/PF/html/wiki/Canvas

<pimpbot> Title: Canvas - HTML accessibility task force Wiki (at www.w3.org)

janina: One key diff between a11y TF and htmlwg

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Media_Sub-Group

<pimpbot> Title: Media Sub-Group - HTML accessibility task force Wiki (at www.w3.org)

<MikeSmith> MikeSmith: agreed with Janina that the a11y subteams have been effective

janina: is that the TF uses teleconferences. not essential to participate in the teleconference
... work via wiki and other means
... work hard to find good times, though it's sometimes difficult

<oedipus> note that bugs are marked a11y for accessibility / a11ytf for bugs HTML A11y TF has identified as pertaining to a11y

janina: strong core group of a11y people and developers
... many track the activity via mail and other mechanisms
... questions?

Alt

<oedipus> http://lists.w3.org/archives/public/public-html-a11y

janina: recommendations forward from the a11y TF some time ago

<pimpbot> Title: public-html-a11y@w3.org Mail Archives (at lists.w3.org)

Josh: question around Alt, mood, graphics: related to Lady of Shallott?

cys: steve Faulkner wrote a document

josh: many contributed to that

<myakura> http://dev.w3.org/html5/alt-techniques/

<pimpbot> Title: HTML5: Techniques for providing useful text alternatives (at dev.w3.org)

cys: there's that document published, but the adviced offereds isn't consistent with advice offered in the html spec
... anyone know the status of the issue for that?

<oedipus> SteveF, could you update us on the alt techs document?

<Stevef> yes

<MikeSmith> issue-31?

<trackbot> ISSUE-31 -- Author conformance requirements for the alt attribute on images -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/31

<pimpbot> Title: ISSUE-31: Author conformance requirements for the alt attribute on images - HTML Weekly Tracker (at www.w3.org)

<MikeSmith> issue-80?

<trackbot> ISSUE-80 -- document conformance and device dependent display of title attribute content -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/80

<pimpbot> Title: ISSUE-80: document conformance and device dependent display of title attribute content - HTML Weekly Tracker (at www.w3.org)

josh: did we not recommend that document be absorbed?

cys: we wanted it separate
... remove anything in the spec itself

<oedipus> note: SteveF is on the phone and is willing to update on alt techs doc

<paulc> http://dev.w3.org/html5/status/issue-status.html#ISSUE-031

<pimpbot> Title: Change Proposal Status (at dev.w3.org)

janina: gen; principle we agreed...we wanted documents about, best practices, etc. to be outside of the spec

paul: pointer to the status page
... need to eliminate change proposals
... in order to make a recommendation, recording rationale for recomendations

<pimpbot> bugmail: "[Bug 11212] Make all the radio button group suffering from being missing (instead of only radio's with the required attribute)" (2 messages in thread) <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2010Nov/0190.html>

<oedipus> 1. http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091209

<pimpbot> Title: ChangeProposals/ImgElement20091209 - HTML WG Wiki (at www.w3.org)

<oedipus> 2. http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100706

<pimpbot> Title: ChangeProposals/ImgElement20100706 - HTML WG Wiki (at www.w3.org)

<oedipus> 3. http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100707

<pimpbot> Title: ChangeProposals/ImgElement20100707 - HTML WG Wiki (at www.w3.org)

<oedipus> 4. http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126

<pimpbot> Title: ChangeProposals/ImgElement20090126 - HTML WG Wiki (at www.w3.org)

<oedipus> 5. http://lists.w3.org/Archives/Public/public-html/2010Jul/0050.html

<pimpbot> Title: Change proposals for ISSUE-31 and ISSUE-80 from Ian Hickson on 2010-07-15 (public-html@w3.org from July 2010) (at lists.w3.org)

<oedipus> 6. http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100504

<pimpbot> Title: ChangeProposals/ImgElement20100504 - HTML WG Wiki (at www.w3.org)

<oedipus> 7. http://www.w3.org/html/wg/wiki/index.php?title=ChangeProposals/ImgElement20100510

<pimpbot> Title: ChangeProposals/ImgElement20100510 - HTML WG Wiki (at www.w3.org)

<oedipus> what about the WAI CG/PF recommendations?

<oedipus> need to discuss IMG and FIGURE

cyn: let's talk about conformance

<Joshue> Scribe: Joshue

Cyns: Lets look at 2

http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100706

<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100706

<pimpbot> Title: ChangeProposals/ImgElement20100706 - HTML WG Wiki (at www.w3.org)

<pimpbot> Title: ChangeProposals/ImgElement20100706 - HTML WG Wiki (at www.w3.org)

Review of the change proposal.

<myakura> ScribeNick: Joshue

<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100706#Details

<pimpbot> Title: ChangeProposals/ImgElement20100706 - HTML WG Wiki (at www.w3.org)

<oedipus> suggested text: "conformance checker must report the lack of an alt attribute as an error unless one of the conditions listed below applies:

<oedipus> * the <img> element is located within a <figure> element that has a non-empty <figcaption> element, or

<oedipus> * a non-empty aria-labelledby attribute is present. "

GJR: This is from Lauras change proposal.

Cyns: That sounds like the PF consensus.

JS: Yes

<oedipus> WAI CG Consensus Resolution on Text Alternatives in HTML5: http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

<pimpbot> Title: WAI CG Consensus Resolutions on Text alternatives in HTML 5 (at www.w3.org)

Lauras Second proposal http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100707

<pimpbot> Title: ChangeProposals/ImgElement20100707 - HTML WG Wiki (at www.w3.org)

Cyns; Lets look at both.

<oedipus> Replace the Current Text: A conformance checker must report the lack of an alt attribute as an error unless one of the conditions listed below applies: * The title attribute is present and has a non-empty value (as described above). * The img element is in a figure element that contains a figcaption element that contains content other than inter-element whitespace (as...

<oedipus> ...described above). * The conformance checker has been configured to assume that the document is an e-mail or document intended for a specific person who is known to be able to view images. * The document has a meta element with a name attribute whose value is an ASCII case-insensitive match for the string "generator". (This case does not represent a case where the document...

<oedipus> ...is conforming, only that the generator could not determine appropriate alternative text — validators are required to not show an error in this case to discourage markup generators from including bogus alternative text purely in an attempt to silence validators.) [edit] With Suggested Text A conformance checker must report the lack of an alt attribute as an error unless the <img>...

<oedipus> ...element is located within a <figure> element that has a non-empty <figcaption> element.

<oedipus> Replace the Current Text: A conformance checker must report the lack of an alt attribute as an error unless one of the conditions listed below applies: * The title attribute is present and has a non-empty value (as described above). * The img element is in a figure element that contains a figcaption element that contains content other than inter-element whitespace (as described above). *...

<oedipus> ...The conformance checker has been configured to assume that the document is an e-mail or document intended for a specific person who is known to be able to view images. * The document has a meta element with a name attribute whose value is an ASCII case-insensitive match for the string "generator". (This case does not represent a case where the document is conforming, only that the...

<oedipus> ...generator could not determine appropriate alternative text — validators are required to not show an error in this case to discourage markup generators from including bogus alternative text purely in an attempt to silence validators.) Suggested Text A conformance checker must report the lack of an alt attribute as an error unless the <img> element is located within a <figure> element...

<eliot> Proposal from the editor: 5. http://lists.w3.org/Archives/Public/public-html/2010Jul/0050.html

<pimpbot> Title: Change proposals for ISSUE-31 and ISSUE-80 from Ian Hickson on 2010-07-15 (public-html@w3.org from July 2010) (at lists.w3.org)

<oedipus> ...that has a non-empty <figcaption> element.

<oedipus> WAI CG Consensus Resolution on Text Alternatives in HTML5: http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

<pimpbot> Title: WAI CG Consensus Resolutions on Text alternatives in HTML 5 (at www.w3.org)

<eliot> ...suggests no change. Should be surveyed. This does not overlap with others

Cyns; This is one of the proposals that needs to be surveyed

JS: Ok, we are giving the chairs some guideance.

Cyns: This suggestion sounds like HTML4.

Cyns; I have a prefer for role="presentaion" etc to be valid and it would be invalid to not have some semantic representation a la WAI guidance , http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

<pimpbot> Title: WAI CG Consensus Resolutions on Text alternatives in HTML 5 (at www.w3.org)

<oedipus> GJR objects to requiring a non-native labelledby -- will aria-labelledby be supported by UAs without ATs to use CSS to visually bind description with image

Cyns: Any one of the 3 works, or leave the spec as it is.

<oedipus> JOC: what about FIGURE and FIGCAPTION?

SF: What about what was agreed in the WAI guidance.

Cys: The most flexible is only @alt like HTML 4 or do nothing..

+q

AO: The problem with conformance checks is that in a DTD there is a lack of specificity, are elements implied or explicit.

MS: We don't want people using DTDs.

<Zakim> oedipus, you wanted to ask if survey would be a negative survey such as those recently used -- i.e. you can't comment if you agree with someone but only if one has original comment

<oedipus> GJR objects to requiring a non-native labelledby -- will aria-labelledby be supported by UAs without ATs to use CSS to visually bind description with image

GJR: We have talked about surveys, they have been of a negative form generally.

Cyns: I think there is API mapping, that labelledby would fullfill the name role in the platform API, is that what you mean?

GJR: Its important that it is native, so CSS etc can be applied.

Cyns; Can that not be done with labelledby @?

SF: You can do that.

GJR: Ok

<MikeSmith> s/Cyns;/Cyns:/

JS: We recommend that the chairs survey on three of these.

<oedipus> GJR: want to ensure that won't need AT to reap benefits of aria-* attribues and features

Cyns: can someone take an action item to conflate 2 and 4?

PC: So GJR, do you want to restate your question?

GJR: The surveys are negative, so only if your comment is originally negative can you contribute.

JS: Why?

GJR: If you can only add a new comment in this way, it is not truly reflective of positive support.

+1 to GJR, he has a good point.

PC: The intent is to find a way of generating the least dissent.

general discussion on w3c survey methodologies

PC: Comments noted.

JS: This topic does need a broader discussion.

<oedipus> GJR: objects to surveys being cited as having "low participation" when rules covering survey are so stringent

<oedipus> can someone put the combined proposals into IRC?

<eliot> ACTION: janina To: Janina to ask Laura to combine working from proposal items 2 and 4 [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action01]

<trackbot> Created ACTION-191 - To: Janina to ask Laura to combine working from proposal items 2 and 4 [on Janina Sajka - due 2010-11-11].

<scribe> Scribe: Eliot

<oedipus> people need guidance on how to use FIGURE and FIGCAPTION as well as IMG and @alt @labelledby, IMG may not always in FIGURE

janina: does the group wish to record a consensus or candidate?

cys: combine 2&4

<oedipus> negative 1

janina: opposition? discussion?

<oedipus> people need guidance on how to use FIGURE and FIGCAPTION as well as IMG and @alt @labelledby, IMG may not always in FIGURE

jan: 2&4 are not about guidance
... should we survey about guidance?

<Joshue> @GJR look at http://dev.w3.org/html5/status/issue-status.html#ISSUE-031

<pimpbot> Joshue: Huh?

<Joshue> #2 http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100706

<pimpbot> Title: ChangeProposals/ImgElement20100706 - HTML WG Wiki (at www.w3.org)

<Joshue> #4 http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126

<pimpbot> Title: ChangeProposals/ImgElement20090126 - HTML WG Wiki (at www.w3.org)

cys: 2&4 are the widest array, the widest way to provide text alternatives
... the other two are the do-nothing proposal and the last is the html4 proposal

stevef: do we ned to disambiguate 2&4?

cys: want machine checking to be as close to author checking
... o we need to structure the proposal with two sections? Machine and author?

<oedipus> figcaption may not provide an adequate alt text -- if one looks at books or magazines, the captions are not very explicative if one can't see the captioned image

josh: need to build a solid foundation

paul: might want to go broader
... move on to something else

cys: impact on the change proposal

four porposals with guidance implications

<Joshue> Scribe: Joshue

Eliot: Here is the list again. http://dev.w3.org/html5/status/issue-status.html#ISSUE-031

<pimpbot> Title: Change Proposal Status (at dev.w3.org)

# Change Proposal: Remove specific alternate text requirements for various specific cases of img and replace with reference to external document.

# http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091209

<pimpbot> Title: ChangeProposals/ImgElement20091209 - HTML WG Wiki (at www.w3.org)

# 5 http://lists.w3.org/Archives/Public/public-html/2010Jul/0050.html

<pimpbot> Title: Change proposals for ISSUE-31 and ISSUE-80 from Ian Hickson on 2010-07-15 (public-html@w3.org from July 2010) (at lists.w3.org)

# 6 http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100504

<pimpbot> Title: ChangeProposals/ImgElement20100504 - HTML WG Wiki (at www.w3.org)

# 7 http://www.w3.org/html/wg/wiki/index.php?title=ChangeProposals/ImgElement20100510

<pimpbot> Title: ChangeProposals/ImgElement20100510 - HTML WG Wiki (at www.w3.org)

<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100504#Details

<pimpbot> Title: ChangeProposals/ImgElement20100504 - HTML WG Wiki (at www.w3.org)

SF: #1 says we have this guidance, talks about spliiting it out, replacing whats in the spec with whats here. Or have both but have normative requirement in the spec and this doc to agree.
... They both say that these are normative reqs for HTML 5.

<oedipus> http://dev.w3.org/html5/alt-techniques

<pimpbot> Title: HTML5: Techniques for providing useful text alternatives (at dev.w3.org)

SF: Outlines diffs between Steves version and the spec example.

Cyns; So does # 1 ask to delete the current spec guidance and point to yours, does it have options?

JS: Are you asking that the current spec guidance be removed?

Cyns: Change proposals should not have 'or's..
... We want to survey delete guidance to authors and link to Steves doc, or do nothing, are their others?

JS; #5 is do nothing.

Eliot: # 7 keep as HTML 4.

JS: It doesn't point to anything or tell you what to do..

Cyns: We are not talking about conformance now..but advice to authors..

# 7 http://www.w3.org/html/wg/wiki/index.php?title=ChangeProposals/ImgElement20100510

<pimpbot> Title: ChangeProposals/ImgElement20100510 - HTML WG Wiki (at www.w3.org)

Cyns: This doesn't go into author advice..
... It's a complementory change proposal.

JS: Not relevant.

<oedipus> are we talking about http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100504 ?

<pimpbot> Title: ChangeProposals/ImgElement20100504 - HTML WG Wiki (at www.w3.org)

# 6 http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100504

<pimpbot> Title: ChangeProposals/ImgElement20100504 - HTML WG Wiki (at www.w3.org)

JS: We can suggest several options.

Cyns: We can replace the guidance in the spec and leave the spec alone, Paul?

PC: Are the proposals just variations?

<oedipus> 3 options on the table are what?

PC: Are you trying to synthesis the change proposals?

<oedipus> can you repeat that please?

<eliot> janina: do we want to draft advice on these three proposals?

<oedipus> i think that any suggested resolution be vetted by the HTML TF on the public-html-a11y list

<eliot> ...suggestions?

<myakura> ScribeNick: eliot

<artur> I can live with a link to S.'s doc or the 2nd, but not with 3rd option... ;)

cys: I motion that we support trplacing advice to authors w/ a link to a separate document

<Stevef> HTML5: Techniques for providing useful text alternatives

janina: agenda item for next week to confirm on TF next week

<Stevef> http://dev.w3.org/html5/alt-techniques/

janina: consensus seems to be in the room. Any disagreement?

<pimpbot> Title: HTML5: Techniques for providing useful text alternatives (at dev.w3.org)

<paulc> HTML5: Techniques for providing useful text alternatives

janina: expect that document on the agenda for the tF for next week

paul: change proposals or decisions need to be made before last call
... decide in which order you work on these. 80? 122?

<Joshue> + 1 for the @alt doc to be reference/normative etc one way or another.

<cyns> 3 options: 1) replace the text in the HTML 5 spec that relates to authoring advice for text alternatives with a link to the separate document 2) paste the text from the document into the HTML 5 spec replacing the current text 3) do nothing

cys: I thought they were done

issue-80?

<trackbot> ISSUE-80 -- document conformance and device dependent display of title attribute content -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/80

<pimpbot> Title: ISSUE-80: document conformance and device dependent display of title attribute content - HTML Weekly Tracker (at www.w3.org)

<cyns> 3 options: 1) replace the text in the HTML 5 spec that relates to authoring advice for text alternatives with a link to the separate document 2) paste the text from the document into the HTML 5 spec replacing the current text 3) do nothing

jenina: we need to take up 80

paul: 2 proposals, one of which overlaps with 81

two slots tomorrow: 9-10

paul: why not start at 8:30?

scribe notes that Paul is powerful enough to use a colored marker

<oedipus> what is janina's question?

janina: emoticons...should they be alt texted?

<oedipus> of course

<oedipus> <img src="smiley.jpg" alt="smile">

<oedipus> <img src="winking.png" alt="wink">

For tomorrow, a11y to take room 3a (with audio) from 8:30-10:30, Lyon time.

<Joshue> +1 to Emoticons :-)

<oedipus> <img src="tongue.png" alt="sticks out tongue">

issue-127?

<trackbot> ISSUE-127 -- Simplify characterization of link types -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/127

<pimpbot> Title: ISSUE-127: Simplify characterization of link types - HTML Weekly Tracker (at www.w3.org)

issue-122?

<trackbot> ISSUE-122 -- alt text and description for Lady of Shalott example -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/122

<pimpbot> Title: ISSUE-122: alt text and description for Lady of Shalott example - HTML Weekly Tracker (at www.w3.org)

paul: null change proposal says do not make it nonconformaing. Are you going against the change proposal?

is this the right issue?

cyns: was emoticons covered?

<pimpbot> Title: HTML WG F2F meeting (room 3A) -- 04 Nov 2010 (at www.w3.org)

paul: call for change proposals ends on 11/27

<oedipus> call for change proposal ends 27 november 2010

<paulc> http://dev.w3.org/html5/status/issue-status.html#ISSUE-122

<pimpbot> Title: Change Proposal Status (at dev.w3.org)

josh: this is not a bout emoticons, it's about sometihng else

cyns: if it goes with no change, then we need to address the example
... 122 is dependant on 31

<oedipus> SteveF has a questoin

all: issue 122 doesn't have emoticons

stevef: got a deadline but there's not been enough discussion about how this is supposed to work

josh: I think the issue's badly worded

<MikeSmith> issue-122?

<trackbot> ISSUE-122 -- alt text and description for Lady of Shalott example -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/122

<pimpbot> Title: ISSUE-122: alt text and description for Lady of Shalott example - HTML Weekly Tracker (at www.w3.org)

<oedipus> steveF notes that issue 122 is logged against the alt-techniques document, not the HTML5 spec

paul: message from 10/27 about the scope.....I'll take care of this

janina: epub is tomorrow?

paul: yes

janina: let's adjourn until 2:00

<pimpbot> Title: HTML WG F2F meeting (room 3A) -- 04 Nov 2010 (at www.w3.org)

<oedipus> thanks to eliot and josh for scribing

<MikeSmith> plh, 02:00 - 03:30 Media Accessibility

<pimpbot> Title: HTML WG F2F meeting (room 3A) -- 04 Nov 2010 (at www.w3.org)

<pimpbot> bugmail: [Bug 11217] New: Footnotes I find it hard to believe, that even today, HTML does not include a specific element for including notes within the text. Notes are necessary for the full argumentation in the text without still belonging to the main text itself, and they includ <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2010Nov/0191.html>

<pimpbot> Title: HTML WG F2F meeting (room 3A) -- 04 Nov 2010 (at www.w3.org)

<raphael> Raphael Troncy: Media Fragments WG co-chair

<anne> Anne van Kesteren - Opera

Eliot Graff, Microsoft

<jorlow> Jeremy Orlow, Google

<mav> Mark Vickers, Comcast

<artur> a/me is here! Artur Ortega, Accessibility Evangelist, Yahoo!

<krisk> Kris Krueger - Microsoft

<hsivonen> Henri Sivonen, consulting for Mozilla

<mjs> Maciej Stachowiak, Apple

<davidC> David Corvoysier France Telecom

<yael> Yael Aharon, Nokia

<oedipus> on phone Gregory J. Rosmaita, sole proprietor and employee of oedipal enterprises, (very) ltd. / invited expert

<Kai> Kai Scheppe, Deutsche Telekom

<pimpbot> Title: Error (at www.w3.org)

<silvia> on irc for a bit Silvia Pfeiffer, contracting for Mozilla and just recently for Google

<pimpbot> Title: HTML WG F2F meeting (room 3A) -- 04 Nov 2010 (at www.w3.org)

<sicking> scribe: sicking

JS: we put forwards a media requirements doc
... people seemed to read it once people asked if it could be adopted
... we might have gotten some things wrong, but i'd like to clear up misunderstandings
... copyright has been discussed
... there was concern that it opened door to other things related to copyright
... need copyright info since copyright might be created by different people than creating the media

Media Accessibility

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements

<pimpbot> Title: Media Accessibility User Requirements - HTML accessibility task force Wiki (at www.w3.org)

HS: we should repeat the conclusion from yesterday as to what happens if some of the info in the requirements doc isn't met

FO: there are three things that the req doc speaks to
... associating tracks with a media element

FOL: need text track format

s/FOL/FO/

FO: there are requirements on the format
... user experience requirements on user experience in browsers. These are requirements on the UAs

<pimpbot> Title: HTML WG F2F meeting (room 3A) -- 04 Nov 2010 (at www.w3.org)

FO: do people agree that the method for associating a track with a media element should be agnostic to the format of the track

<gfreed> unfortunately i have to leave the call, but will rejoin in the near future.

FO: would be good to allow specifynig multiple formats and then UA can use the one they support
... want to be able to get track info out of the media file itself
... we should also discuss the track format itself

MJS: have question on requirement doc
... you can't tell which requirements are going into spec, and what are going to be guidelines for UAs, etc

FO: i am working on putting things in differenet buckets

PC: we need action items

<oedipus> trackbot, status?

<scribe> ACTION: frankolivier to provide mapping from media accessibility requirements doc to spec changes or guidelines for UAs [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action02]

<trackbot> Sorry, couldn't find user - frankolivier

<MikeSmith> trackbot, status?

<scribe> ACTION: Frank_Olivier to provide mapping from media accessibility requirements doc to spec changes or guidelines for UAs [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action03]

<trackbot> Sorry, couldn't find user - Frank_Olivier

<scribe> ACTION: Frank to provide mapping from media accessibility requirements doc to spec changes or guidelines for UAs [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action04]

<trackbot> Sorry, couldn't find user - Frank

HS: towards end of meeting on tuesday whose position was that failing to meet requirement in media accessibility reqs doc should stall last call

<plh> trackbot, reload

HS: we need to agree that the requirements that are on the spec actually need to stall last call

<oedipus> http://www.w3.org/2010/11/02-html-a11y-minutes.html

PC: the chairs are unlikely to agree to that
... we'll be looking for change proposals, and then ask if those meet the requirements in the doc

HS: we need to get that on record. I agree with that approach

<oedipus> a11y issues must be included in media section before any media section is "complete"

PC: we've told people in the TF that they have until feb 23rd to come up with change proposals

<hsivonen> (for the record, I agreed with what *Paul* / chairs said)

PC: if we have 50 requirements on the spec, then people have until Feb 23rd to come up with change proposals for those 50

<oedipus> FYI: if media goes forward without a11y, then there will be formal objections filed

PC: we've been told in no unclear terms that we're working on a schedule

MJS: i agree, that's what we've been told

<cyns> +1

<MikeSmith> trackbot, reload

<eliot> +1 to dsinger

<cyns> that was +1 to dsinger

DS: if we get the arcitecture correct then we'll be in a good position. If we have a way to link to captions then it matters less about the caption format for now

AO: want to explain background
... i'm blind but speak multiple languages. Any of those languages would be fine for me to consume

<dsinger> for the record, I am clear that we need the architecture in place that enables us to solve all of our requirements, and improve those solutions over time. This is much more important than detailed solutions to all. Architecture, once incomplete or wrong, will be a millstone. With the right architecture, we can provide better and better details over time.

AO: HTML5 need a way to provide multiple alternatives which are automatically picked according to what I can consume
... how should we make html comparable to what a tv set can do

CS: the requirements doc is structured in terms of user requirements, not spec features. Can make it look intimidating
... however one spec can meet multiple requirements

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements

FO: we can handle track definition spec issues through bugs

<MikeSmith> action-192?

<trackbot> ACTION-192 -- Frank Olivier to provide mapping from media accessibility requirements doc to spec changes or guidelines for UAs -- due 2010-11-11 -- OPEN

<trackbot> http://www.w3.org/html/wg/tracker/actions/192

FO: most of the requirements are around text captioning formats
... seems like implementors want to implement WebSRT, is that correct

JS: not sure if implementors have such agreement

<oedipus> Make track element additions technology neutral: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11207

JS: happy if some features can come later, such as captioning format

<anne> I do think we really want to have a single format supported by everyone...

HS: without implying comittment to anything, but think implementors are happier to implement something like WebSRT, rather than something TTML. One issue is parsing rules, HTML-like rather than XML-like
... don't think it's productive to discuss TTML as presumed format

<paulc> 1. Should the split of the rmedia equirements be on 3 areas: HTML5 spec, captioning formats (TTML, WebSRT), guidelines for UAs?

sicking: i'd rather start from scratch than start from TTML, its feature set is wrong

PC: i'm not convinced that this is the right group to do requirements on captioning format

<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=11207

PC: we should triage the requirements doc towards what *this* group should do

<raphael> +1 for separating captioning formats from HTML5 spec

<paulc> 2. Where should the requirements for captioning actually be done? Not in the HTML WG?

MK: when you say "this group". do you mean the HTMLWG or the people in this room or something else?

PC: if we brought in captioning format into W3C, it wouldn't end up in the HTMLWG

HS: I think it would be fine to bring WebSRT to W3C, and i do think that the HTMLWG would be a fine group to handle it

PC: I don't want to delay the group

<paulc> Paul agrees to learn to say "alternative media" instead of "captioning format".

FO: yes, TTML has a lot of features, which is both a good or a bad thing
... the IE team wouldn't have a problem with implementing websrt, if it was specced in W3C, and that it fulfilled peoples requirements
... I think we should define WebSRT, and publish a spec on it
... and we should do it by HTML Last Call

MJS: i can't make promises, but folks working on media feel pretty good about websrt
... they don't feel as good about TTML
... partially about complexity, but also that some of complexity doesn't seem warranted. Also doesn't align as well with other web tech

<anne> ("not very much" is an understatement imo)

MJS: it's not good that websrt is in whatwg space
... it's more important that it's moved to w3c, than that it's moved to HTMLWG

<silvia> could be separate spec in W3C space

MJS: if other vendors are interested in implementing it, we should spec it

DS: i don't think there is a "the solution"
... we need a solution for now. but things can change over time

<dsinger> DS: "the" solution is a mis-leading phrase; "the" solution is an HTML architecture that allows captions to be associated with media content; we need "a" solution to get going and webSRT may well be that. But webSRT is not and will not be the only solution to captioning ever (even if TTML never makes it), and captioning is not "the" problem either. Even if we endorse it, we should not make captioning specifically and only webSRT and we should not make altern

DS: also problem isn't just captioning

<dsinger> media be only text.

ack

HS: i think websrt should not go to the same people that defined ttml. Last time they produced ttml which we're talking about not using. I think html is a better group
... the expertize needed is how to integrate with existing web platform

<mjs> +1 to hsivonen

DS: they were asked to create a different type of format, not a delivery format which is what we need now. So lets not critique them

PC: do people agree that WebSRT is what we need

<oedipus> we need to work on WebSRT to ensure meets a11y reqs

<MichaelC> MK: I'm format neutral, want to do user requirements then technical requirements then gap analysis of candidate features then look at which one we might want to improve and adopt with potential enhancement; I do (personally) lean towards a specified interoperable format

PC: we don't get to make the decision where the spec ends up, it's up to the AC

<Zakim> MichaelC, you wanted to say I'm format neutral, want to do requirements then gap analysis of candidates then look at which one we might want to improve and adopt, but I do

MJS: previously we talked about splitting spec requirements vs. other requirements. We shold focus on the former

<oedipus> Make track element additions technology neutral: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11207

CS: we might need some amount of gap analysis, but it seems like the track element is what needs to go into HTML which is a deeper arch thing

PLH: i'm worried about not looking at the format at all, then by feb 23rd we might not have a solution at all

<oedipus> plus 1 to PLH

PLH: the question about which group should do it is a question about patents

HS: aren't we rechartering soon anyway?

<hsivonen> We should also analyze the proposal that modifies WebSRT with the HTML fragment parsing algorithm

PC: we'll probably ask for a charter extension, not a charter revision

PLH: we can always create a new WG for websrt, we can do it quickly
... i agree the existing text WG might not be a good place

<silvia> why not leave the development of the WebSRT spec to the a11y TF?

AVK: we prefer to have a single format to implement, rather than multiple

<raphael> s/existing text WG/existing TimedText WG

<plh> plh: there is expertise in the TTML wg that would be useful to have in the new wg

<Zakim> kliehm, you wanted to say that alternative media isn't limited to <video> and <audio> either

DS: i don't think we'll end up with multiple formats Websrt looks like a good start

<raphael> silvia, a spec is produced by a WG chartered for doing so

thanks

<dsinger> ds: I don't see an immediate need for multiple formats and at the moment webSRT seems like a perfectly fine place, even if it's not the be-all and end-all of captioning

<scribe> ACTION: paulc and co-chairs to investigate how to handle standardization of websrt [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action05]

<trackbot> Created ACTION-193 - And co-chairs to investigate how to handle standardization of websrt [on Paul Cotton - due 2010-11-11].

JS: so assumption is websrt is what we'll use?

DS: no, it'll be *a* solution that we can use

PC: so frank will come up with requirements out of the requirements doc which relate to alternative media format

<artur> +1

<artur> independently ofany format we have to decide to be able to specify alternative audio (e.g. audiodescription, clear voice, different languages), alternative/additional video (e.g. several different s), sign languages), different kind of closed-captions (e.g. with video description, different langueages, etc.) with the media elements audio( & video.

MK: the problem isn't just for video, it's also for audio, canvas, image, etc

<oedipus> plus 1 to artur

MK: we need a solution that works for more than video

<kliehm> http://www.w3.org/Bugs/Public/show_bug.cgi?id=8885

<kliehm> http://dev.w3.org/html5/spec/embedded-content-1.html#embedded-content-1

FO: doesn't seem like any browser vendor has a major problem with websrt?

<kliehm> s/need a solution/need a consistent solution/

FO: we'll keep the HTML <track> feature open, so that it can work for other formats as well

<Sean> correction: With a well defined WebSRT

undo my previous s/MC/MK/g

MC != MK

<anne> whisky for everyone

<kliehm> s/for more than video/for more than video so that UA can provide alternative content based on user's choices/

<frankolivier> http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements

<anne> http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements

FO: DV 1,2,5,6,10,11,12 seem to be UA guidelines

<kliehm> s/MK: we need a solution that works for more than video/MK: need a consistent solution for more than video so that UA can provide alternative content based on user's choices/

CS: should "author should be able to override volume" say "user should be able to override volume"

SH: actually, author is correct, it's probably a requirement on the media format

FO: DV 3,4 are in spec today
... DV 7,8,13 need more info

JS: i think this is a lifted requirement for other WG, want smooth transitions in volume, not big steps

HS: does it require a audio format which represents stereophonic middle, and separate info how to pan it?

<Sean> that is how its done in TV

JS: maybe, i don't know

<oedipus> UAAG sees 3 levels of control: 1. gross (on/off) 2. author defined increments 3. user access to all media player's increments

HS: why not mix the two together?

CS: does this affect the spec?

HS: it might affect the spec if the HTML spec needs to be able to link to a separate file which contain panning info

JS: DV13 is a UA issue

FO: DV14, about copyright, has been discussed a lo

t

HS: if the track format has a place to put human-readable copyright info, then this requirement is met

FO: that seems correct

PLH: media annotations working group need review from browser vendors on the API they are proposing

FO: CC1,12,13 are user experience requirement
... CC14 seems like a format requirement

<Sean> CC14 is there to allow parity with US TV caption sources

FO: CC15 is UX issue
... CC15,23,24 is UX issue

HS: CC26 spec supports this already

FO: CC22 in spec already
... 17.2 already in spec
... CC17.2 already in spec

<richardschwerdtfe> yep

<mav> Is there an existing capability or requirement for programmatic access to closed caption data for non-display usage (e.g. searching for keywords)?

FO: CC2 format req
... CC3,4 format req

MJS: CC5 depends on who makes the decision of where the text goes. If author determines it, then it's a spec requirement, if user decides then it's a UX req

FO: CC6,7 is UX req
... CC8 is format req
... you can stop scribing, i'll send out this list

<hsivonen> it seems to me that there are a lot of reqs that would be met by HTML fragment algorithm-augmented WebSRT but not Hixie's WebSRT

<oedipus> http://www.w3.org/html/wg/wiki/TPAC_2010_Agenda

<oedipus> @kliehm, thanks

<mjs> oedipus, we are going to continue media a11y for half an hour

<oedipus> thanks, mjs - i shouldn't have hung up to recharge phone -- all 5 slots seem to be filled :(

<Sean> Sean is irc only

<anne> dsinger, basically, you use the API and a metadata track

<anne> dsinger, that is my understanding, anyway

<anne> no scribing needed?

<oedipus> zakim says the conference is restricted at this time

<oedipus> sean, jim and i are IRC only, so scribing would be appreciated

<mjs> oedipus, we are going to hang up and redial the call

<MichaelC> everyone, redial using 26636

<Sean> Not connected to conference room

<Sean> yes

<Sean> no we cant

<oedipus> no we can't -- at least i can't

<Sean> did you mean 26636 or 26634

<Sean> as did I

<Sean> ok hear you now

<Stevef> oedipus: I am here too

<oedipus> plh post on DV-4media accessibility and API for Media Resource 1.0 referencing http://www.w3.org/TR/2010/WD-mediaont-api-1.0-20100608/ - http://lists.w3.org/Archives/Public/public-html/2010Nov/0060.html

PC: when discussing this on the list, please start a new thread for each item and put the moniker of the issue in the subject field

<Sean> am I on the right call for the track discussion?

Other uses of timed tracks

<paulc> Testing is on #HTML-WG2

<cyns> MV: we've been looking at mapping commercial video onto html 5

<cyns> video looks fine, UI for user guide is fine, but we have issues

<cyns> MV: things with issues are data.

<cyns> MV: data we extract out to do various things. might be usefult for timed tracks.

<eliot> ScribeNick: eliot

<mav> Examples of non-accessibility uses of Timed Tracks:

<mav> They are in-band timed tracks and media-resource-specific timed tracks.

<mav> 1. Programmatic access to closed caption data for non-display usage (e.g. searching for keywords)

<mav> 2. Television content rating codes

<mav> - example: US Parental Controls (V-chip)

<mav> http://tia.nufu.eu/std/EIA-744-A

<mav> 3. Enhanced TV (ETV) application messaging

<mav> - example: NA Cable EISS (ETV Integrated Signaling Stream) messaging

<mav> http://www.cablelabs.com/specifications/OC-SP-ETV-AM1.0-I05-091125.pdf

<mav> 4. Client-side ad insertion

<mav> - example: SCTE 35

MV: these cd be out of band
... examples from north american cable
... but cd be from around the world
... first is programmatic access
... look for key words, not for display
... but for an app to use
... you can use associated metadata
... never exposed to user
... is it possible in current architecture?

<oedipus> API for Media Resource 1.0 http://www.w3.org/TR/2010/WD-mediaont-api-1.0-20100608/

DS: given that audio group...camera to picture, etc., that programmatic access what's the current thinking?

FO: spec says you can extract these. unique id for every queue
... I think this is supported today. You can switch tracks
... one concern:
... some ppl think that the captdn't be exposedion

s/exposedion/exposed

Janina: DRM issue

MV: same could be said to programmatic access to the audio

FO: Is this a real thing or are we being

MV: never heard anyone compain of it (afaik)

DS: I could imagine someone complaining

<Sean> In TV captions are somewhat obscured because you need specialist equipment to extract them

<Sean> on the web its going to be easy to wholesale grab them

DS: you can display these captions but cannot use them programmatically

janina: using them as intended is not republishing

MV: 2nd example comes from tv content rating code

<Sean> A format could add explict metadata to allow third party use of specific items

MV: in US, v-chip system is a rating code
... they come down as a simple code that's sent continuously and changes for boundaries
... it is timed, in that it's associated w/ a certain time
... but you'd want to know the value when you tune in and then when it changes

<oedipus> captioning re-uses copyrighted content to make it accessible to those who cannot hear along with indications of purely aural events (such as a door slam) -- audio description, it has been argued, is commentary on copyrighted content

DS: could be a track type

MV: could black out a certain value
... tv's are looking to implement html5 interface
... description of current APIs seem very caption-oriented
... you wouldn't want a cue up every time it's sent
... 3rd example

<gfreed> okay, will be calling in in a minute.

MV: enhanced tv: an interactive element
...example: game show that you play along with

<gfreed> got it-- thanks.

have to have timed cues that correspond to the moment

scribe: applications cues...metadata? application cues?
... in NA cable, EITS
... comes down to ..you deliver app-specific things
... then a block of data

MK: Can be more than Q&A. Could it be smiles? Advertisements?

MV: absolutely. Send me more info. Main use in US is for augmented advertising
... seems very light time tracks, but we need to figure out how to make it work
... people expect to have interactive experience on tv and PC
... final example is ad insertion
... ability to get video content locally

<kliehm> s/smiles/SMIL (Synchronized Multimedia Integration Language)/

MV: cues sent down that tell you to run a local ad. maybe different for different users. allows targeted ads.

<mav> URL for ad insertion: http://www.scte.org/documents/pdf/standards/ANSI_SCTE%2035%202007%20Digital%20Program%20Insertion%20Cueing%20Message%20for%20Cable.pdf

Janina: can locate to a degree by IP

Paul: are you asking if it's currently supported?

janina: it comes from wherever it comes from

MV: the first three could be supported but I am not sure

There's a scheduler at the networl levey. with a special size

s networl levey/network level

OA: the red button on England

MV: it's the activation in the UK
... w/ the key definitions they're talking about adding to CSS spec, you'd have support forthe red button
... red button loads the app associated at that time with that channel
... some apps have no screen events
... but some things want to be synchronized, like a game or an ad
... so after you load the app, it needs to listen to a timetrack for these messages
... not sure how to do the fourth one...client-side ad insertions

DS: sounds like a delivery issue, rather than HTML issue

MV: is time tracks the right place to put those URLs?

DS: if it's interstitial you can use the media format
... if it's parallel use time metadata

MV: TV content rating codes

paul: are you expecting UA to respect that as well

MV: that's an issue of law

paul: any different than subtitles?

MV: a lot less data
... does the API work right so I don't get 60 hits a minute
... it only changes when it changes.

Janiina: wouldn't solution just be "What's the current value?"

MV: a callback when it changes would be good

DavidC: initiative to specify how to access this info: the open IPTV forum
... message is triggered every time there's a change

<MikeSmith> Open IPTV Forum specs

MV: an API that says "Access this control," or something.
... want a media resource specific mapping
... so you can tell anyone, if you want to do this......
... the html5 spec doesn't know anything about tv
... for content rating code, if we map it, but it may be in there, but not the API to tell you when something changes

PC: when you want the server to push something to the client...perhaps a potential technology solution is a bidirectional solution

MV: I was thinking about two parallel bands. Doing it out of band, well, the data's not sent like that. And you may have latency

DavidC: the broadcaster has a very short delay.

AO: If you're using multicast, you won't want a 1:1

MV: clientside ad insertion, soulds like the way DS described it mat be a way to do it

DS: local video?

MV: sometimes it is done using local video, but as you said it doesn't matter what server it comes from
...MV: that's it

rssagent, make minutes

MV: will there be best practices?

PC: sometimes individuals will make a primer
... may be another group in w3c that's already working on it
... I personally think that one thing that's going to happen is that there will be a fair number of comments asking if "I can do X" and I suspect that we will take it off line and say yes. If we say no, the challenge is how they'll respond.

MV: and for the one issue, should I submit a bug?

PC: Yes, but realize that we are in LC bugs right now. Earlier is better.

<davidC> This topic may fit in the Web and Tv charter: http://www.w3.org/2010/09/webTVIGcharter.html

Limited Devices

<MikeSmith> Fukuno-san speaking

<MikeSmith> Taisuke Fukuno

<MikeSmith> TF: as a developers, we want to create apps for all devices

<MikeSmith> … but not all mobile handsets can support full HTML5

<MikeSmith> TF: people don't change their mobile handsets very often

<MikeSmith> … the hang on to them for a few years

<MikeSmith> TF: we want to produce a downloadable browser

<oedipus_away> HTML5 basic like XHTML Basic?

<MikeSmith> … because of resource limitations on these devices, we need to consider something like Compact HTML

<MikeSmith> Paul Cotton

<MikeSmith> PC: I bet there are a bunch of people in the room who don't want to do this at all

<MikeSmith> … we have people in this room who have mobile devices that are [marketed as "HTML5" devices]

<MikeSmith> PC: there will be devices for which are capable of running all features from HTML5, some that have no hope of running many features from HTML5, and some in between

<MikeSmith> Dave Singer

<MikeSmith> DS: we have spent a lot of time at the W3C on promoting the idea of "One Web"

<MikeSmith> … and we have seen [profiling efforts in the past not work out]

<oedipus_away> wonders if the windows phone will force non-sighted users to use Narrator

<oedipus_away> Narrator ain't VoiceOver...

<MikeSmith> AO: you sometimes have mobile devices that don't have normal buttons, you want to use them while driving, etc.

<MikeSmith> … [there is some overlap with accessibility needs]

<MikeSmith> PC: I spoke with a rep from LG

<MikeSmith> … and it was about how it would be preferable to have a video codec specified in HTML5

<MikeSmith> … and I pointed out that the TV industry could decide on a profile of HTML the did mandate a particular video codec

<MikeSmith> … so we would end up with vertical standards

<MikeSmith> … but you are unlikely to see W3C do that

<MikeSmith> … not saying that W3C will not do that for sure

<MikeSmith> MV: We are working on such a vertical standard

<MikeSmith> … e.g., adding encryption and DRM

<MikeSmith> MV: I have been hearing the same think about the cost issue

<MikeSmith> … footprint issue

<MikeSmith> MV: the range of connected TVs

<MikeSmith> … lower end TVs vs connected TVs

<MikeSmith> MV: could be a matter of just waiting

<MikeSmith> MV: the low-end devices just have set functions

<MikeSmith> MV: have discussed how they might develop by using a subset of HTML5

<MikeSmith> MV: they are currently using non-standard drawing APIs

<MikeSmith> … but they could be developing using the HTML5 canvas element

<MikeSmith> … which would make them upwardly compatible

<MikeSmith> MV: JS+<canvas>

<MikeSmith> AO: another proof that accessible <canvas> is important

<oedipus_away> strong plus 1 to AO -- canvas a11y needs to be addressed before HTML5 deployed in TVs and other devices

<MikeSmith> Ileana: there is an opportunity to create a profile

<MikeSmith> … maybe you don't want to say "profiling"

<MikeSmith> … but instead just define the basic elements

<richardschwerdtfe> tried to call in - conference is restricted

<richardschwerdtfe> sigh

<MikeSmith> KS: the feedback we got from vendors in the Asian market was that [the profiles we were developing] were not up to date with the current device capabilities

<MikeSmith> MK: we find that there are 3 broad classes of devices

<richardschwerdtfe> no luck getting in

<richardschwerdtfe> oh well - back to processing aria comments

<MikeSmith> MK: I wonder if there is a use-case for "lo-fi" HTML5-capable phones … limited profile, just for, e.g., gaming

http://www.w3.org/standards/webdesign/mobilweb

<MikeSmith> EG: I think this is an authoring issue

<MikeSmith> EG: not sure what you are asking for from the WG

<MikeSmith> PC: problem is, there are some devices that HTML5 [content] won't run on

<MikeSmith> AO: simple example: several video elements on a page

<kliehm> AO: only one decode

<MikeSmith> PC: for the last 7 or 8 years, I have been involved with WSI

<kliehm> s/decode/decoder/

<MikeSmith> … = Web Services Interoperability

<MikeSmith> … we don't purport that the profiles we developed for WSI were appropriate for everybody

<MikeSmith> … they are aimed at developers

<MikeSmith> … we chose to not try to define them at W3c

<MikeSmith> … W3C does not have the vertical expertise to write all the vertical profiles

<MikeSmith> … I thin there is nothing wrong with that

<MikeSmith> … can take the "generic" W3C spec

<MikeSmith> … [and build a vertical profile from it that meets your market needs]

<MikeSmith> PC: of course if you find mistakes, you can bring that info back

<MikeSmith> PC: don't expect those profiles to be done at the W3C

<MikeSmith> PC: instead expect them to be done by the domain experts, elsewhere

<MikeSmith> Ileana: I know there are mobile operators here at W3C who are here in part because they are interested in this area

<MikeSmith> … this is the kind of thing that is needed for 70% or 80% of the market

<MikeSmith> Ileana: I think there is expertise at W3C to address the needs of the mobile market

<MikeSmith> … the W3C needs to have a clear message about this

<MikeSmith> MV: subsetting HTML itself is really problematic

<MikeSmith> … but there is a case where the W3C may be more interested

<MikeSmith> … canvas is one of those cases

<MikeSmith> … the canvas environment is a separate world

<MikeSmith> … it is a procedural world, rather than a declarative world

<MikeSmith> … thin layer on top of graphics capabilities that are already on the devicdes

<MikeSmith> … and there are already all kinds of such non-standard thin layers for graphics that are doing this

<taisukef_> How will I enter te queue?

<MikeSmith> MV: but JS+canvas could be the standard way to make this thin layer for graphics

<taisukef_> thanks!

<MikeSmith> DS: what features do we need in CSS and HTML to be sensitive toward needs of limited devices

<MikeSmith> PC: example I gave was outside of W3C

<MikeSmith> … but it could be done within the W3C

<MikeSmith> … just as well as it could be done outside

<MikeSmith> PC: but [we in this HTML WG] have a priority to just get the core spec done

<MikeSmith> … and then others can create profiles

<MikeSmith> PC: so we should be careful not to tell interested parties to go somewhere else

<MikeSmith> Ileana: Somebody has to find the best organizational environment where this kind of work to take place

<davidC> +1 on paul : profiling is already ongoing, and many of us are here to make sure the spec is delivered in time

<MikeSmith> PC: I don't thin you are going to get that resolution from the HTML WG

<MikeSmith> PC: there are people on both sides of this argument

<MikeSmith> TF: HTML5 does not need guidelines or profiles

<MikeSmith> TF: HTML5 is core, but video, canvas, CSS are "extensible" [maybe means "extensions on top of HTML"?]

<MikeSmith> PC: if people want us to "teir" the HTML5 spec like this, then a good time to do that would be when we go into testing

<MikeSmith> PC: so there is some synergy here

<MikeSmith> AO: canvas will be misused…

<MikeSmith> … I would appreciate that if profiles are being done, that they get done within the W3C

<MikeSmith> PC: tomorrow at 11, we have a session on canvas accessibility

<MikeSmith> … and we can discuss this more then

<oedipus_away> paulc, rich s - the lead on canvas a11y indicated when i pinged him that the canvas slot is a bit too early for him -- could it be adjusted, as it wouldn't make much sense to talk about canvas a11y without him

<oedipus_away> paulc, rich is in the channel -- he is richardschwerdtfe

<oedipus_away> MikeSmith - can you communicate to the chairs that rich s - the lead on canvas a11y - indicated when i pinged him that the canvas slot is a bit too early for him -- could it be adjusted, as it wouldn't make much sense to talk about canvas a11y without him

<MikeSmith> oedipus_away: Paul says we can switch the canvas and ARIA slots

<MikeSmith> would that work?

<MikeSmith> so canvas would be at 14:00 local time here

<krisk> Agenda: General Accessibility (part2)

General Accessibility (part 2)

<paulc> scribenick: krisk

<paulc> We decided to have one long minutes.

<paulc> Thanks.

<paulc> We are still getting setup from a phone call to #html-wg

<eliot> Url for change proposals: http://dev.w3.org/html5/status/issue-status.html

We will start where we left off at issue 31

<paulc> issue-31?

<trackbot> ISSUE-31 -- Author conformance requirements for the alt attribute on images -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/31

<eliot> issue-31?

<trackbot> ISSUE-31 -- Author conformance requirements for the alt attribute on images -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/31

<oedipus> conf code is 26631

shelly: we are looking a the change propose for issue 30 - last 2 items

<oedipus> s/shelly:/cynthia:/

cyns: next part is to update the definition of the img tag

<oedipus> alt is not fallback content because it is primary content for those who cannot process images or have image loading turned off

cyns: the goal of these updates is to update the concept of fallback

<kliehm> http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100510#Details

janina: do people object to this?

<kliehm> s/for issue 30/for issue 31/

janina: an image is an image, they are not the same

<paulc> http://dev.w3.org/html5/status/issue-status.html#ISSUE-031

<kliehm> Cyns prefers http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20100510#With_Suggested_Definition_of_the_Image_Element:

cyns: option #1 is do nothing
... optins #2 is 'with suggest definition of the image element'

s/optins/option/

<cyns> An img element represents an image.

<cyns> The image given by the src attribute is the embedded content, and the value of the alt attribute is the img element's fallback content.

<cyns> option 1: Do Nothing. Current spec text

<cyns> Option 2:

<cyns> The <img> element represents content that can be rendered visually (as an image) and textually. The src attribute provides visual content in the form of an image and the alt attribute provides textual content. The content in the src and alt attributes must convey equivalent meaning.

<cyns> Option 3:

<cyns> An img element represents an image.

<cyns> The image given by the src attribute is the embedded content, and the value of the alt attribute is text content that is rendered when the image is not displayed by a User Agent.

<Zakim> oedipus, you wanted to say that alt is not fallback content because it is primary content for those who cannot process images or have image loading turned off

<oedipus> GJR

<oedipus> gregory

gjr: i prefer option #2

cyns: can you (gjr) can you live with option #3?

<oedipus> would prefer wording that says that alt text is equivalent primary content

janina: I would prefer option #2

<janina> equivalent text semantec?

gjr: I could live with option #3 with a change

paulc: is not the primary question is alt text the primary content?

<oedipus> yes

<eliot> s/ primary content/primary equivalent content

cyns: the issue is fallback

<kliehm> s/is alt text the primary content/is alt text the primary equivalent content/

janina: can we solve this w/o primary and fallback?

<oedipus> PROPOSED MODIFIED #3: The image given by the src attribute is the embedded content, while the value of the alt attribute is to provide equivalent content for those who cannot process images or for whom image loading is turned off

<oedipus> PROPOSED MODIFIED #3: The image given by the src attribute is the embedded content; the value of the alt attribute provides equivalent content for those who cannot process images or for whom image loading is turned off

<dsinger> "or for those to whom images are not displayed"?

gfr see the second PROPOSED MODIFIED #3:

<cyns> when are not displayed

<cyns> when images are unavailable

janina: i like the PROPOSED MODIFIED #3:

<oedipus> GJR takes dsinger's suggestion as a friendly ammendment

cyns: do we want the first sentence?

<cyns> An img element represents an image.

<cyns> The image given by the src attribute is the embedded content; the value of the alt attribute provides equivalent content for those who cannot process images or for whom image loading is turned off

<oedipus> plus 1 to cyns

janina: let we like this as a group?

paulc: what I am hearing - we have 3 intial proposals

<cyns> the image given by the src attibute is the embedded contont; the value of the alt attributge provides equivalen content when images are unavailable

paulc: now we are comming up with 2 new proposals

Option #1 is 'the image given by the src attibute is the embedded contont; the value of the alt attributge provides equivalen content when images are unavailable'

cyns: removes the 'for whole'

gjr: asks for minor change

<cyns> The image given by the src attribute is the embedded content; the value of the alt attribute provides equivalent content when images are not displayed

<oedipus> The image given by the src attribute is the embedded content; the value of the alt attribute provides equivalent content for those who cannot process images or for whom image loading is disabled

cyns: note that we will still keep the first sentence

<oedipus> The image given by the src attribute is the embedded content; the value of the alt attribute provides equivalent content for those who cannot process images or for whom image loading is disabled

Option 2: is change nothing

cyns: do we agree to take #1

<oedipus> slight amendment: The image given by the src attribute is the embedded content; the value of the alt attribute provides equivalent content for those who cannot process images or for whom image loading is disabled

so new Option #1 is 'The image given by the src attribute is the embedded content; the value of the alt attribute provides equivalent content for those who cannot process images or for whom image loading is disabled'

cyns: either is fine
... we need someone to write the change proposal
... can you do the change proposal?

<oedipus> trackbot, status?

<scribe> ACTION: gregory to draft a change proposal to issue 31 to update the definition of img element [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action06]

<trackbot> Created ACTION-194 - Draft a change proposal to issue 31 to update the definition of img element [on Gregory Rosmaita - due 2010-11-12].

janina: Ok - lets move on to item #80

<kliehm> http://www.w3.org/html/wg/tracker/issues/80

paulc: by definition this action items are due in a week
... so it should be on the agenda for the next meeting

<oedipus> issue-80?

<trackbot> ISSUE-80 -- document conformance and device dependent display of title attribute content -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/80

cyns: reading http://www.w3.org/html/wg/tracker/issues/80 to the group

<Marco_Ranon> hi Gregory

<oedipus> "2 courses of action could remedy this: 1. require that browsers display the title attribute content on an image when the image is not available or in a device indpendent manner. 2. remove the the text "The title attribute is present and has a non-empty value." from http://dev.w3.org/html5/spec/embedded-content-0.html"

<cyns> http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091203

<oedipus> related bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7362

janina: gjr do you want to speak to this?

cyns: I think the action would be to either A) close issue #80

the second action would be to B) add title to the change proposal

cyns: does anyone object to these two items?

<oedipus> GJR: title is supplemental information, alt is equivalent information (or an attempt at equivalency)

janina: I am concerned is title a reasonable alt information

paulc: two issues
... #1 how often do people use title
... #2 when people do - is the title enough?

<Zakim> oedipus, you wanted to say title is for supplemental information, alt is equivalent information (or an attempt at equivalency)

dsinger: it seems that this is a really a UA not a conformance requirement

<Marco_Ranon> +1 to GRJ, but fall back support is not consistent across AT

<oedipus> good point, marco

gjr: most screen readers have this type of fallback object

<oedipus> s/fallback object/fallback cascade model (when encounter image use alt, if no alt, labelledby, if no labelledby title, if no title filename/

cyns: with fallback you can end up with duplicate information being presented, which is a poor experience

<oedipus> note: many screen readers offer discrete control over images and images-used-as-links so that one could grab hyperlink text over @alt if that is what they user desires

<kliehm> scribenick: kliehm

<scribe> scribe: Martin_Kliehm

cyns: There are two ways AT gets accessibility information: from the DOM and from the browsers. Currently title is map to the accessibility API. If title is not considered a suitable equivalent we would need to remove it from the accessibility API.

janina: we wouldn't want title as a conforming alternative for image content.

<oedipus> plus 1 to Janina - don't want "title" used as equivalent or fallback text, but supplementary meta-data about the object

<oedipus> s/text, but supplementary/but for supplementary/

s/title is map/title is mapped/

<cyns> The change proposal we resolved to draft yesterday to address teh conformance part of issue 31, which was to include the broadest possible set of text equivalents, will not include @title

<cyns> That change proposal will also address issue 80.

s/teh conformance part/the conformance part/

janina, cyns: disagreement?

<cyns> If that change proposal is accepted, it implies a change to the HTML to Accessibility API mappings document such that @title would never map to accessible name

janina: remaining items 123, 184

s/123/122/

<oedipus> issue-123?

<trackbot> ISSUE-123 -- Autofocus attribute security concerns -- closed

<trackbot> http://www.w3.org/html/wg/tracker/issues/123

<oedipus> issue-122?

<trackbot> ISSUE-122 -- alt text and description for Lady of Shalott example -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/122

cyns: The "Lady of Shalott" example in the alt techniques document is disputed. It has been argued that it's improperly labeled, and that the image should be considered purely decorative rather than "enhance[ing] the themes or subject matter of the page content", and that it should be given empty alt text rather than a brief description. The scope of this issue is the Lady of Shalott...
... example, and in particular, the alt text used in it, the description of this example, and any other closely related matters.

<oedipus> related bug 1: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9077

cyns: change proposal #1: do nothing

<oedipus> related bug 2: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9081

<paulc> http://dev.w3.org/html5/status/issue-status.html#ISSUE-122

<paulc> http://lists.w3.org/Archives/Public/public-html/2010Oct/0393.html

paulc: the chairs issued a call for counter proposals last week

oedipus: the Lady of Shalott example is used several times in the document.

cyns: I think the example does the job

<oedipus> http://dev.w3.org/html5/alt-techniques

paulc: Deadline is November 27 for alternate or counter proposals. It also implies to the document.

<paulc> Here is the end of the -122 thread: http://lists.w3.org/Archives/Public/public-html/2010Oct/0404.html

paulc: If anybody wants to adopt Issue-122 and needs more time the chairs would extend the deadline.

cyns: there were three survey options from yesterday's meeting

<oedipus> in editor's draft the entirty of 4.8.1.1.1 General guidelines is "ISSUE-31 (alt-conformance-requirements) blocks progress to Last Call"

paulc: I suggest taking the thread from the HTML list and putting it on the TF list

janina: putting discussion of the "Lady of Shalott" example on the TF agenda for next week

<oedipus> paulc, cyns, janina - the lady of shallot example follows the text "Examples where the image is purely decorative despite being relevant would include things like a photo of the Black Rock City landscape in a blog post about an event at Burning Man, or an image of a painting inspired by a poem, on a page reciting that poem. The following snippet shows an example of the latter case (only the...

<oedipus> ...first verse is included in this snippet)" in http://dev.w3.org/html5/spec/embedded-content-1.html#the-img-element

issue-133?

<trackbot> ISSUE-133 -- Add a modal attribute to html5 to indicate a modal segment of the DOM (modal dialog) -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/133

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10645

cyns: Modal dialogs are usually created by JavaScript. Accessibility might be added with ARIA, but it depends on the author.

<Zakim> oedipus, you wanted to say what i think we need for issue 180 is to get the lady of shallott example out of http://dev.w3.org/html5/spec/embedded-content-1.html#the-img-element and

oedipus: propopsing to write another example that will be posted to the a11y TF list

kliehm, janina: there's consensus that modal is necessary, the question is whether we want to wait

paulc: since the bug has been escalated somebody doesn't want to wait

(tracker issue has been added by Steve Faulkner)

<oedipus> paulc, http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/0072.html

cyns: adding text to the spec doesn't seem to be that difficult, but implementing might be

<oedipus> issue-80: http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/0071.html

<trackbot> ISSUE-80 document conformance and device dependent display of title attribute content notes added

paulc: pinging Everett Zufelt to write a change proposal

<oedipus> issue-80: http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/0072.html

<trackbot> ISSUE-80 document conformance and device dependent display of title attribute content notes added

janina: putting issue 133 on the agenda of next week's call

issue-134?

<trackbot> ISSUE-134 -- Provide tablist and tab states for menu and command elements respectively -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/134

<oedipus> issue-180: http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/0071.html

<trackbot> Sorry... adding notes to ISSUE-180 failed, please let sysreq know about it

<oedipus> issue-180: http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/0072.html

<trackbot> Sorry... adding notes to ISSUE-180 failed, please let sysreq know about it

<oedipus> ACTION: Gregory - propose replacement example for lady of shallot example of purely decorative use of image with code example of one of the use cases provided in prose introducing the example [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action07]

<trackbot> Created ACTION-195 - - propose replacement example for lady of shallot example of purely decorative use of image with code example of one of the use cases provided in prose introducing the example [on Gregory Rosmaita - due 2010-11-12].

cyns: I would support a change proposal, but I think there are more urgent priorities.

paulc: pinging Everett to provide a use case

<oedipus> issue-122: http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/0071.html

<trackbot> ISSUE-122 alt text and description for Lady of Shalott example notes added

bug review

<oedipus> issue-122: http://lists.w3.org/Archives/Public/public-html-a11y/2010Nov/0072.html

<trackbot> ISSUE-122 alt text and description for Lady of Shalott example notes added

<oedipus> action-195: this is bound to issue-122 "alt text and description for Lady of Shalott example"

<trackbot> ACTION-195 - propose replacement example for lady of shallot example of purely decorative use of image with code example of one of the use cases provided in prose introducing the example notes added

<cyns> http://www.w3.org/Bugs/Public/show_bug.cgi?id=8885

<oedipus> issue-122: this is bound to action-195

<trackbot> ISSUE-122 alt text and description for Lady of Shalott example notes added

<cyns> scribenick: cyns

opens a larger issue. No consistent fallback for embedded content, canvas, svg, iframe, etc.

mk: If there is fallback content,
... if there is fallback content it is not used for accessiblity, except in teh case of canvas
... this bug is entitled embedded content, but gives an example about captioned video. Ian Hixon made a good point that this was inteded to apply to all elements in the section: audio, canvas, embed, iframe, img, etc
... frank yesterday said there should be accessible fallback content beyond a title attribute or alt text.

ao: the differnce btwn canvas and all the toher elements, is that canvas doesn't have an underlying dom with sematnic inforamtion. the others do.
... the accessible dom makes canvas more like SVG in that you can navigate the dom to get accessiblity

mc: we would like consistent approach to fallbacks between different types of objects.
... we haven't come to an opinion about which mechanism we'd like to see

mk: should img be able to hold other elements as well?

mc: we'd like that in an ideal world. object was introduced in html 4 to address this issue, but it never took off
... we want direct semantic association of fallbacks, and the ability to differentiate between short and longer, richer fallbacks.
... but we also have to synch up with history of what has been implemented, and can be implemented

mk: embed, for example, there is fallback content possible, but only for browsers taht don't support the content

mc: if you use embed for flash content, users who have flash installed can't access the fallback, even if they can't use the flash content
... how important is consistency, and how much attention are we going to pay to backward compatibility, and some of the specifics: is alt good enough, or do we need richer fallback. and the issue of long fallbacks (longdesc vs. nested content)

cs: not sure that consistency is important enough to justify the difficulty of approaching them. details are very different, inconsisten in other ways.

ao: some elements already have dom fallback, others need to have it added. img would be nice, but...

js: consistency is almost a little theoretical because the situations are so different. the notion that workable fallback is available, and that you can get at it is important

mk: PF asked Gez to file bug in january

js: was part of our review

cs: PF having filed the bug doesn't mean PF thought it was high priority, jsut part of a broad review

<oedipus> Bug 10853: HTML5 lacks a verbose description mechanism: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10853

cs: I would be ok with postponing consistency to the next version of html

<oedipus> http://www.w3.org/WAI/PF/html/wiki/Verbose_desc_reqs

mk: consistency is a starting position, but we're not sure that each of these has a workable fallback mechanism. Ensuring that is important.

<oedipus> i had a wiki page on a consistent approach to multimedia objects (including object and embed, but can't find it on any of the wikis

cs: action is to do a gap analysis for each element and propose individual bugs
... MK, do you own that? Can someone help him?

pc: must get this done asap, because ian has Dec 8 deadline

mk: bug triage team will take this on.

<oedipus> Bug 10853: HTML5 lacks a verbose description mechanism: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10853

<oedipus> http://www.w3.org/WAI/PF/html/wiki/Verbose_desc_reqs

<Marco_Ranon> I won't be able to join the meeting for the rest of the day. I might stay on irc tho.

<Marco_Ranon> Bye everyone

<oedipus> FYI EPUB discussion from room 3B is minuted at: http://www.w3.org/2010/11/04-html-wg2-minutes.html#item05

<oedipus> ACTION-194: bound to ISSUE-31 http://www.w3.org/html/wg/tracker/issues/31

<trackbot> ACTION-194 Draft a change proposal to issue 31 to update the definition of img element notes added

ARIA mappings

<janina> scribe: janina

cyns: Let's look at html - aria mapping bugs
... will be asking status

<richardschwerdtfe> what is the call in?

cyns: bug 10450

<richardschwerdtfe> thank you

<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10450

martin: issue relates correct identification tab 1 of 4, e.g.

cyns: reason it's on anchor and not on list is backward compatability

martin: could work even without js

<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10450#c19 - hixie's last comment on bug 10450

sf: this bug resolved

<oedipus> hixie: "The remaining issue in this bug therefore seems to be handled by bug 10919. I'll fix it there and am returning this bug to the FIXED state as per comment 1."

cyns: 10903

<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10903

cyns controversary?

cyns: waiting for resolution of issue-129 before making spec changes

<oedipus> steve logged as issue-129 http://www.w3.org/html/wg/tracker/issues/129

<oedipus> hixie: "Since this is the topic of an ongoing working group issue, I'll wait until the chairs have resolved the relevant issue before making any changes here."

cyns: looking for sense of the room on importance of this introductory text

rich: why's there an issue with having intro text?

cyns: agree it should exist, but what's the importance of pushing for it?

<oedipus> steve's bug report details: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10903#c0

<oedipus> hixie: "Since this is the topic of an ongoing working group issue, I'll wait until the chairs have resolved the relevant issue before making any changes here."

sf: next action is ian's ...

s/ian's/editor's/

<oedipus> bug 10903 is bound to issue-129

<oedipus> issue-129?

<trackbot> ISSUE-129 -- replace or modify the ARIA section of the HTML5 spec -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/129

cyns: bug 10444

<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10444

<oedipus> bug 10444 also bound to issue-129 http://www.w3.org/html/wg/tracker/issues/129

<oedipus> hixie's comment "rejected / see comment 7 [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10444#c7]

cyns: current status?
... we need to escalate this bug?

<oedipus> mjs description of bug 10444 http://www.w3.org/Bugs/Public/show_bug.cgi?id=10444#c0

sf: needs chair attention
... perhaps bugs in issue-129 that no longer need action should be removed from issue-129?

<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10450

cyns: so to remove 10450, we need consensus that we agree on resolution of 10450

<paulc> See http://dev.w3.org/html5/status/issue-status.html#ISSUE-129

<oedipus> hixie: "Status: Partially Accepted / Change Description: see diff given below / Rationale: I didn't add "presentation", but added the others. If there's a use case for presentation that doesn't involve non-conforming use of these elements, please reopen the bug (or file a new one, if the use case applies to other elements also)."

paulc: not seeing 10450 on my issue-129 status page
... go to the table, not the issue itself for current status

<oedipus> http://dev.w3.org/html5/status/issue-status.html#ISSUE-129

cyns: need to update

paulc: issue itself describes the bugs that apply?

cyns: yes, it should

paulc: bug marked fixed, which is why it's not in table

cyns: we agree? seems yes

<oedipus> hixie: "Status: Partially Accepted / Change Description: see diff given below / Rationale: I didn't add "presentation", but added the others. If there's a use case for presentation that doesn't involve non-conforming use of these elements, please reopen the bug (or file a new one, if the use case applies to other elements also)."

cyns: presentation is now allowed everywhere, which is why we now consider 10450 fixed
... without 10444 spec less usable -- strong view

<oedipus> hixie's comment "rejected / see comment 7 [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10444#c7]

paulc: next step should be to write a change proposal

cyns: this is included in the larger change proposal, we need to split it out?

paulc: window closes in 16 days

<oedipus> issue-129 http://www.w3.org/html/wg/tracker/issues/129

cyns: who's writing spec text on this?

sf: text is already there
... we need to see whether we agree

cyns: let's find out now

sf: looking for text ...

<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10450#c6

<Stevef> http://www.w3.org/html/wg/wiki/ARIAIntegration

cyns: let's look at 10448 while steve looks for 10444 text ...

<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10448 Consider broadening the set of allowed roles for command elements

cyns: some elements are commands in menu, and not outside of menu tag

<oedipus> bug 10448 marked as "RESOLVED WONTFIX"

cyns: goal to allow more specific roles when used in a more advanced way
... peopls frequently use anchor or button as basis for more advanced control, so need aria roles to make role explicit
... this is very common in the wild

<Stevef> aria change proposal http://www.w3.org/html/wg/wiki/ChangeProposals/ARIAinHTML5

cyns: we discussed command interchangeability -- client os often don't understand distinction either -- aria provides repair
... editor does not agree with this assessment, our proposal has been rejected
... do we need another separate proposal?

paulc: chairs firmly believe in divide and conquer. an individual bug is very helpful

<Stevef> 3.2.6 Use of WAI-ARIA Roles, States and Properties in HTML http://www.paciellogroup.com/blog/misc/HTML5/aria-html5-proposal.html

cyns: even though we have proposed this change, we should do so again, because the previous proposal was an omnibus?

<oedipus> http://www.w3.org/html/wg/tracker/issues/129

paulc: so, give us a change proposal that deals with all the remaining issues in issue-129

cyns: so, revise our existing change proposal?

paulc: yes

cyns: and remove those that are resolved to our satisfaction?

paulc: yes

<oedipus> the following bugs are associated with ISSUE-129: Bug 10450 -Allow lists to be used as menus or tab sets http://www.w3.org/Bugs/Public/show_bug.cgi?id=10450 Bug 10903 -provide an introduction to wai-aria in the wai aria section of the spec http://www.w3.org/Bugs/Public/show_bug.cgi?id=10903 Bug 10444 -ARIA section does not list elements that have no default role or role restrictions...

<oedipus> ...http://www.w3.org/Bugs/Public/show_bug.cgi?id=10444 related to Bug 10603 -Clarify what default roles UAs may assign to elements not listed in the ARIA section http://www.w3.org/Bugs/Public/show_bug.cgi?id=10603 Bug 10448 -Consider broadening the set of allowed roles for command elements http://www.w3.org/Bugs/Public/show_bug.cgi?id=10448 Bug 10449 -Consider allowing various command-like...

<oedipus> ...ARIA roles for h1-h6 http://www.w3.org/Bugs/Public/show_bug.cgi?id=10449 Bug 10462 -merge ARIA mapping tables and list http://www.w3.org/Bugs/Public/show_bug.cgi?id=10462 Bug 10481 -Default role of <IMG> should be "img" http://www.w3.org/Bugs/Public/show_bug.cgi?id=10481 Bug 10493 -"ARIA restricts usage of this role to one per page" is an unclear statement http://www.w3.org/Bugs/Public/show_bug

<oedipus> .cgi?id=10493 Bug 10592 -"h1 to h6 element that does have an hgroup ancestor" not listed in ARIA section http://www.w3.org/Bugs/Public/show_bug.cgi?id=10592 Bug 10594 -conforming use of various aria attributes not specified http://www.w3.org/Bugs/Public/show_bug.cgi?id=10594 Bug 8000 - ARIA roles added to the a element should be conforming in HTML5 http://www.w3.org/Bugs/Public/show_bug.cgi?id=800

<oedipus> 0 Bug 10478 -modify table, tr and td roles

oedipus, you're listing at least one already resolved and removed -- 10450 ...

<oedipus> bugs associated with ISSUE 129 Bug 10450, Bug 10903, Bug 10444, Bug 10603, Bug 10448, Bug 10449, Bug 10462, Bug 10481, Bug 10493, Bug 10592, Bug 10594, Bug 8000, Bug 10478

<Stevef> 3.2.6 Use of WAI-ARIA Roles, States and Properties in HTML http://www.paciellogroup.com/blog/misc/HTML5/aria-html5-proposal.html

cyns: are there multiple bugs that deal with the organization of this table? can we combine those?

sf: yes

<oedipus> bug 10462 merge mapping tables and list: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10462

cyns: 10444 and 10462 about how to present -- we're proposing them in an alphabetized table
... those two highly related -- perhaps to survey?
... anyone think it better to list things that have no default mapping?

rich: it may be helpful to say why some don't have default mappings
... perhaps that would explain the overall approach

cyns: might that alleviate editor's concerns

rich: don't know

sf: neither i

cyns: rejected over maintanance difficulty
... think we addressing that
... these two roles about readability of the spec
... agree that 10444 without 10462 is a problem, but when taken together there's not that problem
... i'll take the next step on this

cyns 10448 ...

cyns about command

cyns: status is rejected; makes no sense
... a diference in uderstanding purpose of aria
... how do we resolve purpose of aria? this is a consistent problem.

<oedipus> aria: "A WAI-ARIA role is set on an element using a role attribute, similar to the role attribute defined in the Role Attribute [ROLE]."

<oedipus> html5: "Authors may use the ARIA role and aria-* attributes on HTML elements, in accordance with the requirements described in the ARIA specifications, except where these conflict with the strong native semantics described below. These exceptions are intended to prevent authors from making assistive technology products report nonsensical states that do not represent the actual state of the...

<oedipus> ...document. [ARIA]"

rich: authors will do what authors will do
... we need a repair opportunity when they misues native html

artur: there is also used as intended, but aria increases accessibility

paulc: that's the kind of technical rationale that need to be presented in rebuttal
... simply say "we want this changed for the following reason," and give the reason plus the use case.

cyns: and address those in the change proposal

paulc: yes

sf: we've done that

rich: yes, but was ignored

paulc: resolution of a bug?

rich: yes

paulc: so now we're talking about resolution of an issue, not a bug. But, do provide the rationale and use cases, because that helps should it go to survey

cyns: sounds like to take discussion on bug, artur's example, and add to proposal

<Stevef> http://www.w3.org/html/wg/wiki/ChangeProposals/ARIAonanchor

cyns: steve?

sf: would want help with it

<oedipus> @role used on http://www.accessibletwitter.com

<oedipus> what hixie calls "self-styled accessibility experts"?

paulc: a rationale that appeals to expertise isn't acceptable; nor is tha ttitude that "i don't want to do it" from the editor
... provide the rationale and use case of why

<oedipus> hixie has dismissed a lot of input by what hecalls "self-styled accessibility experts" even on things that come from the TF

rich: editor says "show me where it's been implemented"

paulc: should standards lead or follow was the analog of this question at the plennary
... it's the chair's job here to find consensus on this question with this issue

<Stevef> Guiding factors for decisions on ARIA Role use: http://www.w3.org/html/wg/wiki/ChangeProposals/ARIAinHTML5#Guiding_factors_for_decisions_on_ARIA_Role_use:

sf: is this principals approach sufficient, or do we need to go role by role

paulc: sounds systematic and probably will have someone argue against
... looks necessary, but can't guarantee it's sufficient

cyns: a different question -- about effectiveness
... would individual change proposals for individual bugs be more effective?

paulc: whatever gets the november date is the best answer
... suggest concentrate on meeting the deadline, and ask this later
... be clear which text is associated with which bug

<MikeSmith> issue-27?

<trackbot> ISSUE-27 -- @rel value ownership, registry consideration -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/27

cyns: so guiding factor -- particularly on command -- very important because editor isn't understanding why we picked those
... I'll take this one 10448

paulc: main reason for writing an omnibus change proposal is that there's overlap -- let's worry about the disentaglement later
... if proposal says a need for 1, b need for 2 & 3, c needed for 4-6; that's what helps chairs

cyns bug 10449

cyns: roles for h1-h6

rich: we showed how these could be used like buttons ...
... we've seen this from the wild
... our argument is that a header can be repurposed through js; and we need the ability to repair to convey intent

<oedipus> IE8 uses a button defined as a header in "friendly" failure methods

cyns: one side says "authors do this," other side says "they shouldn't."

<oedipus> s/failure methods/failure messages/

cyns: is this rich's proposal

rich: yes
... right now in escalation

cyns: next step is to update proposal for the decision, needs to be done by 21st
... we're updating our omnibus change proposal to include only bugs unresolved, and to insure clear rationale and use cases -- by 21st

<artur> example of using <h3/> for (WAI-ARIA) collapsable menus: http://test.cita.illinois.edu/aria/

cyns: can you do this part by then, rich?

rich: yes

<MikeSmith> trackbot, help

<trackbot> See http://www.w3.org/2005/06/tracker/irc for help

<MikeSmith> trackbot, associate this channel with #html-wg2

<trackbot> Associating this channel with #html-wg2...

<trackbot> Sorry... I don't know anything about this channel

<trackbot> If you want to associate this channel with an existing Tracker, please say 'trackbot, associate this channel with #channel' (where #channel is the name of default channel for the group)

<scribe> ACTION: rich to update change proposal re bu 10449 [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action08]

<trackbot> Sorry... I don't know anything about this channel

action cyns to update change proposal for bug 10448

<trackbot> Sorry... I don't know anything about this channel

<oedipus> actoin: cyns to update change proposal for bug 10448

<oedipus> ACTION: cyns to update change proposal for bug 10448 [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action09]

<trackbot> Sorry... I don't know anything about this channel

<scribe> ACTION: steve to update change proposal for bugs 10444 and 10462 [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action10]

<trackbot> Sorry... I don't know anything about this channel

cyns: 10481.

<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10481

cyns: we want img to map to aria img -- backwards compatibility rationale
... have a hard time understanding editor's response
... who owns?

<scribe> ACTION: steve to update change proposal for bug 10481 [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action11]

<trackbot> Sorry... I don't know anything about this channel

<oedipus> trackbot, associate this channel with #html-wg

<trackbot> Associating this channel with #html-wg...

cyns: 10493

<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10493 "ARIA restricts usage of this role to one per page" is an unclear statement

sf: header, footer ...
... not highest priority

cyns: about about mismatches between numbers allowed by html vs aria?

<oedipus> editor's response to bug 10493: "Status: Partially Accepted / Change Description: see diff given below / Rationale: I just removed the parentheticals altogether, since they were a bit out of place... everything in ARIA has restrictions, it was a bit weird just to call these out specifically."

cyns: if we let this stand, how bad is that?

<oedipus> steve requested clarification, and hixie responded by removing the section

<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10493#c3

cyns: suggest we let this one stand

sf: yes

paulc: clearly say this bug is ok

cyns: also a bugzilla task to accept the resolution

aulc: yes

cyns: 10592
... h1-h6 without ancestor

<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10493#c3 ""h1 to h6 element that does have an hgroup ancestor" not listed in ARIA section"

<oedipus> CORRECTION: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10592 ""h1 to h6 element that does have an hgroup ancestor" not listed in ARIA section"

rich: does h-group take a label?

cyns: no, name from chn

<scribe> ACTION: steve to updage change proposal on bug 10592 [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action12]

<trackbot> Created ACTION-197 - Updage change proposal on bug 10592 [on Steve Faulkner - due 2010-11-12].

<oedipus> steve asked how the semantics of the following be exposed: <hgroup><h1>heading</h1><h2>subheading</h2></hgroup>

cyns: 10594
... hidden, grabed and invalid

<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10594 conforming use of various aria attributes not specified

cyns: do you have proposed spec text?

sf: yes

cyns: editor didn't know what to write -- or that long text belongs here

<scribe> ACTION: steve to updage change proposal for bug 10594 [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action13]

<trackbot> Created ACTION-198 - Updage change proposal for bug 10594 [on Steve Faulkner - due 2010-11-12].

cyns: 10603
... what default roles may be assigned

<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10603

cyns: things missing from the table
... related to 10444 and 10462

sf: says related

cyns: 10903
... an intro
... editor is waiting -- so we add to the proposal -- not controversial
... bug 8000
... this part of commands -- tied to my action
... bug 8000 action to be added to action on 10448

<oedipus> there is a hand-off to the ARIA spec when @role is mentioned in section 3.6.2

<richardschwerdtfe> are we over time?

sf: we need to look at 10478

<oedipus> @role is not included in the list of HTML5 attributes

cyns: you added this to issue-129?

sf: yes

cyns: so, first, do we consider this still open?

<oedipus> hixie on 10478: "Status: Accepted / Change Description: see diff given below / Rationale: I gave up trying to understand this."

sf: i have a problem with th being turned into a button

cyns: but it seems similar to turning headings into buttons. are we consistent?

sf: so can have role on any table element -- is that ok?

cyns: my preference

rich: people will simply do it

cyns: think there are legit scenarios for it
... also undermines our argument on headings to take that up differently
... we leave this closed.

rich: i remember bug date, but not this date

cyns: steve, are you ok?

sf: yes
... most is already done

cyns: i will be stricter with myself and rich than with steve. we should have draft next week

rich: let's meet early next week

cyns: i will writ emine off line, and suggest email by friday next

<oedipus> rich, http://lists.w3.org/Archives/Public/public-html/2010Sep/0136.html

<oedipus> rich, http://lists.w3.org/Archives/Public/public-html/2010Sep/0125.html

<oedipus> timeline to last call: http://lists.w3.org/Archives/Public/public-html/2010Sep/0074.html

<richardschwerdtfe> what is the passcode?

<oedipus> 26635

<richardschwerdtfe> i am on

Canvas

<MichaelC> scribe: MichaelC

fo: 2 proposals - imagemap, and DOM

MS supports DOM, implemented in IE9

anybody else?

rs: filed a bug with Firefox, but not in yet

ds: <interrupted>

fo: so looks like support centering around that

<dbaron> trackbot, associate this channel with #html-wg2

<trackbot> Associating this channel with #html-wg2...

<trackbot> Sorry... I don't know anything about this channel

<trackbot> If you want to associate this channel with an existing Tracker, please say 'trackbot, associate this channel with #channel' (where #channel is the name of default channel for the group)

<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibilitynonav

a second mode for this DOM

<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/Map4NotAdom

things sent to the DOM but not rendered

2 DOM modes, testing scariness

leads to questions like with iframe, do you go into that iframe or not?

<oedipus> ISSUE-74: http://www.w3.org/html/wg/tracker/issues/74 Canvas Accessibility

<trackbot> Sorry... I don't know anything about this channel

<oedipus> http://dev.w3.org/html5/status/issue-status.html#ISSUE-074

so need to work out what goes into the DOM

can specify what goes in, or what doesn't go in

might want to look at tricky situations where a canvas object relates to a UI feature

e.g., checkbox in <canvas>, is toggled by AT, should receive a click event

how do we handle event messaging in the shadow DOM?

need to discuss, but need more people involved

pc: what's path to addressing this?

rs: file a bug about what HTML elements are allowed in the shadow DOM

pc: what's the process?

<oedipus> http://dev.w3.org/html5/status/issue-status.html#ISSUE-074

rs: <scribe couldn't parse>

pc, cs: file bugs?

fo: need a bug, a change proposal ultimately needed

need spec text (more than 3 lines) that describe how to address scenario

cs: this is a sub-issue of the canvas issue

pc: we've allready called for objections to ISSUE-74 and ISSUE-105

rs: result?

<oedipus> ISSUE-74 http://www.w3.org/html/wg/tracker/issues/74 Canvas Accessibility

pc: not issued yet

<oedipus> http://www.w3.org/2002/09/wbs/40318/issues-74-and-105-objection-poll/

<paulc> http://www.w3.org/2002/09/wbs/40318/issues-74-and-105-objection-poll/

cs: assuming we accept shadow DOM, <something about options>

<something about imagemap or nothing>

rs: imagemap nice to have

but not needed

cs: assuming we choose DOM over other two <interrupted/>

rs: need to pick the options in the straw poll

pc: which option before the WG is the "use the shadow DOM"

cs: it's the null change proposal, refine existing text
... assume this will be the WG decision

so question is how to refine that into the existing issues

rs: what operates inside the DOM and what functionality from Canvas 2D to support magnification

fo, cs: table that

cs: is this idea part of what has been surveyed?

<oedipus> http://www.w3.org/2002/09/wbs/40318/issues-74-and-105-objection-poll/results

rs: nothing in the survey speaks to defining the limitations of the shadow DOM

cs: meaning it would be a post-LC issue

<oedipus> this was definitely raised as an ISSUE before LC

rs: arguably part of ISSUE-74

cs: checks with Paul

pc: don't know what chair decision would be

rs: we should <scribe got distracted by private msg>

pc: there are LC bugs we're processing in advance, so don't be too fussed about status of the bug

<oedipus> tracker, pointer

<oedipus> tracbot, pointer

<oedipus> trackbot, pointer

<trackbot> Sorry, oedipus, I don't understand 'trackbot, pointer'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

<scribe> ACTION: frank to file a bug about arriving at spec text that speaks to complexities of how DOM elements behave in the shadowl DOM beneath the canvas [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action14]

<trackbot> Sorry... I don't know anything about this channel

fo: --- canvas with text entry ---

options are 1) shouldn't do it

2) describe the multitudinous issues

3) solve some of the problems but not completely

think third option doesn't help users nor implementers

and second is really hard

<oedipus> plus 1 to FO option 2 because people are already building RTEs with canvas (skywriter, lively project, etc.)

rs: we could say no text entry, but can't deliver without addressing the issues

someone will try it

fo: who does it besides bespin?

ds: people use canvas to be innovative

<oedipus> bespin is now skywriter -- there is also oracle's lively-project

fo: which pushes us into describing the issues, a lot of work

ds: can we just leave that to authors

give them pointers, tools, apis?

<oedipus> http://labs.oracle.com/projects/lively/ and

<oedipus> https://bespin.mozillalabs.com/

<oedipus> RTEs that use canvas

fo: let's say shadow DOM interacting with screen reader and <something>

pretty straightforward in basic case

<oedipus> correction, bespin has been rebranded "skywriter" http://mozillalabs.com/skywriter/

with text entry, developer has to handle all kinds of events

<oedipus> however, https://bespin.mozillalabs.com/docs/ - still linked from skywriter pages

ds: or hook into platform things

fo: consider Japanese input, that has symbol prediction

how would you tie that to canvas element

or, consider spell check, form autocomplete,...

these aren't even just a11y issues

cs: in a standard control you'd have access to platform API in imperative manner

don't have that in script

fo: this is all addressable, but not within current timeline in a good way

ds: maybe some of these aren't a11y specific

mk: if shadow dom rich enough, can incentivize authors not to use script

<oedipus> plus 1 to martin

fo: there are things you have to send to screen reader that you don't send to screen, e.g., cursor offset

rs: there are some things we need to sync with UI anyway, such as spelling

because they're part of HTML

<oedipus> canvas accessibility discussion at PFWG f2f 2010-01-01 (member-confidential) http://www.w3.org/2010/11/01-pf-minutes.html#item08

cs: that's native to HTML 5?

rs: yes

cs: it requires spelling and grammar checking in contenteditable?

rs: yes

fo: what do people think of the work load?

rs: contenteditable functioanlity needs to be reflected

and magnification (bug exists)

cs: how much time to do this work?

rs: API isn't the difficult part to spec

finding limits is a big part of the problem

and finding how to expose things like spelling

can get caret info which helps sync

fo: what info do you want to get re spelling/

rs: need existence and location in the subtree

<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibility

cs: how much time to do this work?

<oedipus> avoiding redrawing focus ring: http://lists.w3.org/Archives/Public/public-html/2010Jul/0219.html

rs: implementation a challenge

but 3 weeks to do spec

maybe longer if need to find out what can be done with DOM subtree

fo: <scribe distracted>

cs: how long to spec to point your testers are happy?

fo: don't think it can be done by last call deadline, that's implementable

think we should look at post-LC vehicle to address these concerns

also won't have implementers on board in time for LC

steps of getting spec text, getting agreement, etc., we're only at beginning of this process

cs: can it be modularlized/

rs: canvas 2d by april?

pc: all documents on same scheudle

<oedipus> http://dev.w3.org/html5/canvas-api/canvas-2d-api.html

can find WG position

in email

mc: we could put in "don't do text editing" for LC, and solve the problem during the LC period

cs: or html.next

<eliot> Current canvas 2D spec: http://www.w3.org/TR/2010/WD-2dcontext-20101019/

<oedipus> bugs currently associated with HTML Issue 74: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7011 and http://www.w3.org/Bugs/Public/show_bug.cgi?id=7404

ds: message that you can do it but don't have support from us, on your own

rs: will need caret, focus ring, select

pc: canvas 2d context is in the set of documents going forward with html at LC

ds: don't see how we can lock authors out of this design pattern

cs: can write a WCAG failure

fo: how would you solve?

ds: agree with you on difficulty and timeline

cs: a WCAG failure is easy to do

we could do a sample application to show how to use contenteditable + canvas to get something kinda good

mk: concern that contenteditable div not performant enough

<oedipus> canvas-based rich text editor projects: skywriter (was bespin) http://mozillalabs.com/skywriter/ and lively http://labs.oracle.com/projects/lively/

cs: but that's not our primary concern - just giving options

(another is "use HTML")

this could be a WCAG technique

<oedipus> authors shouldn't have to turn to WCAG in order to do canvas accessibly

mc: are we deciding never to solve this, or to solve it later?

and what do we do pre-LC

fo: think we're commiting to solving, but after LC

not sure what we do pre-LC

mc: so <interrupted>

pc: we could ask in the LC status section what reviewer priority is on this issue

can be hard to get WG to agree to this

but I can just take over that section

fo, cs: +1 (each)

fo: that allows us to say "here are the problems we've identified"

pc: have done this in situations where we weren't sure of appropriate direction

cs: that could help set priority for when / whether to address post-LC

pc: having a bug that clearly describes problem gives a hook for that

in the status section

<group looks for whether there's a bug>

<scribe> ACTION: rich to file a bug about accessible rich text editing with canvas [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action15]

<trackbot> Sorry... I don't know anything about this channel

pc: yesterday question of doing profile(s) of HTML 5 came up

an HTML 5 environment with only script and canvas was a compelling idea

and that's a use case for this text entry issue

connecting the dots....

<oedipus> timed track discussion 2010-11-04 http://www.w3.org/2010/11/04-html-wg-minutes.html#item10

<oedipus> limited devices and profiles: http://www.w3.org/2010/11/04-html-wg-minutes.html#item11

rs: <scribe missed, some sort of +1>

mk: 1.5 years ago this came up at SXSW

<kliehm> mk: "canvas is like having an APll

<kliehm> mk: Apple II in the browser"

<oedipus> shouldn't limit to WCAG -- should be in HTML5 spec

<kliehm> s/APll//

<oedipus> post LC1 pre LC2

<oedipus> minus 1 -- don't think should pass off to WCAG entirely -- canvas implementors will be looking at the 2d-canvas api

sf: ask about caret etc.

rs: not subject to the proposed resolutions

pc: the formal decision hasn't been issued yet

cs, rs: <something> didn't make it to the survey

s/<something>/caret/

pc: but focus rectangle was surveyed

RESOLUTION: in LC version of spec, have a warning about using canvas for text editing (absent a text field), and create WCAG techniques and failures related to this
... work on a full solution to the text editing in canvas problem, and get into the spec at some future point

fo: --- drawFocusRing ---

asks about current status

rs: we originally included coordinates for the focus ring

<something else>

cs: will it pick up OS settings?

rs: yes

a couple threads still open on status

cs: does the spec have everything it needs for focus?

rs: no, caret and focus ring are confounded

doesn't account for blink rate

cs: bugs?

rs: one bug with a proposal

cs: we asked about a bug for caret; didn't ask for focus ring, may need one for that also

rs: <looking>

no actual defect

<scribe> ACTION: Rich to file defects for features necessary for focus ring and magnification [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action16]

<trackbot> Sorry... I don't know anything about this channel

<eliot> Current canvas 2d api spec: http://www.w3.org/TR/2010/WD-2dcontext-20101019/

<confusion over different versions of canvas spec>

<Stevef> Provide accessibility information for driving screen magnifier tracking of focus rectangle and caret selection and to prevent blink rate seizures http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibility

<scribe> ACTION: Eliot to indicate that old editors' draft of canvas is out-dated and reference new one [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action17]

<trackbot> Sorry... I don't know anything about this channel

fo: getcursorblinkrate should be tied to text entry, not focus management

should include this in the text entry bug

rs: along with grammar checking?

fo: yes

<oedipus> note that SteveF said "Provide accessibility information for driving screen magnifier tracking of focus rectangle and caret selection and to prevent blink rate seizures http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibility"

fo: --- any other issues? ---

ds: we haven't scraped bottom of barrel, but won't find all possible issues before LC

mk: should we inventory examples of canvas uses to get ideas of issues?

fo: IE team doesn't enumerate everything on the web, answer is always "enough to matter"

there are three types of controls: <missed>

s/<missed>/1) show info such as labels; 2) toggles for something simple, like checkboxes and single-selection lists; 3) text entry, with lots of complex nuances

those are the basic building blocks of any UI, even when they add up to something complex

mc: not convinced all can be reduced to that, but maybe

mk: for user interaction, it can be reduced that far

fo: no matter how swanky / spiffy the control, it still boils down to those types of actions

<oedipus> developer should get info from 2D-canvas-api portion directly, not be pointed to WCAG

<oedipus> paulc, according to the agenda, the DRM session has been cancelled

<oedipus> are we officially on break?

<oedipus> resuming at top of hour?

<oedipus> thanks to all the scribes!

<paulc> test

Applicable specifications

applicable specs

<adrianba> ISSUE-140?

<trackbot> Sorry... I don't know anything about this channel

<anne> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9178

<paulc> Bug 9178?

<anne> trackbot, associate this channel with #html-wg2

<trackbot> Associating this channel with #html-wg2...

<trackbot> Sorry... I don't know anything about this channel

<trackbot> If you want to associate this channel with an existing Tracker, please say 'trackbot, associate this channel with #channel' (where #channel is the name of default channel for the group)

<noahm> ISSUE-140: clarify the applicability of the term "conforming document" in cases where "applicable specifications" had been used to augment or change the base HTML5 specification

<trackbot> Sorry... I don't know anything about this channel

<dbaron> trackbot, associate this channel with #html-wg2

<trackbot> Associating this channel with #html-wg2...

<trackbot> Sorry... I don't know anything about this channel

<trackbot> If you want to associate this channel with an existing Tracker, please say 'trackbot, associate this channel with #channel' (where #channel is the name of default channel for the group)

<dbaron> trackbot, associate this channel with #html-wg

<trackbot> Associating this channel with #html-wg...

trackbot, int

<trackbot> Sorry, MichaelC, I don't understand 'trackbot, int'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

trackbot, init

<paulc> http://dev.w3.org/html5/spec/Overview.html#extensibility

<anne> ISSUE-140

<anne> ISSUE-140?

<trackbot> ISSUE-140 -- clarify the applicability of the term "conforming document" in cases where "applicable specifications" had been used to augment or change the base HTML5 specification -- raised

<trackbot> http://www.w3.org/html/wg/tracker/issues/140

<hsivonen> http://www.whatwg.org/specs/web-apps/current-work/#other-applicable-specifications

<paulc> Noah: I raised the bug under ISSUE-140.

<paulc> scribenick: paulc

Noah: My concern is about conformance terminology.
... Let's say I have an HTML document that does not use any extensions. The HTML5 spec says what is conforming.
... Let's say someone else writes an "applicable spec" that is incompatible since it changes what is required.

<hsivonen> The "Preset" menu on http://validator.nu/ is relevant

Noah: I am asking that if a document that is only conforming if there is an "applicable specification" then I should have to say this when I give you the document.

henri: I agree with what Noah says. If you look at validator.new its configuration file controls what applicable specs apply during validation.

<noahm> Does the spec require what the validator does?

<dbaron> s/validator.new/validator.nu/

@dbaron: thanks

henri: Since ARIA is included then that case could be changed.

<noahm> I'm happy for you to deal explicitly with a handful of edge cases like SVG and Aria as you see fit.

<noahm> I'm just suggesting that the HTML5 spec should be unambiguous: you can't say "my doc conforms to HTML5" if it actually requires extensions to conform

henri: the html5 does not give the SVG validation rules so you need to tell the validator what SVG to use.

<shepazu> the SVG WG would be happy to help review any tests that involve SVG

Noah: I want to spec to require what Henri described how the validator.nu work.

Maciej: I want to mention scope of applicable specification clause.
... you can add elements to make them conforming but you cannot change existing elements.
... I retract my statement but this is different than it used to be.

DBaron: Restating: Noah wants "conforming HTML5 document" and then some other phrase when an "applicable spec" is involved.

<Zakim> noahm, you wanted to ask Henri: it's great that the validator does this, but where does the spec requires this

If it contains ARIA is if "conforming HTML5 document"?

Noah: depends on what the spec says. Just say it clearly in the spec.

Should we move the sentence:

As far as conformance goes, what matters in a particular community is what that community agrees is applicable.

Henri: The A.S. clause is trying to say in words what the validator.nu has been doing in practise.

<noahm> NM: My main priority is that I want the term "conforming HTML5 document" to be defined as referring only to the unextended specification.

<adrianba> +1 to what henri says - it wouldn't hurt to make it explicit in the spec instead of implicit

<noahm> NM: I am somewhat flexible as to what terminology would be used for documents that conform only to the extended specifications.

Henri: If you invoke the A.S clause then your statement should say something different than if you did not.

<noahm> As best I can tell, I am in complete agreement with Henri, and I note that I have no strong concern as to how ARIA, MathML or SVG is treated, as long is it's clear one way or the other.

Henri: This agrees with Noah's ask.
... Do we need a more formal way of negotiating this.

<noahm> I don't agree that moving the last sentence of the note to be normative achieves the goal.

Julian: The spec needs to be clearer about what a conforming document is ie about SVG, MathML or ARIA are in or out.

<noahm> I think the right way to do it is adding to the definition of conforming document something like: "the term 'conforming document' applies only to documents that conform to this specification in the absence of additional applicable specification extensions".

Julian: We should ahve a term for a document that conforms to HTML5 spec + SVG + Mathml

<noahm> I also think the "vendor neutral" term is sort of goofy, but decided not to fight that battle if you all are happy.

paulc: How do I know what A.S are being used when I receive a HTML5 resource.

henri: the situation is similar for "some version of xml" (search for this)

paulc: this leaves an extension point in the spec

henri: this is the why spec does not give a fixed normative reference to the A.S.

paulc: this is like have a forward looking normative reference (not dated) in the reference section.

<Zakim> noahm, you wanted to talk about media types

Julian: The validator case henri mentioned is really important.
... But others out there use the phrase "conforming HTML5" documents to mean something different and pre-determined.
... We need something in the spec that describes some of the case described by validator.nu

<anne> the additional bit we add is that conformance depends on who you ask

<anne> some will accept microdata as app. spec., some won't

<sicking> My proposed new text:

<sicking> When vendor-neutral extensions to this specification are needed, either this specification can be updated accordingly, or an extension specification can be written that overrides the requirements in this specification. When a community applying this specification to their activities explicitly agrees that they will recognize the requirements of such an extension specification, it becomes an...

<sicking> ...applicable specification for the purposes of conformance requirements in this specification. As far as conformance goes, what matters in a particular community is what that community explicitly agrees is applicable.

<sicking> (green) Note: Someone could write a specification that defines any arbitrary byte stream as conforming, and then claim that their random white noise is conforming. However, that does not mean that their random junk actually is conforming for everyone's purposes: if someone else has not explicitly agreed that that specification does not apply, then the byte stream is not conforming to them,...

<sicking> ...and is just random white noise.

<anne> you should write a CP

<Julian> s/vendor-neutral//

<noah> From RFC 2616L

<noah> When an entity-body is included with a message, the data type of that

<noah> body is determined via the header fields Content-Type and Content-

<noah> Encoding. These define a two-layer, ordered encoding model:

<noah> entity-body := Content-Encoding( Content-Type( data ) )

<noah> Content-Type specifies the media type of the underlying data.

<noah> Content-Encoding may be used to indicate any additional content

<noah> codings applied to the data, usually for the purpose of data

<noah> compression, that are a property of the requested resource. There is

<noah> no default encoding.

<noah> This says nothing about processing.

<noah> So, I respectfully disagree with Henri's reading of the definition of Content-type.

<noah> The word processing doesn't occur.

<anne> s/extensions/vendor-neutral extensions/

<anne> ftfy

<anne> noah, it does not quite align with the vision you can send HTML as text/plain to display it as raw text though

<anne> noah, cause what that is saying is that it is no longer HTML, or am I missing something?

<Julian> (I believe we should stay away from the term "vendor-neutral"; it's not helpful here)

<anne> (it is, because vendor-specific extensions are to be done differently)

<noah> Content-type is NOT about code paths. It is just a statement about the interpretation that the Server intends to be applied to the bits.

<anne> interpretation is a code path no?

<noah> I strongly urge that you ground this discussion in RFC 2616, not in other assertions of what Content-type is.

<anne> text/plain -> go here, text/html -> go there

<oedipus> http://www.ietf.org/rfc/rfc2616.txt

<noah> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.17

<small>

<dbaron> ScribeNick: dbaron

<u>, <small>, etc.

hsivonen: There's a wide range of how semantic presentational formats can be. A PNG gives you a bitmap; a PDF gives an exact bitmap with a bit more abstraction around resolution.
... Then there's HTML, and DocBook that has a lot more that doesn't describe presentation but instead describes the role of stuff in the document.
... And there's TEI (?) that tries to describe roles even more precisely in terms of semantics.

<noahm> Julian (and others): if you're interested in the proper registration of the Content-type, then in addition to RFC 2616 and pertinent IANA stuff, you might want to read the TAG's Finding "The Self-Describing Web". http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html

hsivonen: When HTML started, there were some elements for marking up stuff inside a paragraph, e.g., to be italic or underlined, and this seemed to be closer to the presentational end of the spectrum than to the semantic end of the spectrum.
... There was a belief that being more semantic was better because it allows repurposing the content in different ways.
... The assumption was that more semantic was better, and presentational was worse.
... Here I am making an inference from what I see in old HTML drafts; I wasn't there.
... First there existed <i>, and then since it was seen as presentational and presentational was worse than semantic, a bunch of other elements were created for different use cases, e.g., <em>, <var>, <cite>.
... In practice, as implemented in browsers, and even as implemented for accessibility purposes (at least as far as Raman said on the list sometime), these are for all purposes in practice synonyms for italics.
... There isn't much software that makes good use of these semantics beyond the thing that sets this thing apart from its environment in terms of style.
... The concept that presentational is worse than semantic has been advocated over the past decade, a lot.
... It's hard to take the position that, ok, we didn't mean that, and presentational is now ok.
... But we see that these elements that are called presentational within a paragraph are still being used, so we can't say they'd be non-conforming, which would be silly from a practical point of view.
... The approach HTML5 adapts is that some of these old presentational elements are given semantic fig leaves that give us a way to pretend they are semantic without changing in any way the way software handles them.
... It's a way of saving face that allows us to keep them conforming so nobody is inconvenienced but we keep the semantic better than presentational doctrine.
... The <i> element has been made conforming in HTML5 by giving it a semantic fig leaf, but the <u> element has not, and is nonconforming.

<oedipus> they are "italicized" by a screen reader in response to the markup -- a user should be able to use cite and em and have them spoken with distinct voice characteristics -- if the AT is merely screen scraping, then anything rendered in italics will be identified as being italicized, but the benefit of <cite> as a semantic demarcator is far superior to simply interpreting everything rendered as...

hsivonen: They are similar in nature: both used for applying formatting inside a paragraph in the way that normal people think about formatting.

<oedipus> ...italics as simply italics -- there are semantics behind cite, var, em

hsivonen: ...

<oedipus> hsivonen, re accessibility and italics please see my IRC comments above

hsivonen: If we have <i> but don't have <u>, that's kind of arbitrary. kennyluck filed a bug saying that in chinese you underline certain things. That bug was closed saying that the semantic is already covered by this other stuff, so we don't need the <u> element.
... However, the <u> element exists already, and does this thing that is easy for authors to think about, instead of having to express "I want to express a proper noun" and then say it's underlined.
... You can style the <i> element in CSS to make it underlined, but it's not reasonable to tell a Chinese author to, instead of using the <u> that works they must use an <i> and restyle it.
... Flipping it around for a European author would feel unreasonable (and saying to use <u> for italics).
... It seems it doesn't help the most people to say that these old presentational inline elements are invalid when they are interoperably implemented, and the casual user thinks in terms of wanting this stuff to be italic, bold, underlined, etc.
... There's a counter-argument: if you're translating from Chinese to English or vice-versa, then you need to change the element as part of the translation process, and it would be semantically proper to not have to change the elements when you change the text.
... But if you have ruby in Japanese and you translate to English, you need to change the ruby.
... So this is my argument that these things should be valid. <small> exists and is interoperably implemented.
... When we have these inline elements, we can do accessibility and non-CSS processing on the content; if we have spans and CSS then we need CSS computed style to do the same processing.
... I'm not arguing for adding any new of these inline elements, but since they exist, have use cases, are easy to understand, and already work, we should say it's ok to use them and we don't need to pretend they don't exist.

<Zakim> MichaelC, you wanted to say that semantic elements, while presented a certain way in mainstream browsers, still have different meanings that are used in transformations, custom

MichaelC: I agree with some (> 50%) of what you said.
... 70-ish
... A couple points that didn't sit well with me:
... (1) You talk about how all of these semantic elements are presented the same way; there are some that are handled differently by some software.

hsivonen: Which software?

MichaelC: I could take an action to provide list later.
... There are bigger use cases for semantic elements than I thought you acknowledge.
... I agree that people author according to visual style. I want to find a way to get authors who author visually to end up with semantic content.
... But I think we need to end up with the semantic content available and encourage them to end up with it.
... Those were just a couple addition points I wanted to give.

cynthia: I agree the inconsistency of <i> and <u>; I'd want consistency. My preference would to deprecate them in favor of more semantic elements or <span> where there are no semantics.

hsivonen: Isn't span worse for accessibility? Doesn't that then require figuring out more?

cynthia: I see <i> and <span> as equivalent.
... The <i> element says it's italic but not why; the AT can tell you it's italic.

<oedipus> just because something is rendered as italics visually, does not mean that it should be identified as italics by a screen reader or other AT, but should be triggers for voice characteristics changes so 1 can tell something emphasized from something cited

anne: The AT can tell you it's italic==different.

maciej: Editing tools can (1) add <span> and style (2) insert <i> (3) insert <em>; <i> seems the least bad of these three.

cynthia: I agree having these inconsistent is strange.

hsivonen: I care less about <small> than <u>.

cynthia: The semantic issue: I don't think <em> is much better than <i>; I think the foreign language case may be useful to know that it's italic because it's French or because it's a proper name.

<MikeSmith> http://dev.opera.com/articles/view/mama-phrase-block-list/#phrase

hsivonen: The foreign-language semantic is in the lang attribute.

<MikeSmith> Opera MAMA report on Phrase elements

hsivonen: Going back to what maciej said: Dreamweaver... says in WAI guidelines that things are more accessible if "italic" command is bound to <em> and "bold" bound to <strong>; this is now implemented in Dreamweaver, Wordpress, so now you can't infer semantics from <em> or <strong> because the author just made the "make this italic" gesture.

<MikeSmith> the <u> element is used as often as <em> in existing content

hsivonen: You can no longer infer a difference from <i> and <em> for accessibility from random Web content.
... ... because all these content-generating tools have been generating <em> for this UI gesture.

<oedipus> hsivonen, yes you can -- if you set one voice characteristic for <i> and another for <em> there IS a difference

cynthia: I don't think <i> is a good solution to providing a solution for why it's italic.
... I'd like to see the UI ask you why it's italic.

maciej: I think a prompt after the "italic" command is a non-starter for usability.

cynthia: That doesn't mean the right solution is to replace <em> with <i>.

<oedipus> minus 1000 for hsivonen's point on a11y

<oedipus> it is easier to un-italicize content styled with CSS than it is to undo a hard-coded <u>

<oedipus> make that <i>

hsivonen: I'm not suggesting that. I'm not saying that people shouldn't mark up foreign languages with the lang attribute. I'm just saying the <u>, <i>, and probably <small> should be conforming; people who want to add more semantics should still be able to do that.
... Instead of us prescribing the one way to do that, we should allow the other.

cynthia: I'd tend to agree with you for <i> and <u>; I think <small> not used much in the wild.

MikeSmith: Take a look at the data I put in IRC.

<anne> oedipus, if it is easy to set a voice you can just set the same voice as for normal content so I'm not sure your -1000 applies

MikeSmith: <small> used more than <sup>, <abbr>, ..., combined.

[repeating of data in link]

cynthia: As far as outcome, I think we're not far apart, but I think we largely agree on what to do.
... I put the bug in but didn't escalate it.

<oedipus> anne, hsivonen, kennyluck, just because something is rendered as italics visually, does not mean that it should be identified as italics by a screen reader or other AT, but should be triggers for voice characteristics changes so 1 can tell something emphasized from something cited

MichaelC: I think the use cases you're asking for are, I think, more important than you think.
... I think we could treat ... as WCAG as conformance errors / ???, but I don't think that will be universally accepted in a11y community.

<mjs> oedipus: would you like to type your comments into IRC?

hsivonen: I don't notice gregory citing any particular software products.

<Zakim> oedipus, you wanted to say a user should be able to use cite and em and have them spoken with distinct voice characteristics--if the AT is merely screen scraping, then anything

MichaelC: He uses JAWS.

hsivonen: Does it render them differently by default?

<oedipus> and NVDA and Orca

MichaelC: Not sure default is that important.

cynthia: Highly configurable.

<oedipus> by default, everything is vanilla

<oedipus> the user chooses what voice characteristics to change

[mjs reads comments from oedipus above]

<oedipus> out-of-the-box everything is vanilla -- the user has to choose an overlay or tweak the settings herself

<mjs> oedipus, let us know when you are done please so I can stop reading

cynthia: Point of clarification: Do users typically choose an overlay, and do the common overlays include different voices for the different semantics?

<oedipus> for example, JAWS has "internet rent a crowd" which assigns different voices and voice characteristics to what JAWS can pick up from the DOM

<hsivonen> oedipus, so if <em> and <i> are different for you, how do you know whether the user had an authoring tool that bound <em> to the "italicize" command?

<oedipus> overlays include different voices for different semantics -- it is up to the user -- some users like multiple voices, others prefer one voice with pitch changes or an earcon (to indicate heading level, for exammple)

fantasai: I don't know about assitive technology, but I know book titles are rendered differently from emphasis in Chinese, so for someone who's writing in Chinese, it wouldn't make them to use <i> or <u> for these use cases. If they wanted to they could use the semantic elements and insert punctuation with generated content, or insert the punctuation themselves directly. But they are sometimes styled differently.

hsivonen: I wasn't suggesting taking <cite> away from authors. But as much as we say it's valid for Chinese authors to use puntuation directly in content, it's valid for authors to use the <u> element.

[mjs reads responses from oedipus]

<oedipus> hsivonen, if i have <em> set to trigger a voice characteristics change, it won't do anything for <i> -- UNLESS i set a global "everything that is in italics no matter why should be expressed as italics" setting (such things exist)

<mjs> thanks, oedipus, moving on with the queue now

hsivonen: I can see the point that Gregory can configure the AT, but logically there isn't any quality signal in the difference between <i> and <em> when some tools bind the italic-command to <em>, so being able to style them differently in your user-stylesheet-equivalent mechanism doesn't tell you much.
... Doesn't tell you anything about author's intent beyond that they pressed Cmd+I in Dreamweaver or another application.

<oedipus> hsivonen, i have different voice characteristics settings for <u> than anything that appears in a string encased in &#34; ... &#34;

r12a: Two comments:

<oedipus> s/settings for <u>/settings for <q>

r12a: First is parenthetic: in Dreamweaver I think you have to set an option to make it use <em> instead of <i>. What follows on from that is that I actually chose to do that, and I might later choose not to do that, and I actually do use <em> to mean emphasis and I'm careful about how I write my code.
... In the wide world you might not be able to rely on authors to do the right thing all the time.

<oedipus> hsivonen, so if i encounter something using a quote character it is spoken differently than if it were encased in a quote tag

hsivonen: But the reader doesn't know if the document came from you. But it's useful from you for your CSS purposes. I think it's good for you to hedge your own authoring practice against your own future styling changes. I think CSS is now popular enough that we don't need to make these elements nonconforming to market CSS.
... It doesn't follow that we should say to those authors who don't want to in advance prepare themselves against their future styling changes is nonconforming.

r12a: I agree; just saying some people will do it right and some won't.
... (2) The main thing I wanted to say is that, I think, the main question is whether we deprecate <small> and <u>.

hsivonen: Right now different status for different elements.

<anne> <a>!

r12a: There's i/em and b/strong pairs; what's the semantic equivalent of strong?

hsivonen: <ins> for American lawyer case; nothing for Chinese proper noun case.

<anne> s/of strong/of u/

fantasai: My understanding of the HTML spec is that <i> no longer means italics; it means this bit of text is set apart from the surrounding text in a presentationally-distinguished way. It could be by italics or by something else.
... I don't see how that definition is any different from what's being proposed for <u>: same definition but different default style.

maciej: Traditionally underlines and italics are used for default things.

<oedipus> hsivonen, <em> and <i> are set to produce different voice characteristics because i set them to do so -- either way, i get the message that this string of text is set apart from the other for a specific reason

s/default/different/

hsivonen: You have three ways to set text apart from surrounding text (and they also make things different from each other).
... But in practice people think in terms of italic, bold, and underline. I sidestepped what the semantics should be; I think we should allow this.

kennyluck: I raised this bug. I discussed this with Chinese friend; think <b> might be a solution.

<hsivonen> http://www.helsinki.fi/~rkosken/kirjallisuus/pukuhistoria.html page created in Dreamweaver and edited in another version of Dreamweaver after upgrading

kennyluck: I'm not saying I have a strong opinion but I want to know which element I should use to style ???, or should I just use a <span>?

<kennyluck> s/???/proper noun/

<fantasai> kennyluck, read the definitions of <b> and <i> in the HTML5 spec

cynthia: If the reason for keeping these is ???, that seems like a valid reason to me. Inconsistency also seems bad.

<fantasai> kennyluck, they mean sligtly different things

hsivonen: One reason <u> element is out is that hyperlinks are underlined so Hixie thinks <u> is bad.

Julian: I think this WG has spent countless man-years discussing whether something should be conforming or not. I think it's pointless to make things nonconforming that user agents will have to implement anyway. If we can just make a few noncontroversial things conforming and get closer to finishing.

<oedipus> kennyluck, <b> is about style - not conveying importance, as your quote shows -- presentation should be separate from content

cynthia: Can I withdraw the bug after someone else escalated it?

maciej: Anyone can escalate, so it's escalated, but there will be a call for escalated.
... The bug on <small> was escalated.

anne: Allowing people not in the group to escalate things but not letting them write a change proposal seems like a bug in the process.

maciej: We allow people not in the group to escalate since it's the way to appeal the editor's decision to the WG. If nobody in the WG cares enough to draft a change proposal then it'll get dropped.

anne: Can we instead require someone in the WG to agree before it gets escalated?

cynthia: The only overhead is that it starts the clock for change proposals.

<oedipus> kennyluck "Authors are encouraged to consider whether other elements might be more applicable than the i element, for instance the em element for marking up stress emphasis, or the dfn element to mark up the defining instance of a term."

maciej: One useful framework for thinking about this is that there are two models of authoring for creating rich text to publish as HTML. One model is that you're really thinking of it as HTML / Web Content, and you're thinking about markup, etc. The other is casual, user-generated content (email, Word), where the mental model is hitting the bold or italic button.
... We should support the semantics, but we also need to support the casual user-generated content, and it's unreasonable to ask authors to do too much in order to put some content up on the Web.
... This idea that everything has to be semantic has been a disservice to this sort of users; they end up using lots of spans with CSS, or inappropriate semantics.
... This is sort of like punctuation; we don't have a sentence tag, we let people type a period.
... I stronly agree with having the phrasing elements. If we have to invent a semantic fig leaf, that's ok, but I'd prefer not to.

cynthia: For some of those scenarios there are tools that can assist people in being more semantic, such as clickable styles. I'm fine with those being at a tool level. Mostly I filed the bug because it seemed like there were inconsistencies.

<oedipus> but we should have a L (line) element so when snippets of <code> are displayed, the semantic integrity of a line of code (or a poem) is retained, no matter the manner of rendering (no more code in PRE with multiple <br>)

cynthia: Michael, do you feel strongly about keeping this stuff?

MichaelC: I feel strongly about not wasting a whole lot of time on little issues like this. I think it's been useful to share our ideas on semantics.

<Zakim> MichaelC, you wanted to say it's useful for this opportunity to discuss what we separately mean by "semantics" etc.; but then we can move away from lots of group times on fiddly

hsivonen: I'd like to give some background about the page I linked to. This is a page my mom wrote in Dreamweaver; it lists a bunch of books for her students to read.

<mjs> repasting referenced URL: http://www.helsinki.fi/~rkosken/kirjallisuus/pukuhistoria.html

<oedipus> <code><l>sample code line one</l><l>sample code line two</l></code>

hsivonen: The concept being marked up is clearly the concept the <cite> element would provide. But the page instead has <i> elements and <em> elements. This is explained by the version of Dreamweaver used to create it originally using the <i> element and a newer version of Dreamweaver using the <em> element in response to the same command.
... The page isn't even internally consistent. The user has know way of knowing this result from the WYSIWYG part of Dreamweaver.

<oedipus> the tool (dreamweaver) should have done a universal search-and-replace (interactive, preferably) which would have changed the <i> to <em> when <em> became the tool's default

hsivonen: I think it's hopeless to expect authors to do better; changing what Cmd+I generates doesn't add usefulness to this.

kennyluck: I found the interpretation of <i> as a semantic element hard to understand. The table says the <i> element is for alternative voice, but the text says...
... I don't think technical terms fit into this category; do you alternate your voice when you read a ??? name.

hsivonen: The reason it's complicated is that it tries to provide a semantic fig leaf to justify keeping <i>.

<fantasai> anne: For all the cases where a more specific element is not applicable

<Julian> q!

<fantasai> sicking: Technically you could use the citation, but ...

<fantasai> anne: There is a should requirement that you use the most appropriate element, which would mean you violate that should requirement.

<kennyluck> s/???/ship/

<fantasai> anne: You could argue that violating that should requirement is OK when you use WYSIWYG editor

<fantasai> Julian: I forgot to say and add to what I said before, that in addition to making all those elements that might be unconforming conforming

<oedipus> kennyluck, putting a ship's name in italics is a relic of printing conventions

<fantasai> Julian: The spec explains why using semantic elements is better, instead of using conformance hammer, I think that would be much better

<hsivonen> +1 to what Julian said

<fantasai> mjs: Last call for queuing

<fantasai> cyns: A tool could be designed to handle Henri's mom's use case, to help the user create a properly marked up bibliography

<fantasai> cyns: Not all tools will do that, but a tool can.

<fantasai> cyns: So it's not a spec problem but a tool problem.

<fantasai> cyns: The semantic fig leaf seems somewhat tortured

<fantasai> sicking: Do AT take action on <i> or <u>?

<fantasai> Janina: sure

<fantasai> Janina: That's an option

<oedipus> the tool (dreamweaver) should have done a universal search-and-replace (interactive, preferably) which would have changed the <i> to <em> when <em> became the tool's default while offering the user the choice to use other more appropriate tags (such as <cite> for instance)

sicking: Other than for proofreading, do people configure screenreaders that it reads in a different voice?

Janina: I don't think so.

r12a: I think different types of user are critical to this discussion; I don't think you can expect ordinary user writing blog post to semantically tag their stuff, so I think it's useful to have <i> and <u>.
... There are perhaps other users writing large Web sites going to be localized, and we could expect them to know about semantic markup and how to do things better.

<r12a> i think the distinct types of user is critical to this discussion - i doubt many users would know how to semantically tag their blog post text using elements or class names, but people designing large sites that need to be localized may do so, and for those we can provide guidance, eg. http://www.w3.org/International/questions/qa-b-and-i-tags

r12a: I think keeping the fig leaves in place can be useful; I think guidelines like the one just pasted could be useful. I don't think we should do anything.

cynthia: Except add back <u>?

r12a: Possibly.

<anne> oedipus, haha

maciej: Out of actionable things, it seems like most people in the room in favor of adding back <u>. For adding back <u> we have a bug that has been reopened. Adding more info or maybe escalating might be right step.

Julian: Argument for removing semantic fig leaves.

maciej: Someone would have to file a bug to remove semantic fig leaves.

<cyns> +1 julian

hsivonen: As a validator developer, I care more about telling people to do busywork that isn't beneficial, so I care most about the machine-checkable conformance requirements (does the element exist in the language).
... I'd be ok with not having semantic fig leaves and saying that these things are in the language and they do X.

<oedipus> rip off the semantic fig leaves!

hsivonen: I think it's semi-OK to have the fig leaves since they don't lead to bad consequences for validator users. But they do lead to ratholing on mailing lists.

maciej: I care more about the mechanical requirements.

Julian: But people care about them.

?: That's how we ended up here.

r12a: If people want to demarcate the content and don't want <em>. What do they use?

<oedipus> if they feel strongly about it, they can use <strong>

fantasai: <span> doesn't say that the element should be distinguished to the user. <i> says the reader should be able to distinguish the text from the surrounding contents. I think it makes sense to encourage people to use <i> where that's appropriate rather than <span> + CSS.

cynthia: One thing that didn't get into minutes: I think current spec text is quite confusing: what <i> is supposed to mean.
... It seems like simpler and more declarative "<i> does this" text would be better.

Janina: I think in an English class many years ago we were taught that if you wanted to emphasize something you use italics and if you really want to emphasize it you bold it.

anne: But you also put a bunch of other things in italics.

<fantasai> cyns, but <i> /doesn't/ "do this" (put things in italics) in renderings that dont' support it

<oedipus> cyns, agree that the <i> and <b> parts need to be more harmonic

Janina: to set them apart...

anne: Why not let them use <i>?

<fantasai> cyns, such as voice or braille or TTY interfaces

Janina: I have no problem with them using <i>; I think we're making too much of this.

[multiple conversations]

<oedipus> the only reason italics and bold were used for emphasis is that there isn't any means other than underlining or changing fonts or using italics or bold in print, that shouldn't limit/lead our work on semantic MLs

maciej: Time to adjourn; people are welcome to continue discussion informally.

Meeting adjourned.

Summary of Action Items

[NEW] ACTION: cyns to update change proposal for bug 10448 [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action09]
[NEW] ACTION: Eliot to indicate that old editors' draft of canvas is out-dated and reference new one [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action17]
[NEW] ACTION: frank to file a bug about arriving at spec text that speaks to complexities of how DOM elements behave in the shadowl DOM beneath the canvas [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action14]
[NEW] ACTION: Frank to provide mapping from media accessibility requirements doc to spec changes or guidelines for UAs [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action04]
[NEW] ACTION: Frank_Olivier to provide mapping from media accessibility requirements doc to spec changes or guidelines for UAs [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action03]
[NEW] ACTION: frankolivier to provide mapping from media accessibility requirements doc to spec changes or guidelines for UAs [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action02]
[NEW] ACTION: Gregory - propose replacement example for lady of shallot example of purely decorative use of image with code example of one of the use cases provided in prose introducing the example [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action07]
[NEW] ACTION: gregory to draft a change proposal to issue 31 to update the definition of img element [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action06]
[NEW] ACTION: janina To: Janina to ask Laura to combine working from proposal items 2 and 4 [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action01]
[NEW] ACTION: paulc and co-chairs to investigate how to handle standardization of websrt [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action05]
[NEW] ACTION: rich to file a bug about accessible rich text editing with canvas [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action15]
[NEW] ACTION: Rich to file defects for features necessary for focus ring and magnification [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action16]
[NEW] ACTION: rich to update change proposal re bu 10449 [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action08]
[NEW] ACTION: steve to updage change proposal for bug 10594 [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action13]
[NEW] ACTION: steve to updage change proposal on bug 10592 [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action12]
[NEW] ACTION: steve to update change proposal for bug 10481 [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action11]
[NEW] ACTION: steve to update change proposal for bugs 10444 and 10462 [recorded in http://www.w3.org/2010/11/04-html-wg-minutes.html#action10]
[End of minutes]