See also: IRC log
<joanie> agenda: be done
<Rich> scribe: Rich
zakim takeup item 2
joanie: Matt is familiar with
this and was very involved in the discussion
... meter became an issue in Safari
... I asked James Craig if he could create a pull request which
he did. He changed some language.
... he made a branch
<joanie> https://rawgit.com/w3c/aria/issue-500/aria/aria.html#aria-roledescription
joanie: this is James Craig’s branch
<joanie> https://github.com/w3c/aria/commit/b6d18109404
joanie: those are the diffs
<joanie> https://github.com/w3c/aria/commit/b6d181094048225f14789f269f3b4dad9ce25b51#commitcomment-22558272
<scribe> scribenick: MichaelC
mck: meaning known to AT has to be determined by attributes
rs: ARIA didn´t define role for interactive element
we have adequate structural elements
but lack interactive
so we should say
@@ roledescription @@ native element @@ platform mapping
avoid semantically meaningless
jd: gotta define ¨semantically meaningless¨
mck: this would change purpose of roledescription
to fill any role gap
which is pretty broad scope
normally if there is a hole in ARIA, we add a role
allowing roledescription on any element without implicit ARIA role creates slippery slope
jd: example of text containers
then we introduce paragraph
causing <p> to map to paragraph
would we use roledescription?
I think not
mck: others raised the issue, how do you know when to speak the role?
if it´s used on a generic element where you don´t speak role, such as paragraph
how do you know when to speak and when not?
jd: I´ve made assumption authors know what they´re doing
but in general @@
mck: I see ARIA as a canvas like CSS, authors can do yucky things with it but we don´t want to limit its scope to prevent that
also don´t want to limit reasonable creativity
jg: restrict elements to which it can be applied?
mck: we don´t control the relevant spec, that´s HTML-AAM
rs: not an issue for SVG
for HTML I´d say ¨interactive controls¨
we´ve got classes of roles
mck: can see using on certain of those
so we´d say ¨explicit role required unless interactive element in host language¨
rs: ¨with implied ARIA semantic¨
mck: +1
jd: +1
updated issue
<joanie> Rich (during meeting) mentioned "host language interactive controls" as a category of things which might not have an explicit or implicit ARIA role, but which should still permit roledescription.
so we´d be saying explicit roles, implict roles, or host language interactive controls support roledescription
rs: this should work around ¨semantically meaningless¨ which wasn´t working for us
jd: went to implement aria-errormessage
<joanie> https://github.com/w3c/aria/issues/587
found it didn´t say enough
asked questions and wrote proposals in that issue
mck: pertinent?
jd: if aria-invalid=true, then error message is pertinent
if aria-invalid=false, then error message is not pertinent
mck: that´s in the spec?
jd: yuppers
mck: see not applicable. does it mean not mapped?
jd: that´s the problem I´m trying to solve, it didn´t say
rs: could define it as author error so UA doesn´t have to deal with
mck: we´re trying to minimize author statements
rs: also trying to minimize UA burden
jd: depending on screen reader to do sanity checking means if they don´t all do it, users get inconsistent experience
mck: yeah, troublesome when I encounter this sort of thing as an author
<joanie> I would suggest something like, "User agents MUST NOT expose an element as a pertinent error message when the referencing element lacks aria-invalid="true".
mck: ...
rs: doing this makes the user experience no worse, at least
could be should or must
jd: my version is above
mck: so when aria-invalid becomes true, ua will add a relationship
will AT pick that up?
jd: aria-invalid would change, so a state change event
also probably other events
see the next topic in that issue
about hiding error messages that are not pertinent
<joanie> Authors MUST remove the error message when it is not pertinent, either by removing the element's id from aria-errormessage or by ensuring the referenced element is not rendered or has an aria-hidden value of true.
so I think most ATs would pick up from one of these events
mck: situation of aria-hidden yet visible?
jd: recording...
rs: @@
jd: that´s agendum, we´ll come back to it
<reads updated proposal>
mck: yes, better
<but quibbles>
jd: updated proposal
mck: great
<joanie> "Authors MUST remove the error message when it is not pertinent, either by removing the aria-errormessage attribute or its value, or by ensuring the referenced element is not rendered."
jd: I think this is ready to implement in branch and get WG review
mck: <couple specific details>
jd: I can make additional test cases
jg: does IDL have new error message?
jd: details has two relationships, error message has two relationships
for a while now
we need to test that all
jd: consensus on above proposal?
mck: where is ¨pertinent¨ defined?
<bgaraventa1979> +1 on proposal
<joanie> https://rawgit.com/w3c/aria/master/aria/aria.html#aria-errormessage
<joanie> If the user enters an invalid value for the object, aria-invalid is set to true to indicate that aria-errormessage is now pertinent. When aria-errormessage is pertinent, authors must ensure the content is not hidden and is included in a container that exposes the content to the user as it is expected that the assistive technology user will navigate to the content in order to access it.
<joanie> https://github.com/w3c/aria/issues/588
<joanie> If items are not marked as at risk, and we don't get implementation, we cannot advance past CR. But my understanding is that marking something as at risk, and then getting implementations, will not cause our advancement to be stalled. Therefore, it seems to me that if we suspect features might be at risk, we should identify them as such.
jd: based on the above impacts, I suggest marking 3 things as at risk
particularly if we want more than bare minimum 2 implementations
which I think we do
in DPub-AAM CR implementation, the Director asked about breadth of implementation
so we might want to expand that target
<summarizes current state of implementations, listed in the issue>
in sum, windows and mac could lack implementation, so even if we have others we don´t have the dominant platforms
jd: ¨at risk¨ doesn´t mean we lose it necessarily
mck: if we have minimum now, and mark as at risk, and nothing further happens, we could fail the risk condition even though we´ve implemented
mc: is question what Director will accept as sufficient, or how to achieve level of implementation we want?
jd: what Director will accpet
mc: then we can ask if he thinks we need these risk statements
jd: please start that conversation
<joanie> https://bugs.webkit.org/show_bug.cgi?id=159215
rs: we´ve been through this
would like to proceed on the basis of implementation commitments we´ve gotten
<more kibbitzing on various consequences of risk statements>
<jongund> Is there any time for me to ask some questions about MSAA and IAccessible2 implementation testing?
<Rich> Rich: Joanie, Matt - the reason we don’t have aria-posinset on rows ands we have aria-rowindex and aria-rowcount
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) Succeeded: s/mc:/mck:/ Succeeded: s/pertienent/pertinent/ Succeeded: s/mck: upside of proceeding anyways is if it gets author traction, UAs more likely to see need to pick up// Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** Present: Joanmarie_Diggs Rich_Schwerdtfeger jongund Found Scribe: Rich Inferring ScribeNick: Rich WARNING: No scribe lines found matching previous ScribeNick pattern: <MichaelC> ... Found ScribeNick: MichaelC ScribeNicks: MichaelC, Rich Found Date: 15 Jun 2017 Guessing minutes URL: http://www.w3.org/2017/06/15-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]