<MichaelC> scribe: MichaelC

CfC Results

- Move Password Role to ARIA 2.0 https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0068.html

- Approve changes to the separator role https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0069.html

- Approve changes to the spin button role https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0074.html

rs: no objections, these can go forward

Current Survey Results: aria-roledescription, role=static/text

https://www.w3.org/2002/09/wbs/83726/2016-07-07_roledescription/results

rs: no clear consensus

<Rich> https://www.w3.org/2002/09/wbs/83726/2016-07-07_roledescription/results

opinions are all over the map

Cyns doesn´t want to deal with text / static in 1.1

Edge just finished implementing text pattern, which is no small task

so they may not want to open up rightnow

JamesC thinks roledescription is doable but a hack

which everyone agrees with I think

he´d prefer a role, but willing to move to ARIA 2 if we have the hack for now

SteveF and JamesN wanted this

(the role)

role=text implemented in Webkit

I don´t want misuse of roledescription

use cases for it were primarily education industry

so you could change a functional listbox to e.g., slices of pizza

just a way of exposing author presentation intent

<Stefan> +q

so APG would need to speak about misuse

ss: there are many specialized uses of options and listitems

supplemental role string saying look at documentation very helpful

jn: charts and graphs also benefit from this

mc: these are use cases for roledescription, right? would null roledescription impair those?

rs: no

we just don´t want people abusing it

lw: use cases focus on interactive component

yet spec specifically advises against that

yet @@ lost interaction

jd: initially expected stronger language

but would have made such uses author error

so we went to ¨discourage¨

because of user interaction implication

*if people really know what they´re doing*

lw: that´s clearer, but it´s still terrifying

as BG said, what about reverse where author implies nonexistent interactivity?

jn: more likely than misuse of button?

lw: that´s a case in point that they´ll do stuff like that

jn: authors can break ARIA today

lw: still don´t want to give them another way

rs: clearly authoring practices needed

mk: the third option I proposed focuses on the use cases originally proposed for roledescription

<clown> third option: https://rawgit.com/w3c/aria/action2092option3/aria/aria.html#aria-roledescription

think suppressing role is unneccesasry and high risk

<bgaraventa1979> +q

so I think option 3 is a good compromise

<Zakim> fesch, you wanted to say - I never used roledescription in charts

fe: I don´t like hacks

10 people in the universe will use it well

yet it will live forever because can´t remove a hack

<LJWatson> +1 to Fred

not sure pie chart is a good example; SVG is another language and will develop a separate taxonomy for chart a11y

don´t want a HTML hack to intrude on that

ss: there are good examples of beneifts of roledescription

maybe should consider restricting roles it can be used on

with some roles, there could be conflicts if using it

just saying ¨be careful¨ may not be enough

<mck> +1 to Stefan's statement that we need to tighten up roledesc text in the spec and possibly limit use.

bg: my concerns increase

sounds like this could alter semantics even of implict roles

could easily start to break stuff

AT users really rely on roles not being broken

e.g., if headings get broken, can´t navigate by heading

jd: that wouldn´t happen

mk: there´s an AT should that roledescription shouldn´t affect any behavior besides speaking role name

bg: that would be hidden functionality

because you wouldn´t know what are the headings that you can navigate

mk: option 3 has wording to address that

should only extend description of role

can put guidance in APG

not claiming this solves entire problem

bg: heard, but for the record think roledescription is dangerous

e.g., consider the pizza slices, how does user know they can navigate as a list box?

<Zakim> LJWatson, you wanted to suggest roledescription supplements the role announcement, then if isn't present defaults back only to role announcement.

lw: +1

what if roledescription supplemented rather than replaced?

rs: +1

bg: some things could be weird

lw: but if don´t do, users won´t know how to interact

jn: author needs to describe the interaction pattern

ss: the thing must be known to user

so documentation

mk: saw example of that

but you could also put roledescription on span

jn: then have to code a lot

