<trackbot> Date: 07 July 2014

<richardschwerdtfeger> meeting: W3C WAI-PF ARIA Caucus

<richardschwerdtfeger> http://lists.w3.org/Archives/Public/public-pfwg/2014Jul/0004.html

<clown> #aapi

<clown> issue-436?

<trackbot> issue-436 -- Consider role="disclosure" to match semantics of desktop API disclosure triangles, or other show/hide widgets -- open

<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/436

<richardschwerdtfeger> http://stevefaulkner.github.io/HTML5accessibility/aria-disclosure.html

<scribe> scribe: MichaelC

Issue 436 Creation of a disclosure (details) role

<richardschwerdtfeger> http://thepaciellogroup.github.io/disclosure-button/

<bgaraventa1979> thanks

sf: ^ started with button from ARIA and extended

to play around with idea

have been looking at disclosure widgets for a while

HTML summary / details are specified different, but implemented similar

summary is in theory a label, and details a control container

but that´s not implemented

usually a button or link displays the new stuff

so disclosure follows that design pattern

rs: extends button?

sf: yes; command superclass an artifact of copying button

<richardschwerdtfeger> http://stevefaulkner.github.io/HTML5accessibility/aria-disclosure.html

requires aria-expanded and aria-controls

in the example can only control a single element

discuss whether to allow multiple controlled elements

since aria-controls allows that

mk: don´t see summary / details in related concepts

sf: haven´t fleshed out everything yet

with summary / details, summary is child of details that labels it

<Stefan> +q I second James here

there´s a non-specified element for expanding

mk: like having label and control the same in a screen reader

e.g., clickable heading

<Stefan> +q

otherwise you have to look around for the actionable element

sf: this is a more flexible approach

can put button inside the heading

with summary / details it´s less flexible

some of reason for that design is desire for other controls inside the summary

that´s problematic because a semi-interactive element also has other stuff

like putting links inside label elements

mk: maybe you want to show more than just label in summary

sf: entire summary becomes accessible name of the anonymous control

mk: yeah, that´s an issue

sf: so design in HTML has issues

implementation in Chrome and Safari is that summary element is a button that controls display of details

rs: should descend from command; don´t want pressed state

should reference HTML 5 summary?

sf: don´t think that works as a base concept

in HTML summary has to be inside details

disclosure button can go anywhere

rs: could have a separate label

sf: could have a button element with its label and role=disclosure

<bgaraventa1979> +q

rs: would you map summary role to this?

sf: not sure

summary / details needs work anyways

I would like feedback on the HTML spec

have raised issues on WhatWG list, no useful response

<SteveF> http://discourse.specifiction.org/t/re-imagining-details-summary-design/64/34

<SteveF> http://discourse.specifiction.org/t/re-imagining-details-summary-design/64

rs: want to be able to reveal more than one section?

jn: don´t like role=disclosure

<Zakim> jamesn, you wanted to say disclosure is more like a property not a role

think it´s a property, not a role

<Stefan> me either

could be a checkbox, button, link, etc. that discloses content

<Stefan> +q

rs: on button gets pressed state

bg: is it like a toggle button?

sf: toggle button is in the button itself

disclosure is specific to hiding or showing content

mk: wouldn´t make sense to me to have a disclosure property on a link

they take you somewhere else

jn: link-like things are used for that all the time

mk: but looks shouldn´t determine UI

jn: different people will answer differently what should be a link and what should be a button

various: not me

jn: in the real world they get seriously co-mingled

mk: still for ARIA we should be more crisp

why would you use this role?

jn: if you click ¨show more¨ isn´t it better to know it´s a link than be told it´s disclosing somewhere else

rs: mixing content and presentation

jn: that happens all the time

rs: it´s really difficult for users

<Stefan> * disclosure as a property is more flexible

mk: it´s one thing for people to misuse spec, and another for us to make spec fit the vernacular

