- From: Joanmarie Diggs <jdiggs@igalia.com>
- Date: Thu, 22 Jun 2017 14:16:09 -0400
- To: ARIA Working Group <public-aria@w3.org>
Link: https://www.w3.org/2017/06/22-aria-minutes.html
Plain text follows:
[1]W3C
[1] http://www.w3.org/
Accessible Rich Internet Applications Working Group Teleconference
22 Jun 2017
See also: [2]IRC log
[2] http://www.w3.org/2017/06/22-aria-irc
Attendees
Present
Joanmarie_Diggs, MichaelC, Stefan, janina, jcraig,
jongund
Regrets
Rich_Schwerdtfeger, Matt_King, Tzviya_Siegman
Chair
Joanmarie_Diggs
Scribe
MichaelC, joanie
Contents
* [3]Topics
1. [4]Proposed normative changes related to
aria-roledescription
2. [5]Any reason we shouldn't make aria-expanded
supported on menuitem?
3. [6]Proposed normative changes related to
aria-errormessage
4. [7]Identifying anything at-risk
5. [8]Exiting and re-entering CR (quickly) to address
aforementioned issues?
6. [9]Creating a subgroup of ARIA WG to work on
Personalization
* [10]Summary of Action Items
* [11]Summary of Resolutions
__________________________________________________________
<joanie> clear agenda
<joanie> agenda: this
<joanie> agenda: be done
<joanie> agenda order 4, 2, 3, 5, 1, 6, 7
<MichaelC> scribe: MichaelC
<joanie> [12]https://github.com/w3c/aria/issues/500
[12] https://github.com/w3c/aria/issues/500
<joanie> [13]https://github.com/w3c/aria/commit/b6d1810
[13] https://github.com/w3c/aria/commit/b6d1810
Proposed normative changes related to aria-roledescription
jc: concern with roledescription only allowed on elements with
known roles
there isn´t 1:1 mapping of all possible roles
this restriction could prevent authors from providing useful
a11y guidance
<joanie> Existing text:
[14]https://rawgit.com/w3c/aria/master/aria/aria.html#aria-role
description
[14]
https://rawgit.com/w3c/aria/master/aria/aria.html#aria-roledescription
understand the restriction is to avoid superfluous use
<joanie> Proposed text from James:
[15]https://rawgit.com/w3c/aria/issue-500/aria/aria.html#aria-r
oledescription
[15]
https://rawgit.com/w3c/aria/issue-500/aria/aria.html#aria-roledescription
I get it for generic elements
but host language specific elements could benefit from
roledescription when there isn´t ARIA role
prevent ARIA from being bottleneck
<joanie> Discussion on commit between James and Joanie:
[16]https://github.com/w3c/aria/commit/b6d1810#commitcomment-22
558272
[16] https://github.com/w3c/aria/commit/b6d1810#commitcomment-22558272
examples: <code> which often is sub-typed
might want custom AT behavior on the specific type of code
sample
<meter> which can meter different types of things
authors should be allowed to describe the meter
HTML-AAM has 39 elements with no ARIA semantic
so this aspect of ARIA creates quite a limitation
jd: I get it for cases like <meter>, wouldn´t want to use a
less appropriate role in order to use roledescription
but hung up on generic elements (<div> <span>)
don´t want such elements abused and get away with it with
roledescription
could lead to different results in different platforms
do we trust authors to recognize what is truly semantically
meaningless?
jc: generic role would help
propose for 1.2
that would define which elements have that as their implicit
semantic
providing a better definition for our restriction
if that´s the solution, we might address the issue along with
that in 1.2
but the current wording creates a disallowance now
I´d rather soften the wording now and fix later
jd: the whole reason for that restriction is to avoid misuse on
generic roles
so don´t think we should take out
could imagine softening, but didn´t get consensus in last
discussion
led to proposal for ¨interactive element¨ but gather JC not
liking that
jc: <code> is example of one that doesn´t count as interactive
element
jg: why not use role=region?
with aria-label?
jc: limits future browser handling
right now not many UAs expose CSS 3 speech, but later they may
how they render speech could depend on the role
ss: we have role superposition cases, e.g., columnheaders that
are clickable so also button
might roledescription indicate the dual role?
make it interactive?
jd: doesn´t relate to interactive
ss: would keyboard handling be added to the role description?
jd: that´s a tangent
bg: for me not a problem to use roledescription on element
without role
bigger problem to use on element with explicit role
could cause UAs to do different things
ok to add description info to generic elements
unless they are used in way that implies a role
but can´t stop authors from doing that
<Zakim> jcraig, you wanted to say, what if we changed the
implementor requirement to UAs SHOULD NOT expose this on
elements determined to be generic, such as div/span.
jc: ATs try to do right thing for users, including correcting
for author mistakes
but it can be ambiguous whether something is an author mistake
to be on safe side, could speak both native role and
roledescription, though that could be redundant
there are author mistakes that cause huge problems, such as
marking entire page as hidden
or excessive verbosity in live region
yet we wouldn´t remove those features from ARIA
because used correctly they are valuable
I think this is like that
ok to correct for *obvious* mistakes
maybe say UA should not expose on elements determined to be
generic
allowing proprietary determination of what´s generic
<Zakim> joanie, you wanted to make counter proposal: User
agents MUST NOT expose the aria-roledescription if ... the
element to which aria-roledescription is applied is a div,
span, or
otherwise, leave with interactive wording for now, but don´t
close the issue, come back to it in 1.2
jd: uncomfortable with SHOULD
above wording to specify
jc: yeah, specific to HTML but basically works
mc: avoid getting specific to HTML, use div and span as ¨for
example¨
jc: JD proposal works for me
jd: will implement in a branch of your branch
Any reason we shouldn't make aria-expanded supported on menuitem?
<joanie> [17]https://github.com/w3c/aria/issues/454
[17] https://github.com/w3c/aria/issues/454
jd: since we plan to re-enter CR, was looking for things we
might have overlooked that we should fix
the text is clear aria-expanded is meant to be supported on
menuitem, it´s just not specified in the property list
it´s already widely implemented
bg: would like that fix, make sure testers don´t flag as an
issue
jd: objections?
ss: what about subroles of menuitem?
bg: not implemented on those
jg: APG also using in examples
mc: to avoid inheriting, would have to change taxonomy
bg: not a problem to inherit IMO
mc: we might care about the taxonomy impact, even though it´s
academic
jd: there are other examples where something weird inherits, we
lived with it
mc: probably better to inherit something useless than not
inherit something needed
Proposed normative changes related to aria-errormessage
<joanie> [18]https://github.com/w3c/aria/issues/587
[18] https://github.com/w3c/aria/issues/587
<joanie> [19]https://github.com/w3c/aria/pull/589
[19] https://github.com/w3c/aria/pull/589
jd: we discussed last week
I started playing around with implementation
filed issue, pull request, incorporated a couple rounds of
feedback
a subtlety uncovered is because of how aria-invalid works, need
to change ¨true¨ to ¨not false¨
even if we don´t put in this change, I think UAs will do right
thing
but if we re-enter CR, would like to put this in
<joanie>
[20]https://rawgit.com/w3c/aria/issue-587/aria/aria.html#aria-e
rrormessage
[20]
https://rawgit.com/w3c/aria/issue-587/aria/aria.html#aria-errormessage
Identifying anything at-risk
<joanie> [21]https://github.com/w3c/aria/issues/588
[21] https://github.com/w3c/aria/issues/588
jd: above are three things I think might be at risk, to add to
the at-risk statement upon re-entering CR
they have 2 implementations, but not implemented in the
mainstream UAs
MC asked Director for interpretation
have we heard back?
mc: no, but plan to ping in a standing call tomorrow
jd: if we don´t get Director concern, do we even need to
re-enter CR?
mc: those were the driving issues?
jd: plus the issue at top of call
mc: think this is mainly our call, rather than Director
decision
unless we get a strict response forcing CR re-entry, it´s up to
us to decide what´s the optimal strategy
Exiting and re-entering CR (quickly) to address aforementioned
issues?
jd: ^
Creating a subgroup of ARIA WG to work on Personalization
<joanie> scribe: joanie
MC: Lisa wants to make sure there is work happening on
personalization semantics.
<MichaelC>
[22]https://www.w3.org/TR/personalization-semantics-1.0/
[22] https://www.w3.org/TR/personalization-semantics-1.0/
MC: This spec was done under the ARIA umbrella, but by the coga
task force.
... This module contains attributes which can be used to drive
personalization.
... An example is distracting content.
... Your user agent could be used to turn such content off, if
you so choose.
<janina>
[23]http://lists.w3.org/Archives/Public/public-aria/2017Jun/003
4.html
[23] http://lists.w3.org/Archives/Public/public-aria/2017Jun/0034.html
MC: Some do not have a proper object content model, which could
lead to them being split up, or turned into roles (rather than
properties).
... We need the ARIA working group to be iterating on these
issues so that we can progress to having a usable spec.
... For this reason, there is a proposal to create a
subgroup/task force of ARIA to do this work.
... There's not much point in creating this task force if the
only active participant is Lisa.
JS: Tzviya's regrets message for today stated she thought
members from DPub would be interested in joining and
participating in this group.
Stefan: There's some potential, but what I don't know is the
boundary with ARIA.
... Will ATs pick this up from the DOM or something else?
... What discussion has occurred with browser vendors and AT
vendors?
MC: Regarding the first question (how these attributes play
nicely with ARIA) is a topic for the proposed task force.
... It is anticipated that the implementation would be done via
browser extension.
... For example, if you want to turn of distracting content, I
think a browser extension would do it by looking at the DOM.
... I'm not aware of a means to expose some of these things via
accessibility APIs.
<jongund> got to another meeting
Stefan: Some of these things would be of use to screen reader
users .
JS: This will also work with CSS media queries.
MC: Another of Lisa's important use cases is complex content.
... A tool needs to know what bits of information to summarize.
... Otherwise, a tool is in danger of including advertising in
the summary.
... So we need a way to tag these items.
... To some extent, those questions should be asked within the
group working on this document.
... So getting back to the question Joanie asked, is there
interest and committment in the group?
JS: Or maybe the question to ask is, is there an objection?
Because many people interested could be absent from this call.
MC: With respect to objecting, one cause might be we're busy
working on ARIA 1.1.
JD: I agree with busy working on ARIA 1.1. I fall into that
camp.
... But I also think that those of us buried in ARIA 1.1 are
not the same group with expertise in personalization.
MC: (Losing quorum because we're over time) We didn't get any
objections, but we don't have enough quorum for a resolution.
JS: I'm not sure if we need to have a CfC for this.
MC: We could draft a work statement.
Summary of Action Items
Summary of Resolutions
[End of minutes]
Received on Thursday, 22 June 2017 18:16:55 UTC