<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-aria/2016Jan/att-0083/00-part

<scribe> scribe: fesch

<richardschwerdtfeger> https://www.w3.org/WAI/ARIA/decision-policy

Draft Decision Policy

mc: significant change - will send separate calls for consensus for resolutions in a meeting, clarification 48 hrs is the minimum duration, unless in a hurry we will usually allow a longer time
... structural change - consolidated stuff - steps up to the top
... expounds on process... can read it in the policy

rs: where is the 7 day piece?

mc: it has been removed

js: we don't want to box ourselves in, perhaps we need to meet a heartbeat publishing deadline... we would be stuck
... we removed the 7 day part, to allow us more flexibility...
... we can say you have 5 business days, but we don't want to be trapped

rs: there should be a maximum...
... who decides how long it will be?

mc: process for folks that know they won't make the meeting... they can ask for a longer period, chair already has control of the time limit

rs: trouble is we could resolve and then someone could want it reopened

mc: a wiki log of official decisions gives a history...

rs: concerned we will be back in the same state

js: don't know if we can stop stuff with policy, but we need to be able to control an agenda

mc: there are good reasons to miss - a dead cat for instance (?)
... the separate admin lists should help and focus attention - even if they miss

rs: I will push for 2-3 days and want to know why they can't decide in that time frame... need a good reason

mc: unless the chair has a good reason to not grant an exception, I think the chair should grant an exception

<cyns> +1 for moving on to aria 2.0

mc: we can fall back on policy if there is a problem

fesch: does this policy apply to task forces?

js: a task force can make it's own decision policy

mc: I suggest a task force keep their policy informal

rs: I think we can continue the way we have been doing it (SVG a11y)

js: I support that approach, we only make policies when we run into problems

rs: trying to support folks that can't always make meetings
... I will push for a 2-3 day solution on CFCs...

mk: for technical resolutions for content of a spec, is there an advantage to making it less than a week? Writing responses can take time... you have other work to do

<bgaraventa1979> business days make sense, trouble committing on weekends

rs: but you would have attended the meeting....

mk: wondering how 2-3 days makes it quicker?

rs: it lets the editors move on to the next set of issues

js: this excludes holidays and weekends
... Saturday and Sunday don't count

rs: I am talking about 2 -3 business days

js: if you have questions, bring it up at APA next week...

rs: we are currently operating under it yet...

mc: we need to be more careful adopting it...

rs: any questions?

---- silence ----

rs: Janina you can take it up at the APA

TOPIC Discuss Survey on possible Meeting Time change

<richardschwerdtfeger> https://www.w3.org/2002/09/wbs/83726/2016-01-telecon/results

rs: Mondays have a lot of no's....

mc: Friday at 1pm is the preference and Thursday at 3pm Eastern is next...

<richardschwerdtfeger> https://www.w3.org/2002/09/wbs/83726/2016-01-telecon/results

rs: Joanie misses once every other month...

mc: Thursday at 12 was the third choice - effectively not changing

mk: I marked at time slot as OK, didn't mark noon Eastern on Thursday but half past is OK

tz: running meeting on Friday is a tough time, would cut off folks in Asia

rs: Friday is not a positive experience for many... and would take out Asia, Australia
... we checked it out, sounds like now is the best time...

<clown> "This questionnaire is open from 2016-01-18 to 2016-01-25."

rs: will keep it as it is

jn: we are not making a change so why would we need a CFC?

RESOLUTION: meeting time stays the same

<richardschwerdtfeger> https://www.w3.org/WAI/ARIA/track/actions/1380

TOPIC Action-1830

<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-aria/2016Jan/0079.html

<clown> https://lists.w3.org/Archives/Public/public-aria/2016Jan/att-0096/00-part

rs: changing text in ARIA spec

<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-aria/2016Jan/att-0096/00-part

<clown> https://lists.w3.org/Archives/Public/public-aria/2016Jan/att-0096/00-part

When aria-hidden="true" is applied to an element, the element and all descendant elements are removed from the accessibility tree. If aria-hidden="true" is applied to an image, the entire image is removed from the accessibility tree.

When role="none" (or role="presentation") is applied to an element, the element's role semantics are removed, but the element's descendants remain exposed to the accessibility APIs. Most images do not have descendants elements, so the end result of applying role="none" is that entire element is removed, as if aria-hidden="true" had been applied. When an image has descendants (e.g. <img...

scribe: src="example.svg"> or <svg>), that are exposed to assistive technologies as defined by the host language, applying role="none" will remove the image role semantics, but the exposed descendants will remain accessible to assistive technologies.

rs: svg is really a container....

<clown> <img src="jpg, png, svg, etc">

rs: png doesn't support ARIA... James has some nice text...
... reads...

fesch: with an img with an SVG source, the SVG children do not appear in the DOM

js: need something about owned elements...
... is it true SVG never has required elements?

rs: true

action Rich to rewrite proposal to take into account that an img with source svg has no children and also to address the required owned elements

<trackbot> Created ACTION-2007 - Rewrite proposal to take into account that an img with source svg has no children and also to address the required owned elements [on Richard Schwerdtfeger - due 2016-01-28].

Topic Review Pending Review Items

action-1724

