See also: IRC log
<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
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.[End of scribe.perl diagnostic output]