Protocols and Formats Working Group Teleconference -- 12 Nov 2015

<trackbot> Date: 12 November 2015

<richardschwerdtfeger> meeting: W3C WAI ARIA Working Group

<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-pfwg/2015Nov/0045.html

<fesch> https://mit.webex.com/mit/j.php?MTID=m89fa7dfc04a8e377f134e5845036a266

<janina> scribe: janina

Logistics Migrating to the new ARIA WG

mc: new list will be public-aria as primary, may be others
... expect new wikis, tracker, etc
... some uris will change
... No github change planned

<MichaelC> http://www.w3.org/WAI/ARIA/

mc: Webex will also change at some point

<clown> in terms of my question, to join: https://www.w3.org/2004/01/pp-impl/83726/join

mc: PF extended to Dec 3

<Zakim> clown, you wanted to ask which group to join for "ARIA"

mc: Very important that people join ARIA WG
... For now, CfC's will run under PF

<Zakim> joanie, you wanted to ask if we can add changing the meeting day/time to the to-consider list

jd: Notes she has a conflict every other month on Thursdays

<LJWatson> +1 to considering a new meeting time.

mb: Would prefer later time

jd: yes

clown: West Coast people like this time

<ShaneM> +1 on setting up a poll sooner than later about the time though.

<LJWatson> JS: It's important people join the new group.

<MichaelC> Draft ARIA Decision Policy

<clown> https://www.w3.org/2004/01/pp-impl/83726/join

mb: What to do to join?

mc: I'll follow up with invited experts

pubs

mc: Publishing next Thursday

janina: CfC will be out today

clown: Have some quick edits--will try to get them in

fe: SVG AAM ready

mc HTML AAM?

rs: poking SF

<ShaneM> Yes - the gh-pages need to be updated

mc: It's a manual process, someone needs to do it more regularly
... We prefer to automate, but not working out so far

<Zakim> joanie, you wanted to point out Steve asked about our stale spec

clown: Issue is getting respec out of gh pages

mc: Still not that hard, but a fuss because we have so many docs
... Could use github help to get this automated
... There's webservice for respec
... Getting github to accept the commit hasn't worked out for me

<ShaneM> https://labs.w3.org/spec-generator/?type=respec&url=yourspec

rs: HTML AAM also OK to go
... SVG needs to review SVG AAM?

mc yes

mc: We need a record of approval to publish we can point to

rs: I'm no longer able to attend the SVG call -- bad time

aria-describedat

rs: Clear to me it's not meeting use cases set out by dpub

<LJWatson> JS: Think Judy is worried about dropping @describedat before a replacement is in place.

<LJWatson> ... Seems to be consensus for using details/summary, but one concern is that those elements are used for multiple purposes.

<LJWatson> ... So we'd need a way to indicate to users what the details/summary contained.

<LJWatson> ... There has been discussion of a role to disambiguate that.

<LJWatson> ... AT could use that, and CSS could be used to trigger a visual indicator for non AT users.

<LJWatson> scribenick: LJWatson

<janina> rs: create a new role that defines an extended description, when applied does not get stringified, stays as a relationship

<janina> rs: will allow styling

<clown> for the minutes: the relationship is described-by/description-for.

<janina> rs: don't want to call it "description" because it would be misused by authors

<janina> rs: what does details default to? is it a group?

<janina> clown: believe so

<janina> clown: on atk it's a panel, everywhelse a group

<janina> cs: we're thinking of changing to a dialog

<janina> clown: summary on aapis generally push button with expand/collapse, on ios is disclosure triangle

<janina> rs: If we put a role and overide, is it a problem?

<janina> rs: Problem if hidden?

<Zakim> cyns, you wanted to say that mappings that change based on the role of a referenced object are a pain to implement and slow to run

<janina> cs: significant performance implications and a pain to implement

<janina> rs: property better?

<janina> cs: whatever needs to be on the referring object, not on the target

<janina> rs: describedby iby itself -- could have description or extended description -- that's the problem

<janina> clown: describedby is both string and relationship, we don't want the string in this case

<janina> rs: could have both a description and an extended description

<janina> cs: we should push back on that

<janina> yes

<janina> rs: what if we put property on target

<janina> fe: what if extended descript is third party

<janina> rs: iframe in details

<janina> janina: that was the idea all along

<janina> rs: special property on details, but not role because we don't want to swap roles out

<janina> cs: still a problem because property is on the target

<clown> aria-extendeddescribedby ?

<janina> rs: maybe an extended-describedby where you don't stringify anything

<janina> cs: and if hidden

<janina> cs: believe details isn't in the tree until expanded

<janina> cs: add and build when user expands

<janina> cs: so what's the mapping if both exist?

<janina> rs: we could disallow both

<janina> cs: we have to anyway

<Zakim> joanie, you wanted to ask why this property cannot/shouldn't be placed in HTML5.x instead.

