W3C

- DRAFT -

Protocols and Formats Working Group Teleconference
02 Dec 2013

Agenda

See also: IRC log

Attendees

Present
Rich_Schwerdtfeger, +1.541.678.aaaa, Joseph_Scheuhammer, Michael_Cooper, Jon_Gunderson, Stefan_Schnabel, Janina_Sajka, Matt_King
Regrets
Chair
Rich
Scribe
mattking

Contents


<trackbot> Date: 02 December 2013

<richardschwerdtfeger> Meeting: W3C WAI-PF ARIA Caucus

<richardschwerdtfeger> http://lists.w3.org/Archives/Public/public-pfwg/2013Nov/0057.html

<scribe> scribe: mattking

Role presentation and presentation tables

<clown> Layout table is presentational table, it provides table semantics to AT but it's not exposed to the user.

<clown> UAIG says to not create an accessible object for table element, so exposing role="presentation" table as layout table is not possible without breaking ARIA spec.

<clown> Also UAIG doesn't say we must create an accessible for TBODY/TR/TD/etc in this case. So Firefox implementation conform the spec. However having a generic accessible for presentational TD/TH doesn't seem breaking ARIA spec and it may resolve the problem.

<clown> Anyway, before making any attempts to fix the problem on Firefox side I'd like to get some discussion in ARIA group.

I'd say ARIA spec shouldn't be so strict requiring the browser to remove native semantic of table and its descendants, it should say instead that presentational table should be a layout table. That'd be much easier

for implementers. The same time if we exposed TD as a section role then it should be ok with ARIA spec but that would complicate already complicated browser implementation. So I'd suggested to rise this

topic at WG.

Thanks.

I'd say ARIA spec shouldn't be so strict requiring the browser to remove native semantic of table and its descendants, it should say instead that presentational table should be a layout table. That'd be much easier

for implementers. The same time if we exposed TD as a section role then it should be ok with ARIA spec but that would complicate already complicated browser implementation. So I'd suggested to rise this

topic at WG.Thanks.

RS: there is nothing in spec about merging text among elements of layout table.
... tests for role presentation passed and then the code was changed. this is confusing.
... merging content from multiple table cells does not preserve content as required by spec

JC: seems like good iea to add a clarification in 1.1

MK: should elements with role presentation have a mapping in the API table?

JC: That is a question for UAIG WG. It is not clear that is best approach.
... if FF is exposing TDs as separate text nodes, then that is enough to pass this issue off to UAIG.

<clown> http://www.w3.org/TR/2011/CR-wai-aria-20110118/roles#presentation

