ARIA F2F TPAC - Day 1 -- 16 Sep 2019

<jamesn> https://docs.google.com/spreadsheets/d/1eeq-xg0li2IKEIiyKsqhv-QOxArtbTV3m0OrG8ns-w4/edit#gid=1197832563

Introduction

<Jemma> Scribe:Jemma

rrsagents, make minutes

1.2 Tasks for publication

<joanie> https://www.w3.org/2018/11/aria-charter

Joanie: new ARIA charter

<joanie> https://w3c.github.io/spec-releases/milestones/?rec=2019-12-19

<joanie> https://w3c.github.io/spec-releases/milestones/?cr=2019-11-21

Joanie: we have the deadline to meet, Oct 3 2019.

"Latest date to request wide review of the Working Draft Thursday, October 24 2019"

<joanie> https://github.com/w3c/aria/wiki/Plans-regarding-role-parity

joanie: to meet the deadline of Oct. 24 we need to discuss about the scope for ARIA 1.2

<joanie> https://github.com/w3c/aria/wiki/Plans-regarding-role-parity#no-consensus-yet-need-to-decide-1-2-or-1-3

jamescraig: we should not do password

from the list of "No consensus yet"

<joanie> canvas (#927)

<joanie> details (#928)

<joanie> embed (#929)

<joanie> input (type=color) (#930)

<joanie> input (type=date) (#931)

<joanie> input (type=datetime-local) (#932)

<joanie> input (type=file) (#933)

<joanie> input (type=month) (#934)

<joanie> input (type=password) (#935)

<joanie> input (type=time) (#936)

<joanie> input (type=week) (#937)

<joanie> object (#938)

<joanie> rp (also check with i18n) (#488)

<joanie> rt (also check with i18n) (#488)

<joanie> ruby (also check with i18n) (#488)

<joanie> summary (#939)

jamesn: aria details in the agenda later.

JamesCraig: aria-details with summary can be complex..

cooper: I think aria-deatil is less of high priority

Jamesn: explaining about the concept of "generic role"...

<Zakim> MichaelC_travel, you wanted to suggest if you were creating a web component it could be substantially similar to equivalet HTML

jamesc: the reason for pushing role parity is in part for testing.
... multiple browsers can have the same context and so that they can consistently pass the testing.
... role parity can help each browsers can have consistent result for automated testing.

I was wondering of what exact differece James and Matt have since I think you two are talking the same thing.

spe: from web dev perspective, aria should be easily matched to html.
... I was wondering when JamesN talk about the complexity of "label" what complexity he is referring to.

james: I was thinking about how we can make acc name calculation be easier rather than going through multiple steps of name calculation.

group is talking about "complexity"...according to the level of developer expereinces, or the case framework developer

jaemsc: Therefore, additional ways to encapusulate like Matt king mentioned may give the flexibilty to different audiences.

Joannie: by the end of this week, we may need to decide from three options, 1)forgot about this, 2) partial implementation for role mapping, 3)naming for authors need to happen so we will get the name right and etc till ARIA 1.3. The group is going with option 3.

<ZoeBijl> Mockup for an ARIA label replica: https://codepen.io/Moiety/pen/a9d69ca0bbdadabb89828daed014203d / debug link: https://s.codepen.io/Moiety/debug/a9d69ca0bbdadabb89828daed014203d

<Zakim> ZoeBijl, you wanted to ask if reversing referencing for labels would have implications for AT?

Joannie: The group agrees that naming calculation should be consistent with HTML as much as it can in principle. The group needs more time for gathering naming calculation requirments. The related questions will be the detailed ARIA workflow such as implmentation, APG work, testing and more. The group will add the info to the notes for now so that we don't confuse the Spec users. Please refer the ARIA workflow documentation. https://www.w3.org/WAI/ARIA/workflow.
... If there is any issue like what Irfan addressed, plese file the issue to ARIA git hub so that the group can disucss/look into the issue.

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

irfan: do I file the issue individually?

joannie: avoiding the duplicate is preferrrable. please use your judgement. also the group does triage for the issues.

<Zakim> jamesn, you wanted to break

aria-brailleroledescription

https://github.com/w3c/aria/issues/1001#issuecomment-527125274

<ZoeBijl> scribe: ZoeBijl

<Irfan> https://github.com/w3c/aria/issues/1001#issuecomment-527125274

<joanie> https://raw.githack.com/pkra/aria/braille-props-roledesc/index.html#aria-brailleroledescription

JD: I put a link to the latest aria-brailleroledescription proposal

as you may recall during the 1.1 cycle we came up with roledescription

role descriptions can be pretty long

braille lines can be pretty short

if you allow authors to do something they will likely do it

JC: Are we proposing braille cells or strings as values?

JD: we’ll get into that

What Peter tried to do is…

encourage ETS the ability to do this but discourage authors from doing this

I want to get a feel for, are we OK with landing this?

Peter has been working hard on this and ETS has use cases for this.

I will open up the floor

JC: I think it makes sense

I proposed roledescription a while back

like “slide” comes up a lot

A bunch of native implementations of screen readers

Like voiceover

They pronounce Button, but print btn to braille

<Jemma> https://raw.githack.com/pkra/aria/braille-props-roledesc/index.html#example-28

In example 28 we have “pln” to mean “planet”

What it should be is a string that is then interpreted by ??

In VO your braille API accepts a string and that is then translated into the braille string

JC: If I understand your question, yes

If we’re going to print it to the braille display we pull it through an interpreter

JD: I’m not disagree, trying to understand

Isn’t btn always btn?

JC: Braille is different in every language

JD: Isn’t a B always a B?

JC: In western languages, yes

But in Japanese braille it’ll probably be different

JD: Any author that doesn’t know which braille cells to put in probably shouldn’t put them in.

JC: VoiceOver has specific braille string that are shortened etc

For example btn for button or pln for planet

Let’s say the role description is “people”

for grade 1 it would be printed as the entire string

In different grades it could be just the letter “P”

MK: I’m still sorta confused James

roledescription is like aria-label already

the localisation is the authors responsibility

you localise roledescription you localise the label

<jcraig> I’m saying:

<jcraig> aria-brailleroledescription="⠏⠇⠝"

role is localised, the role names aren’t localised

<jcraig> should be:

<jcraig> aria-brailleroledescription=“pln”

<jcraig> from: https://raw.githack.com/pkra/aria/braille-props-roledesc/index.html#aria-brailleroledescription

MK: JAWS has its own abbreviations for these things
... authors should provide a legend for the abbreviation on the page

JC: I’m saying that the brailleroledescription value should be latin characters rather than unicode braille characters.

<mhakkinen> +1 to jcraig's suggestion

MK: Say you have the string “bl”

I wonder if it could somehow end up being blind

JC: I have a colleague that’s from Germany. They use their entire system in English, except for braille, which is set to German.

There are only so many braille characters

What I’m saying is leave the translation (latin to braille) to the screen reader

JD: I don’t know if this is the case or not

Is there a case where you have a task where ?? would contract braille

MK: I don’t understand in the proposal what is the method for communicating the dots in the string

JC: I can paste the rendered characters

JD: The intent was that the authors already know what the localisation is

MH: I think I’m not a fan of putting braille characters there

I agree with James C

<chris_> Screen readers already handle contraction for Braille, so naively I think the description should be a long form description in the localized language.

*JC demonstrates VoiceOver speaking braille*

<Zakim> ZoeBijl, you wanted to ask if someone can provide information on these “grades”?

JD: So we don’t want actual braille characters in brailleroledescription

Is there anything else?

JC: There are different kinds of braille

JN: That’s my recollection of why this is there

MK: For roledescription the issue might be a bit different

<jcraig> An explanation of braille formats. https://www.seewritehear.com/learn/an-explanation-of-braille-formats/

JN: Ah then it might’ve been for aria-label

JD: What if we make it that authors can put in a non-braille string or the actual braille

We’re not gonna have maths in there

MH: Weeeeelll…

JD: Allowing authors to put in actual braille characters
... if they know what they’re doing

JC: Perhaps change the example to a non-braille string but still allow unicode braille input

Steer authors in the right direction

MK: That means that AT is required to do some preprocessing

to see which characters are in there

<joanie> https://github.com/w3c/aria/issues/765

Conclusion is in https://github.com/w3c/aria/issues/765

<melanierichards> scribe: melanierichards

Speech (James Craig issue)

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

jcraig: there's a number of diff ways to use your voice to control devices. Dragon Naturally Speaking, Android has one in beta (I believe). MacOS, iOS, we announced voice control. Soon to be released
... existing support in a number of these tools to use either the rendered text, or the accessible label, to activate it.
... rendered text is "more", label is "more about widgets", and you can speak either
... any mail app usually renders the check mail button as an envelop icon

<Jemma> https://developer.apple.com/documentation/objectivec/nsobject/3197989-accessibilityuserinputlabels

jcraig: what we've added to public API in iOS 13 is accessibilty user input labels, label synonyms
... we could render 1+ optional strings. "envelope" could be one of those. Screen reader user would only hear the primary label
... there's API that's currently on used by voice control on iOS, but in theory could be used by [missed] keyboard access
... 1+ optional things that can be used in addition to label to get to the element quickly
... don't want users to have to memorize different labels across apps
... not sure if this should land in ARIA, but seems like a good group to start
... I'm not convinced ARIA because ARIA doesn't really have concept of array of strings in a content attribute
... that's my proposal, questions?

mck: if it was part of DOM, are you saying that DOM would land some stuff in the acc tree? This has to get into a11y APIs to be useful

jcraig: yeah, say there was a property on an element that maps into APIs...the only problem with content attribute is what are you going to use for the string splitter? single quotes? Feels awkward

mck: so you're not suggesting we would add a new kind of attr value, like an array, in ARIA?

jcraig: I'm not suggesting that fits into the normal DOM attr content structure
... closest we have is token list; space separated. But some of these may have space in the string

mck: sure would be nice to have maybe JSON syntax for arrays in a content attribute?

[nervous giggling]

jcraig: I can come back with a concrete suggestion?

jamesn: seems reasonable, not 1.2 but can be worked on in parallel

jcraig: I could also take it to WICG
... could propose as DOM rather than ARIA

mck: if there isn't a way to express in content, seems interesting. What would you actually propose in a PR in ARIA?

jcraig: IDL for extending element interface for an array of strings. But ARIA hasn't done that yet, closest is reflected attr so far

jamesn: can you still do it in a declarative manner that way? Probably want to do it declaratively

jcraig: that's why I took it here, why do you think declarative? and how would you implement in the DOM?

jamesn: I have a feeling authors will want to do this in a simpler method than have to add scripting

mck: seems like you're already doing scripting here/

jamesn: [gave example of simple form button]

jcraig: anyone know of precedent for overloaded attributes, define the attribute, redefine the attribute, etc in a declarative fashion?

[quiet room]

jamesn: I'm not adversed to doing just in IDL, if it solves it for most users

<jcraig> such as foo=bar foo=baz, etc? or foo1=bar ffoo2=baz… I don’t know of precedent to that effect.

jamesn: solving for 90% sounds better than doing nothing

mck: if you did it in DOM, not you're for sure limiting it to scripting anyway. No advantage in ARIA unless we come up with declarative way to do it

jcraig: advantage is we can pull ARIA into contexts other than declarative interface
... could be a standalone spec as well

<aboxhall> `data` attribute might be a useful precedent?

Jemma: an ARIA property with a token list

<jcraig> tokenlist is space separated, but some of these strings may include spaces

Jemma: there's one for aria-dropeffect property

jcraig: token list is space-separated, and these strings might include spaces

mck: you could use another split separation character that you'd never include in a label, like a semicolon

jcraig: or a vertical bar

[Matt and James C agree feels messy]

mck: decision of what character you choose may have ramifications down the line
... maybe people go crazy for this kind of type

chris_: agree token list doesn't work here, there are characters that are unlikely to be spoken, but that seems special-casey to me.
... if we extend this concept down, and some are space-separated, others have different separator. Spaces are an innappropriate separator. Separator chars are assuming a certain context, like a certain spoken language

jcraig: I suppose we could backslash our spaces but that seems dirty too
... in those cases where we think it's rare to be used we could use backsplash

[noises of dissidence]

<Zakim> aboxhall, you wanted to discuss dataset

jcraig: open to discussion, don't think it should be a content attr

aboxhall: one places where we have precedence is associate arrays dataset. That's specially specced in the HTML spec, this would have to be specially specced too. Tricky
... aria-labelsynonym1, -2, -3

Jemma: we're not ready for implementation details yet, just brainstorming?

jcraig: yes

Jemma: what's next step

jcraig: I'll come back with a concrete proposal

<chris_> Link for dataset https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/dataset

jcraig: Alice's suggestion is the best one so far

<jcraig> clarifying: "Alice's suggestion is the best one so far”

<jcraig> I will not be including a declaritive content attr approach in the proposal, but off the brainstorming ideas, Alice's suggestion is the best one so far

<inserted> scribe: ZoeBijl

Table Ontology

<jamesn> "I propose a single segment on the topic of "Effects of ontology on table and grid" for discussing approaches to resolving the following 3 issues:

<jamesn> Issue #1022: (Consider prohibiting name from contents for rows in static (non-grid) tables.

<jamesn> Issue #1008: (Should aria-selected be allowed on row, columnheader, or rowheader in table?

<jamesn> Issue #79: WAI-ARIA 1.1: Cell and gridcell, which proposes depricating gridcell.

<jamesn> I don't believe we need non-WG participation.

<jamesn> I think it will take a solid hour or more to clearly layout the problems and weigh options."

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

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

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

ZB: Those are the relevant issues for this topic

MK: Highlevel, there are some places in ontology where we have the same role can either be a widget or a structure

And some places where we have two distinct roles

One for the widget and one for the non widget

One place where we have the same role for role and structure is row and separator

Normally like a row in a table is always a structure

A row in a grid is always a structure

A row in a tree grid can be both

Because it can be selectable

So that’s the same role for widget and structure purpose

Another example of this is separator

If it’s focusable it’s a widget

If it isn’t focusable it’s a structure

In some places we have the reverse

An example of that is grid cell and cell

If you have a cell in table

You use the cell role

but in a grid you use the grid cell role

So we have three issues open related to this

One is calling for the elimination of the grid cell role

That’s 79

Goes back aways…

1008 and 1022 are related to row

I can just see the writing for this “name prohibit except when…”

Same thing with rows being selectable

It’s only… I forget the properties that are on selectable

But there are certain states that only apply when it’s a widget

Not entirely sure what the best way to resolve these is

But in the future… ??

If the row has a pattern related to selectable then it’s a selectable row

but the way he ontology works right now

if it doesn’t support selectable directly it’s inherited from somewhere

The way it’s related to ontology is how ??

Certain states are either allowed or required and it becomes complex for both authors and validators

But if we were to go the path of adding more widget roles

So that summarises the issue

<Zakim> ZoeBijl, you wanted to say we should make it as easy as possible

<jamesn> ZB: earlier discussed making things easier for authors. Would different roles make it harder for authors?

<jamesn> For row for example in a table its a structure and if can focus its a widget

<jamesn> MK: the naming thing is interesting for row - if you allow rows to be named.... normally in a treegrid you want the name to come from contents but there are cases you want the name to come from a portion of the contents

<jamesn> if we prohibit naming on row except in treegrid - is that complicated?

MK: You should never make a row focusable in a grid

I could be wrong about that

JD: What if you had a message list

MK: Should you be using a grid?

I think it should probably be a tree grid

JD: The folder list could be tree grid

ABR: Another example could be a spreadsheet application, you highlight a row or column as a whole for some operations. Could be implemented with a separate header/label cell, but conceptually you're focusing the row.

MK: I heard of it being selected

But I’ve not come across an application of focusing the entire row

ZB: I do see people making rows focusable

Not sure that entirely related, just want to put that out there

MK: We should take a consistent approach to resolving all three of these issues

One approach is to say we have some legacy things and we accept that for what it is

Meaning we’d keep grid cell

How about table and grid

We added table

Because grid was supposed to be the interactive version of table

For all the things to go inside

Maybe it’s enough for the ancestor to be grid or table

Which would tell you whether it’s ineteractive or not

ZB: Makes sense to me

MK: it would make ARIA more forgiving

ZB: I’m in favour of deprecating grid cell in favour of cell

MK: How do we then deal with… ???

It would say “if context is a grid”

if context is…

We would never have it the other way around

JN: We have some inconsistencies anyway

JD: That sounds like a mistake

JN: Oh no it does

It inherits it, I missed that

MK: When you’re doing inheritance…

We need to have a script to propagate that

JD: We’re already doing this for some other things

So we I don’t see why we can’t for this

ZB: Are there implications to deprecating grid cell?

MK: We’d have to change how we list the supported and inherited roles

ABR: It would need to stay around as a deprecated synonym

MK: Something that would be improved is row and column header

We could have something like “only in the context of grid are they selectable”

JD: The funny thing is that it would take more time to come up with the script than it would be to implement the change

MK: You would need in the implementations make sure that certain things are disallowed

JD: That’s already in place for a lot of things

Chromium for sure

ABR: They’re already dealing with invalid attributes anyways

Some perhaps better than others

JD: I think it’s easy to solve in terms of implementations

JN: Do we have agreement on this

MK: we would say they’re not allowed when the context is table

In 1008

But is allowed in grid

For validators that are consuming our spec programmatically

We should try to be cognisant to make sure that we do this in a way that’s consistently parseable

There’s the ARIA query project

ABR: For these attributes that will be conditionally valid we need a machine readable format for that condition

JD: we have a different entry for…

Different condition for a table

MK: Is it possible for us to have two rows

JD: Not saying we should do this

But brainstorming

Could we have “cell (inside table)” and “cell (inside grid)”

MC: Someone said that there is already some complexity to this

Parsers need to be more contextually aware to process this

JD: That’s what we’re doing with this change (limiting naming of rows)

MC: I thought there was a reason for us keeping grids and tables separate

JD: We’re not changing that

*some discussion about aria-owns*

MK: The question was do we add a bunch of roles prefixed with “grid” or do we drop the grid ones that we already have

ABR: Authors get ?? wrong so often

If we can make more of those conditions implicit

Ratehr than alloweing authors to make invalid combinations

That would be a win for both authors and users

ZB: +1

ABR: It does make validation harder

But it follows the order of constituents

MC: I think we need to put extra clear flags about this in the spec

A note to implementors

*JD does hand wavey thing*

It’s something that could be easily missed by implementors

ABR: What Michael said goes back to what Matt said in the beginning

We already have cases where there are a lot of exceptions based on context, e.g. the separator role

MK: We did it in the section related to naming

<scribe> scribe: ZoeBijl

*short discussion about fixing the minutes*

MK: It might be, I don’t know if it’s nicer for the reader if it’s parenthetical or if it’s a separate list

JD: I’ll update the issues

the conclusion is that we’ll deprecate “grid cell”

It’ll be synonym

MC: We should have a path for deprecation

ABR: We encourage authors to move to cell

MC: Not just look at the change log, but make it a major change

MK: Do we want this to be 1.2?

It might be wise to take the same approach as we’re taking with naming related stuff

“This is our plan and we can merge stuff” but let implementors and AT to get on board

JN: What’s the hurry?

MK: Exactly, there’s no hurry

JD: Let’s move this to 1.3

MK: If we resolve 79 by changing it to a synonym

With deprecation we have more arguments for changing the APG

Make grid cell a synonym in ARIA 1.2 and plan to deprecate grid cell in ARIA 1.3

JN: ??

ABR: It’s probably good to focus on checking the implementations as to whether making “grid cell” a synonym of “cell” actually works

Make sure “cell” actually works in a “grid” role

MK: That’s a good point

That could be a test criteria

We don’t want o mess around with the implementation details between now and October

That would be a nightmare

Would be able to resolve 1008 and 1022 in the way we just discussed without deprecating “grid cell”?

I guess we can’t do it with row and column header

We already know that row works in grid, treegrid, and table

Or are we prohibited in some way

JD: I think that’s gonna be easy

They fixed the issue in Gecko

And it was never an issue in Chromium

JN: The gecko bug says that if it has an explicit ARIA role it will calculate the name, if it doesn’t have an explicit role it will not

MK: …allow aria-selected for that specific state

JN: That makes sense

MK: Also wouldn’t have to change the APG

JD: In terms of validation does that count as authoring errors?

MK: In the aria-selected section

of section 6

We also need to change it there

It has been changed in allowed roles

JN: All of that stuff is generated

MK: Ohh the used in and allowed lists are generated automatically

JN: …when someone updates the scripts

But yeah

<jamesn> https://docs.google.com/spreadsheets/d/1eeq-xg0li2IKEIiyKsqhv-QOxArtbTV3m0OrG8ns-w4/edit#gid=1197832563

web components status update

<Jemma> https://github.com/w3c/webcomponents/issues/826

JN: we’d like to update where we are on 1.2

Which came mostly from where you are

you being the web folks

There are a lot of things we’d like to get parity for in 1.2

Some of us are not entirely sure why we’re doing some of this work

LW: If memory serves me right

Google was a real champion of role parity

Especially Geroge Russel

You should be able to extend HTML things

or create entirely new ones

There are two types of custom elements

There are three specs, shadow DOM, templates, & custom elements

<aboxhall> templates, custom elements

This lets you take an excisting HTML element and extend its capabilities

The code can get really ugly so it’s not really popular

And webkit doesn’t support custom elements (?)

The purpose is to replicate HTML in all it’s glory

JN: There are some roles/elements we don’t plan to implement in 1.2

Because we’re not sure how to

So we’re aiming at incremental improvements

LW: That would be fine

MK: James Craig has proposed a way to move forward

JC: my way would improve the testing case but not the web components case

<chris_> 'testing'

JN: So once we decide we’re OK with not having everything in 1.2

We move to what do we do after 1.3

???

LW: I can only assume so

MC: Assuming we also finish role parity

JN: Depends

AK What’s attribute parity

JN: Anything to do with HTML attributes

ABR: Any attribute that has to do with accessibility?

JN: That’s the defined list

MC: If that’s complete…

I think there’s a lot of stuff that’s not mapped

distinguishing not mapped because it shouldn’t be vs. not mapped because it hasn’t been mapped yet

JD: I mean not mapped on purpose

JN: some things are exposed but not directly mapped

AK Do you get the attribute or the inherited concept?

JC: The ??

But it’s effectively the same thing as parity

<joanie> https://github.com/w3c/aria/wiki/Plans-regarding-role-parity

JD: Most of these are at least partially done

abbr for example

The big ones are under the “no consenses 1.3”

But a lot of them are input

For a lot we’re not sure how to deal with them

embedded object and ruby stuff

summary and details is gonna take us some more work than we anticipated

Like canvas

If you look at the “no consensus list” and see something that you absolutely need to have please let us know

LW: proxying for my colleagues, but we will let you know

Thank you for doing that

You’ve done an astonishing job

*round of applause*

JN: Thank you

ABR: Are there other cross issues that we should discuss with Léonie?

I don’t know the status of shadow DOM etc

*something about shadow DOM*

AB: I have a PR open about element reflection

Has been open for over a year

we’ve been going back and forth during that time

There are a lot of open questions around it

<jamesn> https://github.com/whatwg/html/pull/3917#pullrequestreview-189973949

<jamesn> https://github.com/whatwg/html/pull/3917

AB: intended for custom elements, which Léonie mentioned earlier, you can get the internals

That allows you to specify, among other things, ARIA and semantics

These are superseded by DOM ARIA attributtes

*some discusssion about default attributtes*

AB: Any of the ARIA state attributes would change dynamically

AK: The first itteration fo this API exposes form elements

ABR: So you said you came here expecting a discussion about what the ARIA WG should focus on

AK: If you take aria-describedby there is some deligation

Because the custom element could say “hey, it’s actually described by this element”

Because the details aren’t exposed to the outside

Something paralel to the custom ellement can’t know about the custom element’s internals

AB: Having trouble thinking of a usecase

AK: If you have a video element

it might have images for posters and you don’t want those for the name calculation

MK: YOu can’t chaing labelledby or describedby I don’t think

AK: You can’t reference IDs in the shadow DOM

*missed a part*

MK: but that couldn’t contain describedby references

AK: I was assuming it was text content

Like there are parts that aren’t relevant for a described case

AB: I’d be interested to see some more use cases for this problem

Say you’re implementing a custom combobox

POerfect example for active descendant

My active descendant is element 4

But how do you expose that?

AK: But it’s the CE’s shadow host?

AB: yes

AK: So you could set it to the shadow tree descendants?

AB: custom elements wants to refer to something inside the shadow host

AK: Is it the shadow tree?

AB: this is the labelledby case

But that’s bringing another element on the page into the mix

HTML Accessibility Issues

<zcorpan> https://github.com/whatwg/html/issues?q=is%3Aopen+is%3Aissue+label%3Aaccessibility

<tink> SP: Would like to discuss accessibility issues in HTML, and also how we (the WHATWG) can work more closely with the accessibility WG.

<tink> ... There is a list of issues on our repos that have the accessibility label.

<tink> ... The oldest of the open issues is to suggest a warning about the outline algorithm.

<tink> DD: There is an outline algorithm that is based on the idea that nested headings can be treated as lower level headings, but this doesn't match with current reality.

<tink> ... two ways to solve this, Anne has a proposal, and the other is to update the algorithm.

<tink> MK: Can you give more background on where the algorithm is implemented and/or used, and how that affects the AT experience.

<tink> DD: It was never really implemented.

<tink> ... it's more authoring guidance than implemented in browsers.

<tink> AVK: Implementing the algorithm in the browser is expensive.

<tink> DD: It's what the AAM has chosen to ignore the outline algorithm.

<tink> SP: It affects AT users in terms of how they navigate through headings.

<tink> JN: AT can also read the heading levels as well as navigate by them.

<tink> ... Wondering what we (the ARIA WG) can do to help?

<tink> DD: If we want to keep pushing for this algorithm, your help making that call would be appreciated.

<tink> MC: We should work out with the APA WG for review on this.

<tink> AVK: APA?

<tink> MC: Accessible Platform Architectures WG.

<tink> JN: It's the HTML AAM that'd need updating.

<tink> MC: APA is probably best placed to answer this question.

<tink> MS: Part of our expectation was that people who had strong feelings might be here, people liek Steve Faulkner, but they're no, so this might not be the best time to have this discussion.

<tink> JN: I'm familiar with the issue.

<tink> DD: We should re-spec the outline.

<tink> JN: The warning should be put in until that happens.

<tink> MS: There is a warning in the W3C conformance checker.

<tink> ...MS: The validator issues a lot of warnings, including about bad heading patterns.

<tink> SP: The validator also shows two different outlines.

<tink> MS: The validator is one of the few places where the outline algorithm is implemented.

<tink> AVK: We have an accessibility Github team, and we'd like to add more people.

<tink> DD: I'd like to hear from this group, about what you're intefrested in.

<Jemma> https://github.com/whatwg/html/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+aria

<tink> LW: How many accessibility issues are open?

<tink> SP: 20.

<tink> ABR: An issue about a radio group element, which gets to the idea, should HTML have parity with ARIA roles?

<AmeliaBR> Outline algorithm browser bugs: Chromium https://crbug.com/365070, WebKit https://bugs.webkit.org/show_bug.cgi?id=131920, couldn't find one for Firefox

<tink> JMD: What if we hada non-numerical heading element?

<tink> JN: Read the outline issue, it's all in there.

<tink> MS: Backwards compatibility is part of the problem.

<tink> SP: Argument is that it's better to have a flat list of headings, than nothing.

<tink> JC: In the case of <div role="heading"> with no explicit role, it's exposed as an h2.

<tink> ... There are screen reader commands for "jump to heading at next same level", which is useful functionality especially in large documents.

<tink> ...I'm not aware of any disagreement internally with the current proposal for the algorithm, it isn't high on our priority list.

<tink> AVK: There is a carrot in terms of styling too.

<tink> SP: Tested James' example and according to devtools it's an h2.

<tink> LW: Not convinced that breaking backwards compatibility with headings would be terrible, because headings are almost always broken hierarchically in the wild at the moment anyway.

<tink> JC: Having some kind of HTML data provider that is queriable with scripting would make somethings, like scrolling patterns, much easier.

<zcorpan> https://github.com/WICG/virtual-scroller

<tink> DD: There's a proposal for virtual content.

<tink> ... It's better to encourage people to put the data in the DOM, but right now that's expensive, and so we'd need to improve that first.

<tink> ... So the cost is based only on what's displayed on the screen.

<tink> JC: There might be hundreds of thousands of things in the dataset.

<jamesn> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/Accessibility/VirtualContent/explainer.md

<tink> DD: If it's a vast dataset then that proposal is intended to help.

<tink> JC: Making it possible to use find functionality to search the dataset would be a useful feature.

<tink> DD: I think the virtual content proposal had server hooks?

<tink> AB: No, it's based on scrolling.

<tink> ABR: Maybe an issue on that proposal to ask for hooks?

<tink> ...If it was based on user events, like when a user tabs into the area, or when a user searches for something inside the area?

<tink> DD: You'd want a hint to the server, "they want the next heading" etc.

<tink> JC: Platform acc API have something similar.

<tink> AVK: It would be very observable that you were using AT.

<tink> ABR@ If there's just a generic "load more" API, that might help with that.

<tink> MK: Why would it make it observable you're using an AT?

<tink> JC: I think Anne was saying there is no UA that does something like heading navigation.

<tink> MK: GoogleDocs does.

<tink> JC: That's the application though, not the screen reader/AT.

<tink> ABR: On the issue of a hidden-like attribute, that's a case of speccing something that has strong use already on the web, a method to hide things visually but not from AT like screen readers.

<tink> SP: Like display:none; but still available to screen readers?

<tink> JMD: aria-hidden="false" was intended for this purpose, but it's not been implemented.

<tink> SP: Since developers use CSS hacks to get this, it shows there is demand for it.

<tink> JC: There is demand but there are also implementation challenges.

<tink> ... Webkit supports aria-hidden="false" to a degree, but it got complicated because of the rendering block/tree.

<tink> AVK: You used a flattened tree to create the acc tree?

<tink> JC: We ended up making it so that you could only hide something one element deep I think.

<tink> JN: I think we've taken aria-hidden="false" from the spec?

<tink> MK: How? I don't remember.

<tink> JC: Think it wasdeprecated.

<tink> SP: You can use aria-label/labelledby to add information for a "more" link.

<tink> JN: I've seen hidden text used in situations where you use something like the <del> element.

<tink> MK: Or where there's no visual heading but a navigation heading would be useful.

<tink> JN: Could use <span role="heading aria-label="heading text">...</span> or something?

<tink> LW: Does aria-label get exposed on that?

<tink> SP: headings have an accessible name so I think so.

<tink> JC: Perhaps an @screenreader CSS media query?

<tink> AB: Often wanting to do this is a design flaw.

<AmeliaBR> The CSS version of this feature request: https://github.com/w3c/csswg-drafts/issues/560

<tink> .. there are somethings legitimate use case, but I wonder what proportion they make up?

<tink> MK: Another case is stuff that gets displayed only on hover or focus, but when you browser with the virtual cursor you want it there all the time.

<tink> JN: So the question of whether we want equivalent HTML elements for all ARIA roles?

<tink> ABR: Yes, issues 4180 on the HTML repo, and #2463 on HTML also.

<tink> JC: Switch was added to ARIA 1.1 because checkbox on/off wasn't sufficient for the tri-state switch controls being used on mobile.

<tink> MK: This gets into what you should develop using ARIA and script, and what you shouldn't. Where do you draw the line?

<tink> ... Seems HTML should be the ones to draw the line here.

<tink> JC: There are things like the icons that could be changed if it was a native feature.

<tink> ABR: To the more general question, are there roles that exist in ARIA that should have HTML equivalents?

<tink> AVK: If there are use cases it makes sense.

<tink> DD: My team has been working on this, switch, but also other elements.

<tink> ... It's hard to ship new elements, because getting developers to say "we'll replace our thing with a native thing", because of librarries and other reasons.

<tink> ... It's hard to extend. Last time we tried it was <dialog> but it only has one implementation.

<tink> ... There are tactics, one I've explored is using custom elements and technologies like that, but it's just hard.

<tink> LW: Have there been successful examples where a pattern has been implemented natively and been taken up?

<tink> DD: Input elements like email perhaps.

<tink> MK: details and summary.

<tink> SP: video and audio elements.

<tink> DD: There is a discussion tomorrow about switch.

<tink> ... author focus handling is limited to tabindex and that's a problem for the switch pattern.

<tink> ABR: What about arrow based navigation like cycling through a set of radio buttons or such?

<tink> DD: And whether tabs in a tabset are arrows or tabs.

<tink> SP: What's needed?

<tink> ABR: A way to do these things that doesn't need event listeners.

<tink> DD: Something like a scoped tabindex?

<tink> AB: To say this container groups a set of similar elements that should be navigable in a certain way.

<tink> ABR: So the container would get the tabindex, then aria-activedescendant could be used, but you have to listen to all the keypresses yourself.

<tink> JC: There are some proposals in the AOM that look at user input events, and some semantic events, that could be interspersed with existing events.

<tink> DD: Are people familiar with the behaviour in chrome, and possibly others, have implemented where you tab between the three date fields in a date picker?

<tink> ... currently it's tabs.

<tink> MK: Not aware, would be good to see an implementation test case.

<tink> DD: I can share one.

<tink> ... But you tab through the three day, month, year fields inside it.

<tink> JC: So it's a single element with three tab stops?

<tink> DD: Yes.

<tink> AB: Like a video element has controls.

<tink> JN: On a date heavy page it sounds like a lot of tab stops.

<tink> MK: For a screen reader user it's hard to have to keep moving between fields to find out which year the month relates to etc.

<tink> AB: A related question of things that are tab traps.

<tink> ... things like modals.

<tink> MK: Also non-modal things with application behaviour.

<tink> ... Where there are containers with their own tab ring, but that you can navigate to using f6. Replicatingthat on the wbe is hard.

<tink> AVK: Does this relate to focus groups?

<tink> DD: It's only at the document level.

<tink> SP: The concept could apply to this though.

<tink> ... Could specify that two elements are two different focus groups, then have a feature to move between focus groups.

<Domenic> Example of native <input type=date> with three tab stops: https://boom-bath.glitch.me/native-input-date.html

<tink> AB: Yes, focus groups, and modals, all related.

<tink> ... GoogleDocs grid view is a good example of where this behaviour is implemented.

<jamesn> scribe: jamesn

Calculating Group Position

<joanie> https://github.com/w3c/core-aam/issues/52

JD: this is 1 of 2 issues - not the main issue

<joanie> https://github.com/w3c/core-aam/issues/49

Added the other issue

SF filed that FF is caluculating posinset and setsize when there is a separator as separate sets

<joanie> Section https://w3c.github.io/core-aam/#mapping_additional_position States

<joanie> "Otherwise, if the role supports aria-posinset and aria-setsize, process the parent (DOM parent or parent defined by aria-owns), counting items that have the same role."

the other issue - issue 52

<joanie> This is not correct. A menu should count all the menu items no matter the type (menuitem, menuitemcheckbox, menuitemradio) not just items of the same role

Aaron stated same platform role - but that doesn't work on all platforms

posinsset and setsize - what are they supported on?

do we know what would happen with associationlistitemkey and associationlistitemvalue

JD: to me the questions are - if you have a separator and don't have a group object - do you reset your count every time you have a separator

MK: the separator is not intended to be a semantic thing - but a visual presentation thing
... they never get exposed

JD: I've seen menus where you can arrow to the separator

MK: if you want grouping in a menu you want a group

MK: we don't have the concepts of various required owned element things

<BGaraventa> I don't think I have the right dial in code, the line is sielent

<BGaraventa> nvmind, I hear you guys now

<joanie> scribe: joanie

<jemma> http://a11y.pro/combobox-TPAC2019/

The above link is to Matt's presentation

The presentation doesn't directly address HTML issues yet, but we'll talk about them.

http://a11y.pro/combobox-TPAC2019/#/2 (Evolution of the Combobox Structure)

Matt: In 1.0 only a listbox could pop up and it was owned by input.
... Now we have a div wrapper with a text input with a sibling element which pops up.
... You can construct this relationship in two different ways.
... The relation between the pop-up and input is aria-controls.
... The relationship between the wrapper and widgets is an owned relationship.

http://a11y.pro/combobox-TPAC2019/#/3

Matt: Why did we change it in 1.0?
... Because of aria-owns, listbox is a child of textbox.
... Screen reader users can perceive listbox options only when interacting via keyboard.
... Only way to get access to the options is that focus change events come as a result of aria-activedescendant + use of arrow keys.
... If you're using any type of touch device or are in reading mode, you're not going to see any of this.
... That is the problem we wanted to solve: We didn't want the listbox inside.

http://a11y.pro/combobox-TPAC2019/#/4

Matt: Regarding the 1.1 structure, the div has the combobox role, but it isn't focusable. What's focusable is a textbox.
... So it's not actually clear what that textbox is when you Tab to a combobox. What is the screen reader supposed to say and do?
... This is something we didn't really define. Plus it's a pretty different way for screen readers to have to handle.
... The other problem we ran into is when you're naming this, WCAG says you have to name the input because it's focusable.
... But you also want to name the combobox itself. So what do we do?

http://a11y.pro/combobox-TPAC2019/#/5 Has a summary of all the structural issues in 1.0 and 1.1.

Matt: In addition to the previously-discussed issues, the container adds unnecessary complexity.
...

Does not correspond to anything visible in the UI.

Does not add value for screen reader users.

Like requiring a wrapper around a menu button and the menu it opens.

http://a11y.pro/combobox-TPAC2019/#/6 Has proposal for 1.2

Matt: I propose we treat combobox similar to a menu button that controls the menu.
... The slide says "text input" but it doesn't have to be a text input; it's an input.
... Browsers could still support the 1.0 pattern. It's pretty straightforward.

<BGaraventa> +q

Matt: But we'd nuke what we're doing in 1.1 and replace it with what I'm proposing for 1.2
... Namely, a listbox controlled by an input.
... The 1.2 version can be found here: https://raw.githack.com/w3c/aria-practices/aria1.2-combobox-proposal/examples/combobox/combobox-autocomplete-list.html
... In testing, the 1.2 version is working out of the box in both reading mode and interaction mode.
... All of them see the combo box, present the combobox, can perceive the listbox, etc.
... There are a few bugs, but the basics work.

https://raw.githack.com/w3c/aria-practices/aria1.2-combobox-proposal/examples/combobox/combobox-autocomplete-list.html

Matt: There's also a link to it in the ARIA pull request.

BG: Are you using aria-activedescendant as the user up and down arrows?

Matt: I believe so, yes, but I would have to look.
... I took the 1.0 version and changed 2 lines of code, one in html and one in JavaScript.
... I changed aria-owns to aria-controls.
... I had to make a similar change in the JavaScript because it was using an attributte selector, looking for aria-owns.

BG: I've seen people try to put the listbox inside a button. We want to discourage that.

Matt: At this point in time, we don't have an example of a combobox which doesn't have an edit. But if we make this change, we'd of course also want to write such an example because it's a very common use case.

http://a11y.pro/combobox-TPAC2019/#/8 Has Related GitHub Issues

Matt: A couple of these have actually been closed, but the question is which changes we need to support if we go this path.

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

The Combobox 1.0 design pattern references incorrectly include aria-owns instead of aria-controls. #998

Matt: This issue is confusing people because where the property goes.

https://github.com/w3c/aria/issues/776 aria-controls a required property for Combobox?

Matt: All of these issues stem from the fact that we have the combobox wrapper and the thing which is not a combobox (i.e. the input)
... If we don't have a wrapper and the input itself is the combobox, it's unambiguous where the aria-controls goes.
... So making this proposed change will solve these issues.

http://a11y.pro/combobox-TPAC2019/#/10 Naming issues

893: 1.1 Combobox pattern endorses unlabelled form fields

909: Clarify combobox label placement

1046: Does combobox require an accessible name?

Matt: The screen readers have never exposed a wrapper before for a combobox, so why would they expose a wrapper?
... So again, these three issues get solved with the 1.2 proposal.
... Those are the structural problems. Now I want to talk about the definition.
... 1.0: A presentation of a select; usually similar to a textbox where users can type ahead to select an option, or type to enter arbitrary text as a new item in the list. See related listbox.
... In 1.1 we made it a lot more clear.
... A composite widget containing a single-line textbox and another element, such as a listbox or grid, that can dynamically pop up to help the user set the value of the textbox.
... One of the problems here is that historically there are a lot of comboboxes in the world that don't have a textbox.
... We kind of drewe a line in the sand, saying essentially "these are not comboboxes"
... We've received a large amount of pushback as a result.
... There's an issue in HTML-AAM regarding mapping of select element with size of 1.
... Another conflict I call the "readonly conflict"

Matt: You can select the text, but it gets announced as a read-only combobox. This is really confusing.
... Because the popup functionality that allows you to change the value isn't disabled, yet it's spoken as readonly.
... The purpose of having this attribute on the input is so the end user can tab to the input and examine and select the text.
... Authors get the info for free.
... But you can change the input from the popup, so it's not a readonly input.

Amelia: Do we have a way to override this, like aria-readonly="false"?

Matt: But what would that do?

JN: Who wins?

Matt: But that might cause it to be presented as an "edit combobox" which is wrong because it's a select box.
... We also have the issue that in HTML you cannot use readonly and required on the same thing.
... The goal is that we want input type="text" readonly functionality, but we don't want it announced as readonly. But I don't know how to solve that yet.

http://a11y.pro/combobox-TPAC2019/#/13 Proprosed 1.2 definition

Matt: There are loads of changes here.
... An input that controls another element, such as a listbox or grid, that can dynamically pop up to help the user set the value of the input.
... The input could be a textbox, but it doesn't have to be.
... The difference is that you could take a button, give it a combobox role, give it a label which would be separate from the value, and make it required (which you cannot do on a button).

http://a11y.pro/combobox-TPAC2019/#/14 Summary of 1.2 Changes (PR 1051)

Revise definition of combobox to encompass implementations that do not support text editing, such as some implementations of the HTML select element by browsers.

Revise description of the structure of combobox so the element with the combobox role is the focused element instead of a wrapper that is not focusable and the relationship with the popup is defined by aria-controls.

Change the super class to input from select so it describes the actual structure; select is a composite and the revised combobox structure does not include any focusable descendants. This also has the beneficial side effect of removing aria-orientation, which is not applicable.

Add aria-activedescendant as a supported property because it is no longer inherrited from its super class.

Remove all required owned elements. A combobox no longer has any descendants.

Change section 2.3 (id=“managingfocus”) to remove combobox from the list of composite widgets and for clarity and compatibility with revised combobox structure.

Editorial revisions to the definition and description of the aria-activedescendant property to reflect the changes to the combobox structure.

Matt: To the best of my knowledge, this fixes all the open issues related to combobox. It does NOT solve the readonly issue I mentioned. (Not currently filed)
... We're done revising combobox is we make these changes.

Melanie: I really appreciate all the work that went into this.
... The one challenge is, if we make another revision, we want to make sure it's airtight.
... In UIA a combobox is a composite container.
... I would be concerned about supporting this proposal because it doesn't make sense in my API.

Matt: How does it not make sense?
... We don't have to make any mapping changes in any platform.

Melanie: But the structure is different from what we're expecting.

Matt: We tested this with Narrator and Edge and the user experience is better with the 1.2 example than the 1.1 example.

Melanie: But if it doesn't align with the structural assumption UIA has, there may be breakage later.
... And then you would have to write web specific code.

Jemma: I'm trying to understand your concerns.

Melanie: There would be no work on my end (browser) to support what Matt is proposing.
... But the accessible hierarchy doesn't match what we see in the native equivalent.

<melanierichards> https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-supportcomboboxcontroltype

Jemma: What kind of damage is done when there's a structural change?

Matt: Do you assume a wrapper for a menu button?
... Do all the structures in HTML match what's in UIA.

Melanie: That's the challenge. We do the best we can. We provide access via the AriaProperties property.
... What concerns me is that we are choosing to go against what's exposed via the API.
... Can we work with screen reader developers to make the 1.1 version work better?

Matt: Right now we have so much author confusion with the 1.1 because it doesn't look like anything people are familiar with.
... The thing that gets focus isn't the thing that has the role.
... That's unlike anything else we have in ARIA.
... We're always telling authors to focus the thing that has the role.
... But here, in the 1.1 combobox, we're telling authors the opposite.

JD: This can be solved in ATs.

Matt: You can hack, but.... With most composites you have multiple things inside which can get focus. And you manage the focus.
... the user sees the container, then the child.

<jamesn> JD: like the proposal as simpler. Other thing just say on the record

<jamesn> in response to Melanie - there are a bunch of things which don't look like neative

<jamesn> and screen readers have a bunch of hacks and workarounds - all screen readers have to deal with "the web"

<jamesn> seriously while i sympathise - in UIA it may look different but the rest of us just cope with it.

<jamesn> if the problem is you have a combobox container - you ascend the ancenstry. if nothing has cuased the listbox to be presented then providing context is something screen readers do

<jamesn> if you tab to a window the window ancestor should be presented. Why don't NVDA and JAWS look at the textbox and see there is a combobox ancestor and present as a combobox

<jamesn> MK: could special case it... could have a wrapper without calling it a composite...

<jamesn> JD: how is this special?

<jamesn> MK: the grid never gets focus. the grid and structure get exposed.

<jamesn> JD: but why does that happen?

<jamesn> JD: If i land in a cell in the middle of a grid... the screen readers say i'm in a table ..... i guess I should tell the user about the grid

<jamesn> JD: why can't screeen readers do that for comboboxes

<jamesn> MK: things aren't aligned

<jamesn> JD: so many things aren't aligned

<jamesn> MK: what it would take to fix 1.1 without making changes to definiton - if we were to keep the structure - we would need to get screen readers to support both 1.0 focusable input and also would have to look up the tree for some of the information.

<jamesn> MK: the hardest part for authors is to determine what goes on what

<jamesn> MK: what actually belongs on the input and what on the parent

<jamesn> MK: people don't understand what goes on the input and what goes onb the combo

<jamesn> MK: could be permissive and allow aria-expanded on wither

<jamesn> MK: no point to authors or screen reader or screen reader user for the wrapper

<jamesn> JD: could Narrator adapt?

<jamesn> MK: has already adapted.... hypothetical if changed something would it be more work

<scribe> scribe: joanie

Matt: Is the screen reader the problem? Is UIA the problem? Isn't UIA giving it everything?

Melanie: It is, but it's a different structure.
... The problem is we have a declarative approach to semantics.
... If you put the role on it, UIA puts in everything that goes along with it.
... If you create imaginary nodes in the accessibility tree, where do you put the properties?

Matt: Wherever UIA expects them to be.

Melanie: It seems like a weird thing to ask a browser to do.

Amelia: Are there cases where anonymous nodes get added?

Melanie: I don't know for sure, but I don't think there are.
... I think we transparently map whatever the author has given us.

Matt: What are potential paths forward?
... The main problem we have right now is a lot of existing comboboxes don't work very well.
... And they're still based on the 1.0 pattern.

Jemma: One thing to help me understand the issue is there's a menu button. I thought it was an easy concept to use for combobox.
... Why isn't it similar for combobox?

Melanie: I wonder if we could get more screen reader developer input on the proposal and also the 1.1 version.

Matt: And what about the naming problem?

Amelia: The 1.1 version really needs a second role, an input inside the combobox. But to also have the legacy behavior....

Matt: Maybe if we had two different roles for the different variations of comboboxes.

JN: Don't do that please.

Amelia: In your new structure without a wrapper, how do you describe widgets that thave an explicit show the list button?

Matt: That's really simple: Those are not part of the widget.
... We actually encourage hiding it from screen readers.

Jemma: What is the resolution?

JD: (Joking) Deprecate combobox!

Matt: Actually, we could do that. An input with aria-autocomplete. (Some explanations.)

JN: And maybe fix HTML select styling.

Matt: If we could get all the screen reader developers in a room.... This could probably be resolved.
... We cannot require aria-controls on combobox. So it has to be on the textbox.

JN: Why not?

Amelia: That gets back to conditional attributes.

Matt: We could put aria-controls on a textbox if it's in a combobox.

JN: We could change the definition of aria-controls....

<BGaraventa> What happens right now in UIA when aria-controls is on a textbox that includes role=combobox?

Matt: I would prefer doing it conditionally.

- DRAFT -

ARIA F2F TPAC - Day 1

16 Sep 2019

Attendees

Contents