jn: I get questions about this stuff all the time

if UI designers want it to appear as a link, it should be exposed that way to everyone

they don´t know what´s happening under the surface

but if they want it to look like a link, it should act like one

rs: very confusing

mk: extremely confusing

want screen reader to say what it does, not what other people would all it

jn: I get the opposite

<bgaraventa1979> just to clarify for my original question, is the purpose of disclosure to automate the process of hiding or showing a section?

mk: understand the desire to have presentation and function match better

<Birkir> If it looks like a button, I a a screen reader user want it to be announced as a button. Not doing so can create a lot of confusion e.g. when working with sighted peers, customer service reps etc.

but screen reader users get their cues from the roles

jn: if it looks like a duck it should quack like a duck

<Birkir> ... and taste like a duck, yumm, I want lunch

sf: having it as a property retains flexibility

<Zakim> MichaelC, you wanted to say we can rejigger taxononomy to address pressed state issue

mc: make sure we don´t get stuck on existing taxonomy

<SteveF> we have a role in OS x https://developer.apple.com/library/mac/documentation/UserExperience/Reference/Accessibility_RoleAttribute_Ref/Role.html#//apple_ref/doc/uid/TP40007870-Roles-AXDisclosureTriangle

if it´s a problem because of inheriting aria-pressed, rejigger taxonomy so that doesn´t happen

<richardschwerdtfeger> http://www.w3.org/WAI/PF/aria-1.1/roles#button

<SteveF> from leonie "IMO if content is revealed it should be aria-expanded, if it is a toggle (like the play/pause button on a media player), then aria-pressed would be better."

rs: button supports aria-expanded

how does that differ from disclosure?

jn, mk: yes

mk: thought this was coming from HTML 5 matching

but we´re realizing in ARIA we have toggle buttons, and expanded / collapsed

so sounds more like a design pattern than a new feature

<Birkir> aria-expanded assumes the content that is displayed/hidden comes inline to the control. would the same to apply to "disclosure" role, since aria-controls is required I assume it is not necessarily so then.

<Birkir> that is the only difference I can think off

rs: this exercise was to put the design pattern into a role to see how it would map to HTML 5

mk: but you say HTML 5 implementations don´t align with spec

so this won´t help anything?

sf: there are undefined anonymous controls that is the disclosure widget

want to be able to map that to disclosure role

but that thing isn´t defined

mk: how about map to button with aria-expanded?

sf: could do that

rs: with a disclosure role, aria-expanded could be required

mk: but the mapping can provide that effectively required anyways

<bgaraventa1979> +q

rs: so, the question comes to, do we want to wrap this design pattern into a role, or just have it as a design pattern with certain states and properties?

mk: fewer roles is better

more roles is more to implement and more for users to figure out

<Birkir> How many screen reader users are familiar with role="disclosure"? Apple users perhaps, but overloading users with roles and sidget types can end up doing more harm than good.

<clown> <span role="button" aria-expanded="false" aria-controls="something">Expand section 1</span>

not seeing an intrinsic advantage here

sf: not making this role up

it´s existed in OSX for some time

mk: ack; from Mac world brings user base

sf: in Windows they exist too, just not in AAPI

bg: ¨disclosure¨ is also a legal term

<clown> <span role="disclosure" aria-expanded="false" aria-controls="something">Expand section 1</span>

rs: better name, or no role?

bg: no role

mk: me too

rs: happy not to add a role

mk: one less thing to test

rs: :)

SF, do you have enough input to do an HTML 5 mapping?

mc: long term we might want to harmonize AAPIs around ARIA

if exists in OSX, maybe we want a role to harmonize around?

rs: can just harmonize the mappings around the AAPI mappings to design pattern

mk: don´t like ¨expanded¨ buttons

though can live with

have wondered if there should be a region associated with such buttons

is that left to context, or should it be a normal expectation?

and if there´s a region, is expanded / collapsed on the region or the control?