<jcraig> ACTION: joseph to clarify that presentation role should preserve separation of nodes within tables/lists; work out in UAIG and with implementors/vendors how to resolve this. [recorded in http://www.w3.org/2013/12/02-pf-minutes.html#action01]

<trackbot> Created ACTION-1311 - Clarify that presentation role should preserve separation of nodes within tables/lists; work out in uaig and with implementors/vendors how to resolve this. [on Joseph Scheuhammer - due 2013-12-09].

Joseph: Right in the spec, it says that one example is a layout table.

<clown> A layout table and/or any of its associated rows, cells, etc.

<jcraig> action-1311?

<trackbot> action-1311 -- Joseph Scheuhammer to Clarify that presentation role should preserve separation of nodes within tables/lists; work out in uaig and with implementors/vendors how to resolve this. -- due 2013-12-09 -- OPEN

<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1311

<jcraig> <foo>

<jcraig> <span>

<jcraig> <element>

<jcraig> ACTION: jcraig to change presentation example from <span> to generic <example> element which does not have the same baggage as span, with varying cross-browser implementations. [recorded in http://www.w3.org/2013/12/02-pf-minutes.html#action02]

<trackbot> Created ACTION-1312 - Change presentation example from <span> to generic <example> element which does not have the same baggage as span, with varying cross-browser implementations. [on James Craig - due 2013-12-09].

<jcraig> action-1312?

<trackbot> action-1312 -- James Craig to Change presentation example from <span> to generic <example> element which does not have the same baggage as span, with varying cross-browser implementations. -- due 2013-12-09 -- OPEN

<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1312

Consolidated 1.1 generic Core implementation guide

RS: Put all that is common in one core implementation guide and then break out technology differences into separate implementation guides.
... e.g., HTML 5.1 and SVG would each have their own guide.

JC: We don't have 1/1 mappings for all elements. For example, there are not SVG native elements for all types of drawing objects.
... I like the general approach.

Joseph: What would be done with events?

RS: Events would be part of core, along with focus change, selection, etc.

MC: How is the core cleanly spearated from peripheral modules?

JC: I see analogy with CSS module specs.
... scopes testing and speeds standards process.
... but is more complex for authors to read.

<Zakim> jcraig, you wanted to say this is different from what I thought Rich was proposing

<Zakim> Joseph_Scheuhammer, you wanted to point out that there is overlap between UAIG events and IndieUI.

JC: For ARIA 2.0, we could have a roles module, with sections for document roles, application roles, graphics roles (covering SVG & canvas sub-DOM), etc.

Joseph: In the events space, there could be overlap with IndiUI

RS: Proposal is to put all common elements in one core.

MC: I hear 2 different types of proposals. One for a feature module and the other host language mapping modules.
... If we go for 2nd approach, then we should treat ARIA like a host language.

Joseph: that is very much like what is now.

RS: Consider name computation, SVG and HTML name computation are different and so this would not be in the core.

MC: I am not disagreeing, but I am not yet ready to agree with a specific proposal. I need to understand better.

JC: there is general agreement about some kind of modularization, but there are some very different ideas about how the modularization should be done.

RS: I think we need to do it for 1.1.

JC: I think this will take a couple of years; I do not see it being contained in 1.1.

RS: we have to think of semantics for drawings in SVG today. So, we need a way to work on it right now.

<Zakim> janina, you wanted to say it seems we like the modularization approach, but are unclear on how best to divvy things up

JC: If we want to do it soon, then we should start the ARIA 2.0 module drafting now.

<Zakim> MichaelC, you wanted to say a dot version wouldn´t generally have such a big refactoring; we should do a small fast 1.1 and do this as a 2.0 in a shortish timeframe

JC: to support HTML 5.1, we only need a couple of new roles in ARIA 1.1, so we don't need a major refactor.

MC: I agree with James for diff reasons. For a point release, the changes should be small.
... and, we could start on the 2.0 drafts now to address urgent issues with SVG.
... in other words, do 1.1 and 2.0 in parallel.

RS: We need an SVG mapping right now.
... there is a requirement for a normative implementation guide for ARIA for html 5.1.
... What we need to define whaat happens when there is amatching native role.

<Zakim> jcraig, you wanted to say SVG a11y community group could start a wiki page with roles needed to support SVG

JC: that seems like a small edit that could be done to address html 5.1 in aria 1.1.
... Propose use SVG accessibility community wiki to list all roles required by SVG that are not in ARIA 1.1

RS: the SVG spec currently points to ARIA.

JS: We are not going to be able to work all this out today.

RS: there is nothing normative for html 5.1 today. So, we need to adress the issues today.

<MichaelC> Note in http://www.w3.org/TR/html-aapi/ ¨This document is intended to become a W3C Recommendation.¨

<jcraig> q

MC: We need to be sure we cosider charter and timeline as part of this discussion.

JS: ARIA 1.1 is aimed at html 5.1. 1.1 is not possible in 5.0 time frame.

JC: this seems like a huge re-write for a point release.

Face to face dates

JS: Proposal is for an ARIA Next face to face.
... Not specifically ARIA 1.1, but a go-forward strategy that could be 1.1, 2.0, etc.
... proposing we need 3 days.

<jcraig> I would be more likely to be able to make a 2-day conf

JS: Propose Toronto in January ... side benefit is great weather.
... Have 2 possible hosts. Many of the people we want at the table are in that area.

MC: Reminder we need 8 week notice.

RS: Much prefer end of January rather than February.
... week of 20th?

JC: that is workable.
... let's go for 2 days.

RS: One of the things we want to do is 1.1 issues.

<clown> aria 1.1 issues: https://www.w3.org/WAI/PF/Group/track/products/17

JS: If we have to go into weekend, would rather go into a Saturday.

charters

RS: do we have to include version numbers in the charter?

MC: It is not necessary, but it would be a change to what has already been reviewed.

JS: I'd rather go with charter amendments than a new charter.

Next week

JS: We will have comments from UAIG; they are due Friday.
... We also have ARIA hidden to address.

JG: Will there be additional implementation testing for 1.0 features that were not implemented.

JS: we are done when we pass CR requirements.

RS: Is there a formal test results publishing process?

MC: Not now. There is an effort called test the web forward that we may work with in future.

JG: Can we use the test harness to see if gaps, e.g., Chrome implementation, have been filled.
... It is important for us to provide feedback to browser developers if they are open to it.

JS: agree.

rssagent, make minutes

Summary of Action Items

[NEW] ACTION: jcraig to change presentation example from <span> to generic <example> element which does not have the same baggage as span, with varying cross-browser implementations. [recorded in http://www.w3.org/2013/12/02-pf-minutes.html#action02]
[NEW] ACTION: joseph to clarify that presentation role should preserve separation of nodes within tables/lists; work out in UAIG and with implementors/vendors how to resolve this. [recorded in http://www.w3.org/2013/12/02-pf-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013/12/02 16:35:18 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/test/tests/
Succeeded: s/tis/this/
Succeeded: s/For ARIA, we could have a roles module, graphics modeule, etc./For ARIA 2.0, we could have a roles module, with sections for document roles, application roles, graphics roles (covering SVG & canvas sub-DOM), etc./
Succeeded: s/specific porposal/specific proposal/
Succeeded: s/for html 5.1, we only need a couple of new roles in aria 1.1./to support HTML 5.1, we only need a couple of new roles in ARIA 1.1, so we don't need a major refactor./
Succeeded: s/ARRIA/ARIA/
Found Scribe: mattking
Inferring ScribeNick: mattking
Default Present: Rich_Schwerdtfeger, +1.541.678.aaaa, Joseph_Scheuhammer, Michael_Cooper, Jon_Gunderson, Stefan_Schnabel, Janina_Sajka, Matt_King
Present: Rich_Schwerdtfeger +1.541.678.aaaa Joseph_Scheuhammer Michael_Cooper Jon_Gunderson Stefan_Schnabel Janina_Sajka Matt_King
Agenda: http://lists.w3.org/Archives/Public/public-pfwg/2013Nov/0057.html
Found Date: 02 Dec 2013
Guessing minutes URL: http://www.w3.org/2013/12/02-pf-minutes.html
People with action items: jcraig joseph

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]