See also: IRC log
<joanie> clear agenda
<joanie> agenda: this
<joanie> agenda: be done
<joanie> agenda order 4, 2, 3, 5, 1, 6, 7
<MichaelC> scribe: MichaelC
<joanie> https://github.com/w3c/aria/issues/500
<joanie> https://github.com/w3c/aria/commit/b6d1810
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: https://rawgit.com/w3c/aria/master/aria/aria.html#aria-roledescription
understand the restriction is to avoid superfluous use
<joanie> Proposed text from James: 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: 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
<joanie> 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
<joanie> https://github.com/w3c/aria/issues/587
<joanie> 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> https://rawgit.com/w3c/aria/issue-587/aria/aria.html#aria-errormessage
<joanie> 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
jd: ^
<joanie> scribe: joanie
MC: Lisa wants to make sure there is work happening on personalization semantics.
<MichaelC> 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> 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.
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** Default Present: Joanmarie_Diggs, Rich_Schwerdtfeger, jongund, janina, jcraig, MichaelC, Stefan Present: Joanmarie_Diggs MichaelC Stefan janina jcraig jongund Regrets: Rich_Schwerdtfeger Matt_King Tzviya_Siegman Found Scribe: MichaelC Inferring ScribeNick: MichaelC Found Scribe: joanie Inferring ScribeNick: joanie Scribes: MichaelC, joanie ScribeNicks: MichaelC, joanie Found Date: 22 Jun 2017 Guessing minutes URL: http://www.w3.org/2017/06/22-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]