W3C

– DRAFT –
ARIA WG

07 April 2022

Attendees

Present
BryanGaraventa, chlane, Jem, joeyang, JoryCunningham ScottO pkra, MarkMcCarthy, myasonik, sarah_higley, siri, spectranaut
Regrets
-
Chair
JamesNurthen
Scribe
MarkMcCarthy, spectranaut

Meeting minutes

<jamesn> title: ARIA WG

<chlane> chlane+

I can scribe!

New Issue Triage

https://github.com/w3c/aria/issues/1718

jamesn: move to authoring practices

https://github.com/w3c/dpub-aria/issues/42

peter: this might be an aria issue

peter: might be a scott issue

jamesn: I'll add him to the issue

https://github.com/w3c/html-aam/issues/394

jamesn: I think this is in progress, steve is looking at it

New PR Triage

<jamesn> https://github.com/w3c/html-aam/pull/395

jamesn: cyns can you add comments on this?

jamesn: I added you as a reviewer

cyns: lets add james craig to get an implementer to look

Deep Dive planning Brief Status Updates

jamesn: I prefer not to have one next week, unless anyone really wants one

cyns: works for me I have a conflict anyway

jamesn: so the week after?

jamesn: we need a dpub aria meeting

jamesn: we could do it at an earlier hour to make it easier for everyone to attend

jamesn: we also need a catch up with open ui, maybe the week of April 21st?

cyns: can we do it 28th instead I can't make that week

jamesn: I'd like if we can do monthly or every other month with open ui?

cyns: can we do dialog 1st or 2nd week of may?

jamesn: I thinkw e can make progress without a meeting on some related issues

cyns: we can cancel it if necessary

jamesn: 5th of may holding for dialog deep dive

ACTION: james to schedule Dialog 5th May, OpenUI April 28

<trackbot> 'james' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., jcraig, jnurthen).

ACTION: jnurthen to schedule Dialog 5th May, OpenUI April 28

<trackbot> Created ACTION-2167 - Schedule dialog 5th may, openui april 28 [on James Nurthen - due 2022-04-14].

Handling Author Errors: form & region roles

jamesn: maybe we should skip until we have scott

sarah_higley: I think we should just merge this

jamesn: we have three approving reviewers - peter can you merge?

peter: yup

Inconsistency between native and ARIA listboxes when implicit aria-selected is provided

sarah_higley: the thing that scott brought up on the PR, but it points to something bugger, if you have roving tab index instead of active descent, then you want the one with tabindex 0 to have implicit selection, so what if they all have tabindex 0, this points to the broader issue that it is hard to assume based on the wide variety of how listboxs are authored, it is had to assume implicit selection.

sarah_higley: so if they all have tabindex=0, do they all get implicit selection?

matt_king: we made some rules about implicit selection last year... there are conditions underwhich user agents can assume implicit selection, by having those rules we were trying to accommodate legacy implementation, where people didn't specify selection at all in their implementation -- to make up for authors lack of explicit selection

sarah_higley: yeah, but the changes we made last year -- we took things in tree and added them to listbox. we didn't introduce a new functional change so much as we made something more explicit in listbox

sarah_higley: this is also a problem in tree

matt_king: so you are bring up a possibility that there should be no implicit selection based on focus -- but the primary objector is aaron

matt_king: I'm not so I agree with him

matt_king: ultimately, some of us would like to move implicit selection completely from the spec. which would be a different PR from this PR

sarah_higley: yes, but it would solve this PR

<chlane> aria/pull/1683 +1 to removing implicit selection

cyns: I am nervous about removing defaults

matt_king: it is a behavior that is being disallowed in more and more cases, and it is more "error correction" that implicit selection

matt_king: screen readers don't always tell you when something is selected, they tell you when it is not selected. does the non announcment of selection imply selection is a question we are discussing in APG

jamesn: sounds like we are going into a bigger rabbit hole than this PR is supposed to fix

sarah_higley: this rabbit hole did exist earlier. we talked about the issue where implicit selection is likely to be wrong, and we decided to go ahead anyway, and now there is just more and more reasons it is likely to be wrong. the problem with this change is that we say the browsers is going to guess as selection

<jamesn> https://github.com/w3c/aria/pull/1682/files

jamesn: that is not what I'm reading in the original

jamesn: previously, we it was using active-descendant, you only go the selection only got the selection WHEN the box has the dom focus

jamesn: the current language is confusing

matt_king: that is the problem with implicit selection, is that it relies on focus

matt_king: the user agent has to make a change to the authors content by making the selection stay after focus moves

cyns: why can't it do implicit selection when there is no focus

sarah_higley: the screen reader is communicated persistent selection where as there is no way to know whether that is intended

matt_king: if you have an entry int he listbox is "choose an item", should that be considered "selected"?

cyns: in an html select box it would be considered selected

sarah_higley: we have a focus without roving tab index in a pattern we made. All children are in the tab order in the dom, even though in reality the widget controls the focus, when nothing is selected, everything is considered selected by the browser

jamesn: do we have authoring guidance on this?

matt_king: yes

matt_king: it says ALWAYS use aria-selected

bryan: I'm favor of ignoring it

+1

cyns: should I close the issue as not a problem?

jamesn: it doesn't seem like we can make it better in enough cases to make it worth doing?