mk: expect that would be the base use for this

still push towards option 3 because of the guidance

jn: option 3 seems not to address null roledescription

mk: it says null = absent

jn: really we´re looking at options 1 and 2; could add language to either from option 3

mk: really think it´s between 2 and 3, not 1 and 2

though wording for option 2 hard

rs: this started as addressing use case for text / static role

certainly issues if null roledescription could in theory wipe everything out

what if we just do it for img role?

recommend suppress role on null roledescription in just that case, but otherwise take matt´s preference

<mck> -1 to allowing null on image; unnecessary.

<jamesn> +1 to allowing "" on img

<LJWatson> -1 would strongly want to know when an image was an image, even when it contains only text.

mk: think this is a way to control screen reader verbosity, which seems not domain of aria

<MichielBijl> -1, images that only have text fail WCAG.

don´t think needed

jn: gave use case last week

with current ARIA, you lose the decimal that´s in the visual version

so needed static role with a label

<fesch> @clown in all other ways to bring SVG in a browser (as a file, inline, iframe, embed...) you get children in the DOM

mk: could do without null roledescription

lw: ??

<fesch> @clown it is easy to do <img alt='' so I don't see how it solves anything

jn: it´s not an image, it´s text

some of characters missing

need to override text presentation

<Zakim> clown, you wanted to ask if SVG is considered an image on some cases?

lw: use aria-label
... need to have a role to use label

mk: could use roledescription with some other role e.g., ¨price¨

in that example, decimal is the only thing missing

jn: it´s important

I didn´t write this, I found it on the web on a major site

mk: why hack ARIA when there are other approaches?

lw: @@

mk: is a high risk hack worth it

jn: I also dislike null roledescription

really want text / static role

but feel forced into this direction

rs: we already have text / static written up

but MS won´t implement right now

looking for an interim approach

jn: suppressing @@

mk: can solve other ways

jn: can always find another way

every role in ARIA is a way of working around something

mk: e.g., tree can´t be done

jn: but still most things

mk: still not clear why one more way needed?

jn: many other places this would be useful

don´t have examples right now, probably worked around in suboptimal ways

ss:

I think AT should always expose original role

that you could access via special function

mappings should not disable that

rs: on some APIs the original role is still available

not sure if all

agree original role shouldn´t be overwritten

think that´s generally agreed in AT vendor community

maybe need to state that in APG

for now, will the hack work, or do we just provide original role

right now, several say they have an issue

I´m ok either way, just want to meet the issue

right now, there is not consensus

note if we don´t agree, then nothing happen

mk: set roledescription to the text label you want

that´s seamless and doesn´t require null

<bgaraventa1979> I'm okay if a null value is only used on an image for this purpose, just not as a global attribute

so don´t need aria-label then

<jamesn> that is an even more cheesy hack

<mck> <img roledescription="hi">

<LJWatson> Why not use an alt to do the same thing?

js: would there be alt on this example?

mk: no

put alt=¨¨

js: that indicates it´s presentational

<jamesn> <div class="plan_cost" role="img" aria-roledescription="US$19.99/mo"><span class="superscript">US$</span>19<span class="superscript cents">99</span><span class="per_month">/mo</span></div>

lw: why suppress image?

mk: exactly

<clown> <img alt="" aria-roledescription="hi">

<Zakim> joanie, you wanted to say that is a horrible hack

jd: is user comes across a renamed role, they have to navigate to it and query to figure out how to interact with it

only to discover in this example that they can´t interact after all that effort

<jamesn> +1 to Joanie.... this hack is too horrible

<jamesn> <div class="plan_cost" role="img" aria-roledescription="US$19.99/mo"><span class="superscript">US$</span>19<span class="superscript cents">99</span><span class="per_month">/mo</span></div>

jn, jd: this is worse than null roledescription

lw: no

rs: label in roledescription - that seems quite wrong

mk: this supports more temporary nature of the hack

