<trackbot> Date: 11 November 2015

<janina> Hi, It's 647 857 439 passwd pfwg

<tzviya> it worked this time with a captcha

<janina> argh, captcha?

Janina what is the meeting paswword?

<janina> 647 857 439 passwd pfwg

<janina> Leonie, it's lower case pfwg for the password, but there may be a captcha problem that's newly shown up too

<janina> You might rather want to ask for a call out via your mobile

<scribe> scribe: fesch

preview agenda with items from two minutes

js: anyone with news, items?

APA Charter Impact http://www.w3.org/2015/10/apa-charter.html

js: #1 thing, everyone needs to sign up for the new working group (APA), PF will expire...
... newer things will move over, new mailing list..., not moving to new mailing list until most members are moved over would be counter productive, please get your transition underway
... may be end of year before we cut over, ARIA will get similar message tomorrow

mc: we will have a change of infrastructure.... will get it worked out over the next few weeks (Rich, Janina, MC)

<Zakim> joanie, you wanted to ask if we'll all be auto-subscribed to the new list when most of us have joined

js: yes (we will be auto-subscribed to new group, when we join new group)

Long Text Mechanism Resolution

js: Rich are you here? I think Rich is wrong in initial post on details, we know Chrome and Safari have support, Mozilla has it underway, thinking MS Edge will
... 2nd item, issue of making details visible, believe we can do that via CSS
... 3rd issue - how we disambiguate use of details - no mechanism, so not quite there yet, think unfortunate aspect is if we do it with ARIA then restricting to users of AT
... some of use cases we were given don't use AT (COGA, keyboard only user...)
... without a non ARIA use we may be similar to...

<janina> Rich, lower case pfwg

tz: aria may be broader use than AT

<richardschwerdtfeger> did that. will try again

<Ryladog> I have the same question

jw: is it correct to say a details element can use CSS?

js: you can, but that doesn't discriminate between use - advertisement vs description

jw: you could style differently using CSS
... web controls allow us to do that, Mark H showed a demo

js: talking about details
... we haven't found a way to disambiguate between uses

rs: requirements keep growing ... where does it end?

<Zakim> tzviya, you wanted to say that these are not new requirements

tz: these are the same requirements, we talked about them in the past

rs: we didn't talk about them

tz: we gave broad examples, not every use case in the publishing world

rs: describedat won't do what you want, that is off the table
... when you have an iframe, why do you need pagination?

tz: that is off topic...

rs: that was a reason we couldn't use it

tz: I will have to go back to Daniel about that... I think he is concerned about widgets in iframes....
... Daniel entered in the middle of the conversation... Janinia brought up, need a way to disambiguate usage

js: perhaps we could use a aria tag ... but want non AT users to benefit too
... don't know if there will be a rush to implement ARIA for all users - in ereaders
... are ebook reader's going to implement aria for use outside supporting AT?

tz: I can't speak for the platform developers, most are on top of a browser implementation

rs: all dpub readers support HTML 5 markup - all based on web browser technology

js: so data is available to them, if they want to take advantage of it

rs: yes

tz: may happen, but will depend on underlying technology

js: we haven't found how to disambiguate - other users may see the link but won't know if it is a description or advertisement

rs: for Diagram project, wanted to crowd source that is why they wanted a URL

tz: that wasn't forwarded by dpub, we have a formal document...

<richardschwerdtfeger> ok

<tzviya> DPUB requirements for extended desc: http://www.w3.org/dpub/IG/wiki/Publisher_requirements_for_extended_descriptions

rs: : we take requirements from more than dpub

js: how can we disambiguate? Looking for suggestions

rs: we could have a detailed view, sections - regular description, detailed description
... I heard that having a URL was a requirement - is that a requirement?
... I don't want to rule out iframes...

tz: at TPAC MC said we would look at the table he put together, look at options and put to group

mc: I was going to harmonize the table from feedback from TPAC, Jason and private discussions, haven't done that yet
... only a couple options seem viable from use cases

lw: we have a definitive set of requirements?

mc: I have a table, don't know if it is definitive

lw: if we don't know the requirements.... makes it hard to work out solution...
... does it mean there is no consensus on requirements

rs: describedat won't do it - will have an item on ARIA call tomorrow

<tzviya> Michael's long analysis: http://www.w3.org/2015/08/extended-description-analysis.html

js: number one question about tables are they representational? If not, then the table won't help us make a decision
... we know about unadded changes... details is best option, how to disambiguate use?

jw: mentioned on list - use CSS for visual, can't apply styles to underlying to shadow DOM element - if you can't do it then it would rule out using CSS ...
... web components don't have that problem... Mark H has demoed this
... can use web components to satisfy requirements

js: it is unclear what support web components will get?

jw: I think that is clear, but capabilities of web components are greater

js: web components are one, web annotations are another, need support now

jw: may not get everything immediately
... if can use CSS to handle visually different, that would handle the disambiguation issues

mc: what details doesn't do - is disambiguate, could use class='description" but that would be a convention, so support a role..
... might have to add a role to ARIA

rs: I don't think I would use role='description' , we have a role...

mc: don't care what the role is - just as long as there is a role

<Zakim> tzviya, you wanted to mention http://caniuse.com/#search=custom

tz: dpub is neutral, web components have limited support, apple did not commit to supporting web components (unless it is well supported)

js: that is what I am trying to convey to Jason...

mc: are the implemented? are they easy to use?
... if we fill in web components with no, no, no then it will fail the test, but have the capability to pass later

fe: I like something that disambiguated roles

mc: I think this is a question for ARIA

js: sounds like answer is yes, do we need to worry about styling?

mc: want styling on a universally predictable thing

js: is it reasonable to ask ARIA for a thing to disambiguate roles?

rs: you can ask.... trying to get ARIA 1.1 out...

jw: Mark H will work on prototypes using details and migrate to web components

rs: where are we on the IRC?

js: talked about this earlier.... IRC may switch earlier, email later -

mc: no need for ARIA to switch IRC :)

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/dsc/desc/
Found Scribe: fesch
Inferring ScribeNick: fesch
Present: TzviyaSiegman janina Jason_White fesch Joanmarie_Diggs LJWatson MichaelC Rich_Schwerdtfeger Katie Haritos-Shea Rich Cynthia

WARNING: Replacing previous Regrets list. (Old list: Gottfried, John_Foliot, Markku)
Use 'Regrets+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Regrets+ James_Nurthen, Gottfried_Zimmerman, John_Foliot, Michiel_Bijl

Regrets: James_Nurthen Gottfried_Zimmerman John_Foliot Michiel_Bijl
Agenda: https://lists.w3.org/Archives/Public/public-pfwg/2015Nov/0061.html

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

Found Date: 11 Nov 2015
Guessing minutes URL: http://www.w3.org/2015/11/11-pf-minutes.html
People with action items: 

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