and is control inside or outside the region?

rs: whatever author likes
... So, it sounds like we don´t see need to mint a disclosure role

and can provide HTML 5 mapping of summary / details to existing ARIA features

sf: ok

<Birkir> It's a decent summary of the roles of the summary

clown: Core-AAM should be updated then

<clown> http://www.w3.org/TR/2014/WD-core-aam-1.1-20140612/#mapping_role_table

looking at twisties / twiddles / expandos

sf: it´s against spec for a summary to be implemented as a button

but that´s what it is

sf, clown: <triaging the mapping history>

<clown> <summary aria-expanded="true" role="button" style="-moz-user-select: none;" tabindex="0">

various: nitty-gritties in the mapping tables

rs: agreement not to introduce disclosure role?

disagreement?

sf: disagree but not vehemently

RESOLUTION: Do not introduce disclosure role

close issue-436

<trackbot> Closed issue-436.

Issue 626 text alt computation on recursions are unclear

<richardschwerdtfeger> http://www.w3.org/TR/2014/WD-core-aam-1.1-20140612/#mapping_role_table

issue-626?

<trackbot> issue-626 -- text alt computation statements on recursion are unclear -- open

<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/626

<clown> issue-626?

<trackbot> issue-626 -- text alt computation statements on recursion are unclear -- open

<trackbot> https://www.w3.org/WAI/PF/Group/track/issues/626

mk: right, sounds like an issue

avoid infinite nesting?

clown: that´s what the confusing statement tries to do

mk: so it says it won´t concatenate IDREF names before stuffing them into the name?

rs: a single element should not appear more than once in a name computation

clown: avoid infinite loops

jn: but people should be able to do what they want

in tables, use aria-labelledby to provide a heading for a cell

referencing a rowheader and colheader

yet the rowheader also references the colheader

what should happen?

rs: intent is not to use it twice

jn: @@

clown: this happens?

jn: for sure

clown: what do browsers do?

jn: not sure, but a bug was filed and fixed on Firefox

rs: so label shouldn´t recurse on itself?

bg: have had form fields labeled by the previous form field

a kind of dynamic labeling technique

jn: a challenge there because you want the value of the field

mk: er, um

bg: FF gets label and value right now

mk: think IE is closer to spec

even though that´s a valid use case, spec doesn´t support

rs: from issue, continue following IDREF arcs until encountering one that´s already been referenced, then stop

is that the direction we want it to go?

various: think so

<richardschwerdtfeger> new text:

<richardschwerdtfeger> in other words, aria-labelledby is infinitely recursive until the point where it references an element that has already been referenced in this computation,

<bgaraventa1979> I'm in favor of making the value part of the calc for fields with values, since this is useful for aria-describedby in some cases

<richardschwerdtfeger> in other words, aria-labelledby is recursive until the point where it references an element that has already been referenced in this computation,

<clown> http://www.w3.org/WAI/PF/aria-1.1/roles#textalternativecomputation

<digging around in spec for wording to modify>

<richardschwerdtfeger> (in other words, aria-labelledby is recursive until the point where it references an element that has already been referenced in this computation, so it will not cause loops)

<clown> <span id="first" aria-labelledby="second"> … <span id="second" aria-labelledby="third"> … <span id="third">foobar</span>

bg: as I understand it should follow recursion until getting to node you´re on

jn: how could you ever reference value of something?

when there is a big massive algorithm, what authors do won´t result in something intelligible

mk: making it recursive is the way to make sure what comes out is ordered an intelligible

order of IDs is precise

when referencing an element, it´s already had its label calculated

jn: right now proposal introduces a problem

rs: says don´t want to go into infinite loop

jn: if someone references element with aria-labelledby, don´t use aria-labelledby

mk: that was how JamesC read it as well

makes it sound as if it goes only one level deep

but the issue is that it shouldn´t say that

and we never previously understood that

hear you as saying it should only go to one level