<MichielBijl> <div role="link" aria-label="submit button">Submit</div>

jn: with @@ can still determine it´s an image

<LJWatson> Rich:Q+ to say this feels like a hack to solve a minor use case, with the potential to break far more than it will ever mend.

mk: this is all about suppressing one word - ¨graphic¨

all the AT users here don´t care about having it suppressed

jn: but it´s not a graphic

mk: a different technique would be better

jn: that´s not always possible quickly

lw, mb: <overlapping>

jn: there´s a lot of QA to fix something

lw: why use img?

jn: it´s all we have. I wanted text / static, but that´s been punted

<Stefan> <span><span role="img" aria-roledescription="Multi-Dollar ">$$$</span> World</span> should announce "graphic Multi-Dollar World" ?

<Zakim> LJWatson, you wanted to say this feels like a hack to solve a minor use case, with the potential to break far more than it will ever mend.

lw: this hack is for one very specific use case sometimes, but can do a lot of collateral damage

<Stefan> +q

mk: @@ would fix the problem

jn: changing DOM also fixes, but that´s harder

this hack is so you don´t have to add nodes, just putting role on an existing node

<Stefan> <span><span role="img" aria-roledescription="Multi-Dollar ">$$$</span> World</span> should announce "graphic Multi-Dollar World"

ss: what is AT announcement in above example?

<clown> <div class="plan_cost" role="img" aria-roledescription="text"><span class="superscript">US$</span>19<span class="superscript cents">99</span><span class="per_month">/mo</span></div>

rs: the label in roledescription, that´s one of the most frustrating things I´ve had to deal with in APIs

me, I don´t support label in roledescription, but don´t have strong preference on other approaches

can only think of limiting to img for now

until we can deal with more substantially in ARIA 2

and get other implementers on board

mk: ??

rs: we don´t have consensus to include text / static in ARIA 1.1

but want to meet the use case

can we live with null roledescription just on img role?

<LJWatson> No

mk: are we voting between that or nothing?

remember the AT users aren´t concerned about the redundant ¨graphic¨ announcement

alternative between that and not solving problem?

rs: correct

this is holding up other things

trying to narrow scope

very clear there isn´t consensus

so exploring limiting to img, or doing nothing before ARIA 2

think JamesC, SteveF, and @@ will object to doing nothing at all

this proposal is essentially a modification of option 3

ss: is it analagous to alt=¨¨?

does it make the img presentational?

rs: similar, but providing a label

<mck> Proposed resolution 1: Solve speaking of the word graphic by allowing null roledescription onelements with role img.

<mck> Proposed resolution: Push off the image role speaking problem to ARIA 2.0.

rs: JamesN you could live with isolating to img?

jn: yes

<LJWatson> +1 to pushing to ARIA 2.0

<MichielBijl> 💩

<fesch> +1 to pushing to ARIA 2.0

rs: can people not live with proposal 1?

<mck> mk: can not live with #1; when push comes to shove.

<mck> mk: would rather wait.

lw: really prefer not; to be binary, I can´t live with it

rs: can people live with proposal 2?

<fesch> +1

<jamesn> so we can have this same discussion again in 2.0

<LJWatson> +1

mc: some people not present can´t live with it, so this will come right back

jn: punting to 2.0 just means the same objections there? Why wait?

mk: could scope more carefully

also I want to collect the killer use cases that justify the extra work

<JF> +1 to Leonie

lw: I don´t see the use case as critical, and echo that once a hack is out there we can´t retract it

<joanie> +1 to LJWatson

rs: I agree this is not critical for 1.1

note in 2.0 we might even need host language restrictions, so even more complicated

js: note we don´t need unanimity, we need preponderance

