Accessible Rich Internet Applications Working Group Teleconference -- 22 Jun 2017

<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

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: 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

Any reason we shouldn't make aria-expanded supported on menuitem?

<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

Proposed normative changes related to aria-errormessage

<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

Identifying anything at-risk

<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

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> 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.

Accessible Rich Internet Applications Working Group Teleconference

22 Jun 2017

Attendees

Contents

Proposed normative changes related to aria-roledescription

Any reason we shouldn't make aria-expanded supported on menuitem?

Proposed normative changes related to aria-errormessage

Identifying anything at-risk

Exiting and re-entering CR (quickly) to address aforementioned issues?

Creating a subgroup of ARIA WG to work on Personalization

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output