<janina> jd: why does this have to besolved by aria

<janina> cs: why not an attrib on summary or details?

<janina> rs: because we can get it done quicker ???

<janina> cs: understand browser wrapped in native app? sm: do we have to solve this use case?

<janina> rs: would be ok to remove describedat and add issue to fix use cases in 1.1?

<janina> mc: rather the other way, do the work then remove

<janina> mc: would not want to go to cr with describedat

<Zakim> ShaneM, you wanted to ask if the world will end if we decide there is no good solution for DPUBs use case

<janina> mc: is the next pub cr?

<janina> [discussion on how best to proceed, what first, what second, etc]

<janina> rs: decision to put a "probably will be removed" on describedat

<ShaneM> FEATURE AT RISK

<janina> rs: working with dpub to address use cases for extended descriptions

<janina> mc: can work on wording offline

<janina> mc dpub and others

<janina> rs: please tweak as necessary for the heartbeat

<richardschwerdtfeger> ACTION: cooper Work with Joanie to inject aria-describedat wording pertaining to limited life [recorded in http://www.w3.org/2015/11/12-aria-minutes.html#action01]

<trackbot> Created ACTION-1740 - Work with joanie to inject aria-describedat wording pertaining to limited life [on Michael Cooper - due 2015-11-19].

article feed

<richardschwerdtfeger> https://www.w3.org/WAI/PF/Group/track/actions/1725

<janina> rs: didn't we agree to this at tpac? didn't see it go in

<richardschwerdtfeger> https://www.w3.org/WAI/PF/Group/track/actions/1725

<richardschwerdtfeger> http://rawgit.com/w3c/aria/mck_issue633/aria/aria.html#articlefeed

<janina> rs: any issues?

<janina> rs: believe we were limiting this to articles, yes?

<janina> mb: if so, why not just call it "feed" ?

<janina> mb: because if we take it beyond articles, the word "article" in its name would be confusing

<janina> rs: text talks about "a scrollable list of articles"

<ShaneM> reminder - "article" doesn't only mean a news item.

<janina> clown: agree to "feed"

<ShaneM> for example, "the" is an "article"

<janina> rs: so could expand in a future version for other types

<jamesn> it is limited to <article> elements?

<janina> fe: believe matt wanted "article feed" because it was only articles

<janina> rs: but it's in the definition

<janina> fe: feed is the abstract

<janina> rs: article feed is the instance

<janina> rs: the other way is we can introduce the abstract "feed" later to add others

<janina> jn: why? why not just have feed

<janina> jn: don't see the use case -- different roles for each ??

<ShaneM> is it a 'feed' because it is a live region where additional content keeps coming in?

<clown> more tweets keep getting added.

<janina> jn: assuming some kind of container, and the ability to focus on objects in the container

<janina> fe: point was to be able to move within the article with various nav units

<janina> fe: so it didn't need to change nav while skimming

<janina> cs: seems having a feed would be far more flexible

<janina> rs: yes

<janina> rs: call it feed, set article as default

<janina> jn: has anyone implemented

<janina> jn: no backwards compatible issue today

<janina> rs: yes

<ShaneM> +1 to using "feed"

<janina> rs: leave as is for now, switch role to "article feed" leave def as is, then change "article feed" to "feed"

<ShaneM> if we need a type attribute later, it would be an enumerated list of potential types that we define, and related to HTML elements or "mixed" or something

<janina> rs: any objection to calling it feed?

<jamesn> +1

<clown> +1

<richardschwerdtfeger> +1

<richardschwerdtfeger> -1

<jamesn> -2

<joanie> 0 on the grounds that I'm not convinced we need this role independent of name. But if we need it I don't care what it's called.

<janina> resolution: change the name of article feed to feed

<clown> +1

<ShaneM> +1

<jamesn> +1

<joanie> 0

<fesch> +1

<janina> +1

<janina> clown: the text speaks of the aria role 'article' as well as the html article element. does it work the same for both?

<janina> rs: maps

<janina> RESOLUTION: Change "article feed" to "feed"

<clown> +1

<clown> for the minutes: yes, html article has the same mappings as ARIA role article.

action 1361

<janina> action-1361?

<trackbot> action-1361 -- Matthew King to Suggest new text for the application role -- due 2015-06-11 -- OPEN

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

<janina> rs: any issues?

<richardschwerdtfeger> http://rawgit.com/w3c/aria/mck_applicationRole/aria/aria.html#document

<janina> [rs summarizes changes]

<janina> rs: objections? need more review? ?

<janina> RESOLUTION: Pull Matt's change for role application and role document; close issues 1631 and 633

- DRAFT -

Protocols and Formats Working Group Teleconference

12 Nov 2015

Attendees

Contents

Logistics Migrating to the new ARIA WG

pubs

aria-describedat

article feed

action 1361

Summary of Action Items

Scribe.perl diagnostic output