- From: Michiel Bijl <michiel@agosto.nl>
- Date: Thu, 7 Jul 2016 20:08:50 +0200
- To: ARIA Working Group <public-aria@w3.org>
- Message-Id: <EB8FD15E-426B-4D1B-A291-849B3534B591@agosto.nl>
Minutes for today’s ARIA call can be found as text in this e-mail or at this URL: http://www.w3.org/2016/07/07-aria-minutes.html <http://www.w3.org/2016/07/07-aria-minutes.html>
Thank you Michael for scribing for the first 80 minutes!
—Michiel
[1]W3C
[1] http://www.w3.org/ <http://www.w3.org/>
- DRAFT -
Accessible Rich Internet Applications Working Group Teleconference
07 Jul 2016
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-aria/2016Jul/0032.html <https://lists.w3.org/Archives/Public/public-aria/2016Jul/0032.html>
See also: [3]IRC log
[3] http://www.w3.org/2016/07/07-aria-irc <http://www.w3.org/2016/07/07-aria-irc>
Attendees
Present
Rich, Jemma, MichaelC, Joanmarie_Diggs, Janina,
JaeunJemma_Ku, LJWatson, Joseph_Scheuhammer, jongund,
Bryan_Garaventa, matt_king
Regrets
Chair
Rich
Scribe
MichaelC, MichielBijl
Contents
* [4]Topics
1. [5]CfC Results
2. [6]Current Survey Results: aria-roledescription,
role=static/text
* [7]Summary of Action Items
* [8]Summary of Resolutions
__________________________________________________________
<MichaelC> scribe: MichaelC
CfC Results
- Move Password Role to ARIA 2.0
[9]https://lists.w3.org/Archives/Public/public-aria-admin/2016J <https://lists.w3.org/Archives/Public/public-aria-admin/2016J>
un/0068.html
[9] https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0068.html <https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0068.html>
- Approve changes to the separator role
[10]https://lists.w3.org/Archives/Public/public-aria-admin/2016 <https://lists.w3.org/Archives/Public/public-aria-admin/2016>
Jun/0069.html
[10] https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0069.html <https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0069.html>
- Approve changes to the spin button role
[11]https://lists.w3.org/Archives/Public/public-aria-admin/2016 <https://lists.w3.org/Archives/Public/public-aria-admin/2016>
Jun/0074.html
[11] https://lists.w3.org/Archives/Public/public-aria-admin/2016Jun/0074.html <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
[12]https://www.w3.org/2002/09/wbs/83726/2016-07-07_roledescrip <https://www.w3.org/2002/09/wbs/83726/2016-07-07_roledescrip>
tion/results
[12] https://www.w3.org/2002/09/wbs/83726/2016-07-07_roledescription/results <https://www.w3.org/2002/09/wbs/83726/2016-07-07_roledescription/results>
rs: no clear consensus
<Rich>
[13]https://www.w3.org/2002/09/wbs/83726/2016-07-07_roledescrip <https://www.w3.org/2002/09/wbs/83726/2016-07-07_roledescrip>
tion/results
[13] https://www.w3.org/2002/09/wbs/83726/2016-07-07_roledescription/results <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:
[14]https://rawgit.com/w3c/aria/action2092option3/aria/aria.htm <https://rawgit.com/w3c/aria/action2092option3/aria/aria.htm>
l#aria-roledescription
[14] https://rawgit.com/w3c/aria/action2092option3/aria/aria.html#aria-roledescription <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>
[15]http://rawgit.com/w3c/aria/action2092option3/aria/aria.html <http://rawgit.com/w3c/aria/action2092option3/aria/aria.html>
#aria-roledescription
[15] http://rawgit.com/w3c/aria/action2092option3/aria/aria.html#aria-roledescription <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
Summary of Action Items
Summary of Resolutions
1. [16]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
2. [17]Begin process of publishing a pseudo last call version
of ARIA 1.1 pending the survey
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [18]scribe.perl version
1.144 ([19]CVS log)
$Date: 2016/07/07 18:04:48 $
__________________________________________________________
[18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm <http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm>
[19] http://dev.w3.org/cvsweb/2002/scribe/ <http://dev.w3.org/cvsweb/2002/scribe/>
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34
Check for newer version at [20]http://dev.w3.org/cvsweb/~checkout~/2002/ <http://dev.w3.org/cvsweb/~checkout~/2002/>
scribe/
[20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ <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 LJWats
on Joseph_Scheuhammer jongund Bryan_Garaventa matt_king
Agenda: [21]https://lists.w3.org/Archives/Public/public-aria/2016Jul/003 <https://lists.w3.org/Archives/Public/public-aria/2016Jul/003>
2.html
Found Date: 07 Jul 2016
Guessing minutes URL: [22]http://www.w3.org/2016/07/07-aria-minutes.html <http://www.w3.org/2016/07/07-aria-minutes.html>
People with action items:
[21] https://lists.w3.org/Archives/Public/public-aria/2016Jul/0032.html <https://lists.w3.org/Archives/Public/public-aria/2016Jul/0032.html>
[22] http://www.w3.org/2016/07/07-aria-minutes.html <http://www.w3.org/2016/07/07-aria-minutes.html>
WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.
[End of [23]scribe.perl diagnostic output]
[23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm <http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm>
Received on Thursday, 7 July 2016 18:10:57 UTC