<scribe is getting very confused trying to scribe people´s recursive exploration of a question of recursion>

clown: @@

rs: <reads something>

<clown> <span id="foo" aria-labelldby="bar snafu foo" aria-label="foo-label"> <— the end of the label for this elemen tis "foo-label".

jn: not a problem as written, but think I´m reading it differently from you all

mk: @@

rs: so there´s a failsafe to stop recursion

<scribe> new text adds confusion?

jn: does everything think it does need to be recursive?

rs: what does it break?

jn: breaks grids

<grid example from start of this topic>

<Birkir> headers/id?

need to be able to reference a cell´s row and column headers, plus the row headers´s column header

<Birkir> true, .. breaks, for every cell you get the row header and column header of the cell, plus the column header of the row header column.

clown: we didn´t test this

don´t think we considered the issue

jn: but it´s a very real use case

rs: issue is one UA doesn´t compute names?

jn: can´t do these things automatically all the time

mk: grid only supports simple table constructs

rs: can embed one in another
... so, there is an issue with the current text

what would make it clearer?

jn: don´t know right now

mk: there is an action to straighten out the algorithm with a diagram

<clown> action-1474?

<trackbot> action-1474 -- Cynthia Shelly to Work with joseph s. and david b. to rewrite text alternative computation for both the aria spec. and the core accessibility api mappings specification. -- due 2014-07-07 -- OPEN

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

<clown> action-1475?

<trackbot> action-1475 -- Cynthia Shelly to Work with michael c. and joseph s. to create up to 4 accessibility diagrams showing the application (before and after) of applying role=“presentation”/none -- due 2014-07-07 -- OPEN

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

<jamesn> so am I correct i reading:

<jamesn> <input type="checkbox" id="flash">

<jamesn> <label for="flash">

<jamesn> Flash the screen

<jamesn> <input type="text" value="3" size="2" id="numTimes" aria-label="Number of times to flash screen">

<jamesn> times

<jamesn> </label>

<jamesn> results in "Flash the screen 3 times"

<jamesn> But

<jamesn> <input type="checkbox" id="flash" aria-labelledby="a">

<jamesn> <label id="a">

<jamesn> Flash the screen

<jamesn> <input type="text" value="3" size="2" id="numTimes" aria-label="Number of times to flash screen">

<jamesn> times

<jamesn> </label>

<jamesn> results in Flash the screen Number of times to flash the screen times

<jamesn> ... not quite the same issue but still weird

<jamesn> TPAC

<sorting of related actions>

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/practice/theory/
Succeeded: s/headig/heading/
Succeeded: s/hiding/hiding or showing/
Succeeded: s/<various>/various:/
Succeeded: s/you´reon/you´re on/
Found Scribe: MichaelC
Inferring ScribeNick: MichaelC
Default Present: Rich_Schwerdtfeger, +1.603.882.aaaa, Joanmarie_Diggs, janina, Jon_Gunderson, Michael_Cooper, +1.541.678.aabb, Joseph_Scheuhammer, Matt_King, Steve_Faulkner, +49.322.110.8.aacc, Stefan_Schnabel, Cynthia_Shelly, +1.415.624.aadd, James_Nurthen, Bryan_Garaventa, +1.919.607.aaee
Present: Rich_Schwerdtfeger +1.603.882.aaaa Joanmarie_Diggs janina Jon_Gunderson Michael_Cooper +1.541.678.aabb Joseph_Scheuhammer Matt_King Steve_Faulkner +49.322.110.8.aacc Stefan_Schnabel Cynthia_Shelly +1.415.624.aadd James_Nurthen Bryan_Garaventa +1.919.607.aaee
Agenda: http://lists.w3.org/Archives/Public/public-pfwg/2014Jul/0004.html
Found Date: 07 Jul 2014
Guessing minutes URL: http://www.w3.org/2014/07/07-aria-minutes.html
People with action items: 

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