<trackbot> action-1724 -- Matthew King to Create a proposal to simplify grids in order to incorporate the list view concept -- due 2016-01-21 -- PENDINGREVIEW

<trackbot> http://www.w3.org/WAI/ARIA/track/actions/1724

<clown> http://rawgit.com/w3c/aria/mck-action1724/aria/aria.html#grid

<mck> can you not hear me

<mck> crap

<mck> unmute me

mk: wanted to comment on img - don't want to recreate all text on role presentation
... 1724...
... from a testing point of view, I don't think the text would change any test cases, changes are oriented in providing better guidance

rs: what are the changes?

mk: goes through changes - ( you can see them in the action)
... issue with flattening text
... as long as the element in a grid cell gets focus and not the grid cell, then the screen reader can interact easier with interactive content
... ... second paragraph role does not imply a visual layout... in cleanup in 3 rd paragraph... 4th paragraph ...

rs: if in a cell and tab to table were does focus go?

mk: we don't want to add practices to this spec...

rs: are you saying you can tab to a button inside a grid cell?

mk: depends... (long example...) isn't any different than in ARIA 1.0 except in ARIA 1.0 the cell is expected to get focus

rs: what I don't want to happen is land in the middle of a grid and not know where they are

mk: nothing in the spec that says anything about that - we don't put limits on what may be an accessible practice in some cases
... in ARIA 1.0 no language on what could get focus inside a grid, there is language in practices

<clown> "Grids allow the user to move focus between cells using two dimensional navigation."

js: grids allow 2D navigation in the grid...

mk: master doesn't give direction to folks writing guidance...
... I reduced what is in the master, was not aware of rowspan, colspan...

<mck> 7. Removed the following statement because the language of sections "7.4 Implicit WAI-ARIA Semantics," "7.5 Conflicts with Host Language Semantics," and "7.6 State and Property Attribute Processing" makes it obsolete:

<mck> "However, if the author applies a non-global WAI-ARIA state or property to a native markup element that is acting as a row, such as the <code>tr</code> element in HTML, the author MUST also apply the <rref>row</rref> role to that element as stated in the section on <a href="#host_languages">Implementation in Host Languages</a>."

rs: but you are also saying that something can be used in a grid and we already state that in ARIA 1.1

mk: I assumed that was still useful to the reader... willing to remove if you think it is bloat

rs: where are the changes opening up interaction within the grid

mc: grid def is shorter... def grid provides 2d navigation
... limiting language is removed... first 2 sentences are more clear on purpose of a grid

<clown> "Grids do not necessarily imply presentation. The grid construct describes relationships between data such that it may be used for different presentations."

mc: a grid is still logically tabular...
... a two dimensional composite
... keyboard management - second sentence and two bullets are new

rs: difference - an interactive element in a grid can receive focus without having to use the arrow navigation
... I don't have to land on a cell, I can land on an interactive item as the first focus item
... what if you have 3 links in a cell?

mk: we will address that in the practices... there are a lot of different ways that it could work.

mc: lots of folks at TPAC supported this change

<clown> a cell contains a single interactive widget that will not consume arrow key presses when it receives focus, such as a checkbox, button, or link authors MAY set focus on the interactive element contained in the cell. This allows the contained widget to be directly operable.

<clown> If a cell contains a single interactive widget that will not consume arrow key presses when it receives focus, such as a checkbox, button, or link authors MAY set focus on the interactive element contained in the cell. This allows the contained widget to be directly operable.

mc; discussed at TPAC...

rs: I don't want people getting lost

<cyns> I like it.

mc: very motivated... talking to vendors...

jd: says to mck I mean the exact expected behavior

jn: we often used a readonly role as table as use is in the wild

rs: anyone have issues about Matt's change

js: aria- readonly .... default is issue

mc: readonly is not allowed to be undefined...
... putting readonly on the grid is only an author convenience, unless the value of the cell only become editable when you interact with it.
... readonly undefined on a grid would be useful... then when you press enter on a gridbox it becomes editable...
... does that have any mapping consequence

<clown> An undefined value for aria-readonly, i.e., aria-readonly is not specified, does not imply that a grid or a gridcell contains editable content.

mc is really mk -typo!

mk: found readonly behavior on screen reader vendors problematic

jd: we added a state readonly a few years ago

<joanie> https://developer.gnome.org/atk/2.18/atk-AtkState.html#AtkStateType

mk: I wish on a grid, readonly would be undefined....

rs: do we need another week on this?

js: my misgivings are minor

RESOLUTION: accept action-1724 proposal

jd to do a pull

RESOLUTION close action-1724

<clown> issue-633

<trackbot> Sorry, but issue-633 does not exist.

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: fesch
Inferring ScribeNick: fesch
Present: Michael_Cooper Bryan_Garaventa Cynthia_Shelly Fred_Esch James_Nurthen Janina_Sajka Jemma_Ku Joanmarie_Diggs Joseph_Scheuhammer Matt_King Rich_Schwerdtfeger Stefan_Schnabel Tzviya_Siegman ShaneM Markus
Found Date: 21 Jan 2016
Guessing minutes URL: http://www.w3.org/2016/01/21-aria-minutes.html
People with action items: 

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