<jamesn> (text wasn't rushed - it was one of the first things in 1.1)

mc: this is political not practical; if people feel outvoted they can take to FO

can we avoid that by making people happy enough?

mk: FtF discussion with JamesC might help

rs: note role=text implemented all over ITunes

really want to avoid FO

<strategizing on a CfC that will deliver a clear result>

<mck> Proposed resolution: aria-roledescription="" will cause aria-roledescription to be ignored by user agents in all cases except for the implied or explicit img role where it would suppress speaking of the role by screen readers.

<Rich> http://rawgit.com/w3c/aria/action2092option3/aria/aria.html#aria-roledescription

jn: not clear on option 3 yet

<mck> Proposed resolution: aria-roledescription="" will cause aria-roledescription to be ignored by user agents in all cases except for the implied or explicit img role where it would be mapped to the accessibility API and enable screen readers to supress speaking of the image role.

<mck> Proposed resolution: aria-roledescription="" will cause aria-roledescription to be ignored by user agents in all cases except when an element has an implied or explicit img role where it would be mapped to the accessibility API and enable screen readers to suppress speaking of the image role.

fe: if role=img on span, would apply to span?

ech

<clown> <span role="img" aria-roledescription="">image stuff here…</span>

<mck> Proposed resolution: aria-roledescription="" will cause aria-roledescription to be ignored by user agents in all cases except when an element has an implied or explicit img role. If the element has the img role the aria-roledescription property would be mapped to the accessibility API to enable screen readers to suppress speaking of the image role.

<Rich> <span role="img" aria-roledescription="">image stuff here…</span>

<MichielBijl> scribe: MichielBijl

MK: I like that approach
... bit different than normal CfC

RS: Pick one, and hopefully we do better than 50/50
... Matt, can you create branch with that text in it?
... We'll put that to CfC as a vote

MK: Just like option 3 except that it has the exception in it?

RS: Everyone okay with it being a vote?

JS: I'm okay with it
... Not sure it's the best way

RS: It gives everyone a chance to vote

<LJWatson> WFM

MC: Something about CR edits

LW: Would this be a substantive change?

MC: Well no
... No process requirements

LW: Ah okay

<bgaraventa1979> got to head out guys, another meting

RS: Do we need a CfC for the straw poll?

MC: Not formally
... Is it a CfC survey?

JS: We've been misusing the word straw for a couple years now

LW: Can I thank the CfC senders for adding length and end date in the subject

MB: +1

RESOLUTION: Put up CFC survey for members to put in a special case of option 3 that tells ATs to suppress the the role when the role description has a null value and to move the text/static role to ARIA 2.0 or to accespt option 3 and move the text/static role to ARIA 2.0

*discussion about CfC about poll and survey*

<JF> no preference

RS and JS: I'm happy doing this parallel

RS: Michael can you start the process for last call draft?
... Let's see where we are next week

MC: Not much I can do process wise, except staging

JS: CfC goes out after the survey?

MC: Same time(?)

<JemmaKu> no objection with what Rich said

MC: We can send both simultaneous

RESOLUTION: Begin process of publishing a pseudo last call version of ARIA 1.1 pending the survey

RS: Start looking at time lines next week

<JF> bye all

RS: Thank you everyone for working on this issue, it's not the easiest one

<JemmaKu> Thanks everybody

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)

Succeeded: s/MC/MS/
Succeeded: s/+1/MB: +1/
Succeeded: s/RRSAgent: makeminutes//
Succeeded: s/RRSAgentm, makeminutes//
Found Scribe: MichaelC
Inferring ScribeNick: MichaelC
Found Scribe: MichielBijl
Inferring ScribeNick: MichielBijl
Scribes: MichaelC, MichielBijl
ScribeNicks: MichaelC, MichielBijl
Present: Rich Jemma MichaelC Joanmarie_Diggs Janina JaeunJemma_Ku LJWatson Joseph_Scheuhammer jongund Bryan_Garaventa matt_king
Agenda: https://lists.w3.org/Archives/Public/public-aria/2016Jul/0032.html
Found Date: 07 Jul 2016
Guessing minutes URL: http://www.w3.org/2016/07/07-aria-minutes.html
People with action items: 

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