sarah_higley: should we add an authors should or must to clarify what should be done?

jamesn: "must" if you want the user to know for sure what is selected

jamesn: maybe we just point to the authoring guidance. we should have more links. we don't need a should/must

matt_king: good to have normative statements in aria to support APG

Secondary actions on items in composite widget roles

jamesn: this is a reminder to everyone to look at this and comment and participate! :)

<pkra> https://github.com/w3c/aria/issues/1440#issuecomment-1091984559

sarah_higley: I put an issue comment in with proposed specific thing

<jamesn> https://github.com/w3c/aria/issues/1440

jamesn: if we didn't change children presentational, can we make a normative must so that it is not included in any of these?

sarah_higley: the point is to allow siblings or children

jamesn: lets give it a week for comments, then try doing a PR?

When is hidden content taken into calculation of name and description? More In Depth Discussion agendabot]

<pkra> PR is https://github.com/w3c/accname/pull/150 ?

jamesn: everyone, please read comments! and comment, thanks. there are people who have been asked to review in teh issue

jamesn: simplification of accname for hidden subtrees

jamesn: its a significant change, the more eyes the better~

cyns: I'll add myself as a reviewer

Add combobox value support for aria#1225

spectranaut: i was looking through blocking issues and this looks like a difficult one

spectranaut: there's some discussion of an implicit value for combobox. when thinking about how to test that for Core AAM or anything, there's no spec for what it should be mapped to

spectranaut: plus, what do we do about accname if this is the case?

spectranaut: basically, there's not a lot of discussiona bout this case so I'm not sure what to do

bryan: I'd love to see a way to set an implicit value

jamesn: hurrah for that

jamesn: Matt, what do you think about this? if it were readonly or selectonly for instance?

matt_king: its name would be computed from content, basically. that content then is the value. In other words, what's the name if you ignore the label?

bryan: that doesn't translate well in the property mappings

spectranaut: that's what we're trying to fix

bryan: historically, you can have more than just that plain text content.\

matt_king: it's an authoring requirement that the content is the value

matt_king: if there's an icon in it, it has to be separate. so, if it's a select only combobox, it has to follow authoring requirements

matt_king: ideally*

matt_king: since we don't have value text, and at the time, there were other issues with value text so we figured we'd do this later

bryan: got it - so in another way, why is it a problem to support value text on a combobox?

spectranaut: let me rephrease, thank you for context

spectranaut: problem is we say how to specify the value, but in HTML AAM we have nothing for how to map that from a role=combobox

matt_king: it should be similar to how you specify the value for a <select>

spectranaut: so do we reference that? and if so, where does it belong?

matt_king: not necessarily referencing, but mimicking

matt_king: so basically in other words, how to we specify and map in the accessibility API, HTML AAM?

matt_king: would this be mapped similar to an aria select-only combobox then?

jamesn: i don't think HTML AAM covers that

jamesn: i'd also like to ask: how do we map the value of a textbox in core AAM?

bryan: it supports aria-valuetext

cyns: it doesn't

scotto: why would it, the value is in the textbox

jamesn: looks like it might inherit some things

matt_king: this seems like the exact same thing we're trying to achieve with spectranaut's question

Jory: is there some nuance with this, though?

matt_king: maybe in some javascript way, but that might depend on if you want a different value than the inner content

scotto: the option element works in the reverse in terms of aria-selected than a select does

matt_king: i think jamesn was on the right track, not sure there's a meaningful difference from role=combobox with editable content or not - the value is computed in the same way

bryan: i don't think there should be a difference if it's editable or not. but you should be able to set aria-labels or -labelledby if you'd like

jamesn: problem then is we don't say how to map values?

[general consensus]

spectranaut: i think this is a worthy consideration for a next todo

matt_king: we'd still need text cases, and arguably that might have to come first

matt_king: or at least with a lot of research

spectranaut: where do those tests belong, if not core AAM or HTML AAM?

spectranaut: or, where are the ARIA spec tests?

jamesn: core AAM

jamesn: the tests are in core AAM - every normative statement in ARIA has tests there

jamesn: this is definitely something we need to resolve for 1.2

jamesn: i'll talk to spectranaut about this and see what we can figure out

Summary of action items

  1. james to schedule Dialog 5th May, OpenUI April 28
  2. jnurthen to schedule Dialog 5th May, OpenUI April 28
Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).

Diagnostics

Succeeded: s/CORE/Core

Succeeded: s/do about accname?/do about accname if this is the case?

Succeeded: s/basically,/basically in other words,

Succeeded: s/specify this/specify and map

Succeeded: s/spectranaut'/spectranaut's question

Succeeded: s/we'/we'd still need text cases, and arguably that might have to come first

Succeeded: s/spectranaut: i was looking through blocking issues and this looks like a difficult one/scribeNick: MarkMcCarthy spectranaut: i was looking through blocking issues and this looks like a difficult one/

Succeeded: s/we have three approving reviewers/we have three approving reviewers - peter can you merge?/

Succeeded: s/jamesn: peter can you merge?/scribe+ MarkMcCarthy/

Succeeded: s/scribeNick: MarkMcCarthy spectranaut: i was looking through blocking issues and this looks like a difficult one/spectranaut: i was looking through blocking issues and this looks like a difficult one/

Maybe present: bryan, cyns, jamesn, Jory, matt_king, peter, scotto