Accessible Rich Internet Applications Working Group Teleconference -- 26 Oct 2018

<jaeunku_jemma> Jaeun Ku(Jemma) at University of Illinois

<jaeunku_jemma> scribe: Jemma

Annotations

<jaeunku_jemma> aaaron:

<jaeunku_jemma> aaron: annotation became important aspect for google doc. we would like to describe doc semantically and annotation will be useful - ie. comments

<jaeunku_jemma> aaron: mealny at microsoft suggested to come up with use cases.

<jaeunku_jemma> aaron: high level question - ARIA role vs annotation vs styling

<jaeunku_jemma> aaron:To me, annotation is in-page link to add info - relationship to main content

<jaeunku_jemma> mattking:how comment will look like?

<jaeunku_jemma> aaron: it is like comment in ms doc

<bigbluehat> https://www.w3.org/TR/dpub-annotation-uc/

<bigbluehat> the model https://www.w3.org/TR/annotation-model/

<jaeunku_jemma> bigbluehat: Digital publishing did most of work in regard to online publishing but missing thing is the ties into dom and accessiblity tree.

<david-macdonald> http://spec-ops.github.io/html-note/index.html

<joanie> https://lists.w3.org/Archives/Public/public-aria/2018Oct/0016.html

<jaeunku_jemma> aaron: [he is reading] different types of use cases.

<david-macdonald> http://spec-ops.github.io/html-note/index.html

<jaeunku_jemma> melanierichards: we have a functionality to show another author popped up.

<jaeunku_jemma> is this about insertion point or ?

<jaeunku_jemma> stefan/mattking: description for the change (suggestion, proposal..) will be covered by annotation?

<joanie> https://lists.w3.org/Archives/Public/public-aria/2018Oct/0016.html

<jaeunku_jemma> aaron: https://lists.w3.org/Archives/Public/public-aria/2018Oct/0016.html

<jaeunku_jemma> aaron: would like to suggest to remove "annotation-type"

<jaeunku_jemma> mking: I was thinking that AT can have numerate version info

<jaeunku_jemma> including braile.

<jaeunku_jemma> that kind of functionality would not be possible.

<jaeunku_jemma> aaron: we can add token for each change.

<bigbluehat> https://www.w3.org/TR/annotation-model/#motivation-and-purpose

<jaeunku_jemma> joanie: that is a good point. we can hash out later

<jaeunku_jemma> young: we did not do annotation model/type intentionally in digital publishing group.

<jaeunku_jemma> young: current work from digital publishing group would help this proposal a lot.

<jaeunku_jemma> aaron:breakpoint tends to be associated text and it can be multiple although it looks like one. based on screen reader use case, it can be treated as annotation

<jaeunku_jemma> melanierichards:Regading ui platform, it currently provides rich experience..text arrangement has meta data(ex: attribute type id)..main point is

<jaeunku_jemma> self referencing annotation vs comments markup with different property has different model

<Zakim> joanie, you wanted to ask for UIA API docs so other APIs could potentially model their to-be-added solution on UIA's

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

<melanierichards> https://docs.microsoft.com/en-us/windows/desktop/winauto/uiauto-annotation-type-identifiers

<jaeunku_jemma> bigbluehat: explained how web annotation model works - it marks annotation(ie. span, div) and put in one place(ie. json file)

<bigbluehat> http://annotator.apache.org/ is the implementation of Web Annotation mentioned earlier

<jaeunku_jemma> aaron: discussion of "italisized text" case with web annotation model detail

<jaeunku_jemma> mattking: target of annotation sometimes need what semantic that is, such as comment so target of annotation may not be enough

<bigbluehat> https://www.w3.org/TR/annotation-model/#h-introduction -- this model might be helpful

<jaeunku_jemma> mattking: is the annotation the same concept when Ben said and Aron said?

<jaeunku_jemma> melanie: annotated text is annotation to me

<jaeunku_jemma> annotation itself has meta data

<jaeunku_jemma> mattking: it would be good to involve AT developers to mark up

<jaeunku_jemma> +1

<jaeunku_jemma> david-macdonald: what is the current status of web annotation model?

<jaeunku_jemma> bigbluehat: it was first used for the cultural heritage image such as the Monaisa painting to explaining the small part of the image..so on.

<jaeunku_jemma> we were explored aria role, rdf, html dom, but it was not part of charter scope. there is another group(T..?) who work on annotation ux.

<joanie> ack

<jaeunku_jemma> bigbluehat:accessible annotation working group will be nice.

<Zakim> joanie, you wanted to say this is clearly going to need lots of input from and guidance written by the APG TF

<jaeunku_jemma> joanie: There may be the possibility to work under APA incubator group.

<jaeunku_jemma> regarding "accessible annotation working group "

<jaeunku_jemma> stevelee: you may want to work with Personalization workgroup about this accessible annotation topic.

<MichaelC> scribe: MichaelC

Annotations continued

al: some annotations could be verbose, e.g., comment threads

would be nice to provide a summary to AT

maybe annotation could use aria-label

optionally

mck: might want that summary visible on screen, so use aria-describedby

<jaeunku_jemma> +1 for using aria-describedby

jn: we could document authoring patterns, either way could be valid

by: if I´m an AT user and know there is annotation I might want to go to

how much should the markup tell me about what I should go look at

e.g., if there are 1000 comments, how do I decide how many to read, find my way back, etc.

I want to figure out state transitions and signalling between the content and the ¨annotation sidebar¨

al: we can do stuff in either place, want to do what makes sense for the author

by: I want to know I´m in the main text or in secondary text

how do I know that

some annotation could seem just the same as the main text

jn: in some cases the annotation is as important as the base text

so need to know about them and be able to follow them

by: annotated alice is an example, you only buy books for the annotations

jn: we can address much of this with authoring practices one there are draft implementations

al: so we can explore existing markup solutions to this

<bigbluehat> "The Annotated" collection mentioned from WW Norton & Co http://books.wwnorton.com/books/book-template.aspx?ser=The+Annotated+Books

sl: don´t get too caught up in user experience

this is a verbosity use case, different users want different settings

what we make available to users allow them to set

<Zakim> MichaelC, you wanted to ask about a region role

mc: do we need an ¨annotation¨ region role?

by: think so

jn: possibly

can explore that

jf: annotations also can address cognitive and learning disability use cases

would like to avoid an overly narrow solution

not just AT exposure

also think in addition to verbosity, there is importance that should be able to attach

by: makes sense

knowing provenance of an annotation helps determine that

e.g., boss vs stranger

jf: comments can bubble to top

by: that´s a machine choice, not necessarily mine

al: maybe a summary rather than semantic weight helps better

dmd: +1 to new role for annotation

sl: -1 to role for annotation

content of annotation can be in many forms

there could be regions, asides, footnotes, etc.

so role could confuse unless we have compound roles

there should be association between annotation and content

which means there is a way to determine that you are in something that is an annotation of something else and you can jump back and forth

at the moment this seems to fill the use case, unless we discover others

mck: +1 to authoring practices

what are hopes for timeline and next steps?

I´m hearing both grand proposals and tactical proposals, unsure what we should do next

al: make things as difficult as possible of course :)

jd: think we can do much in existing ARIA; can explore other things as well

al: would like to explore the existing ARIA in detail to meet the use cases

explore a couple potential new things if needed

mck: any new features, is that ARIA 1.2 or later?

jn: For a single property, we could probably put in 1.2

good to file an issue about that so we can start exploring

jd: can go into editors´ draft sooner

if the full workflow doesn´t complete in time for 1.2 spec, still in editors´ draft for maturation

al: think we´re close

I want to explore if we want multiple annotation types

mck: what´s case against that?

al: path of least resistance, UIA supports single type

mp: different properties support different values

at the moment could have different types of anntations, but not multiple type on the same annotation

we could explore changing that

keeping in mind it makes it more complex, so consider consequence

could use ARIAproperties instead

by: Apache annotator is an example of the approach we´re exporing

it´s JS on DOM at moment

Open Annotation CG is a shadow group

inactive but can be used to ping people who´ve been working on it

re author understanding, want to define when it´s necessary for things to happen in UX

<Zakim> joanie, you wanted to ask if we could have prioritized token list

jd: we need to discuss use cases before deciding on multiple types

if we go that direction, there could be a prioritized token list

which allows to simplify some of it

al: seems to make sense

jf: use case is broader than AT

so architecting more broadly will be helpful

by: +1

would like to anticipate features rather than discover missing later

we have a list of annotation types, just need people to suggest what should be in it

but also suggest instead of typing annotations, use purpose and motivations

not all the use cases haven´t been elaborated yet

<bigbluehat> +1 to making this real with proposals

al: I will circulate a proposal

<bigbluehat> purpose and motivations are described here https://www.w3.org/TR/annotation-model/#motivation-and-purpose

<melanierichards> https://github.com/w3c/aria/issues/749

RESOLUTION: Aaron will add annotations proposal to w3c/aria github issue 749

<jaeunku_jemma> https://github.com/w3c/aria/issues/749

Stefan

ss: aria-rowtype, we discussed

jn: we need your help to address in the APG

<joanie> Documents for this topic can be found here: https://lists.w3.org/Archives/Public/public-aria/2018Oct/0015.html

ss: on columnheader

in ARIA 1.0 grids every columnheader is potentially active

in 1.1 it´s a bit different but still true they can be focused and contain actions

mck: yes, @@

ss: gap re headers

mck: if one columnheader has actions, every cell in the row should be focusable

<jaeunku_jemma> https://www.w3.org/TR/wai-aria-practices/examples/grid/dataGrids.html

APG has example with 2 sortable columnheadders but the rest focuable

<jamesn> discussing https://lists.w3.org/Archives/Public/public-aria/2018Oct/att-0015/Properties.docx - section Columnheader: active, aria-fixed=”true/false” and aria-filtered=”(string)”

haven´t gotten quite to that level of detail though, it´s in the example

save that for the ARIA Textbook

ss: need properties to indicate column is fixed and won´t scroll

given there can be autoscroll during keyboard navigation

mck: rowindex could do that

ss: column

mck: there is an example in APG as well

both rowindex and colindex communicate that

ss: how?

not clear from verbosity

also, we have aria-sort but not a filter

if a cell has a sort it acts as a column header though it isn´t one

not sure of impementation

jn: we can explore that

ss: columns allow filtering by arbitrary string, common in business applications

<jaeunku_jemma> https://www.w3.org/TR/wai-aria-practices/examples/grid/dataGrids.html

mck: filtering and sorting should be a joint issue

jn: does seem there are missing things

but should work out what´s missing, and what should be addressed with author guidance

don´t want to add properties to spec until exploring practices for existing feature

for filter, I´ve always put them on descriptons of the table itself

hard to find when down in a column

ss: I´m looking at dynamic filter

jn: sometimes you get a pre-filtered view

discoverability has been a challenge

mck: AT should handle the discoverability

sn: yes, but in practice hasn´t been

<Zakim> joanie, you wanted to reiterate the need to also sort out what ATs should do in response

jd: ^

mck: sounds related to my aria-at project

dmd: have tested the aria labeling properties in AT, varying results

jn: there is a proposal to disallow author labeling of a region

mck: been wanting that also

jd: e.g., div

mck: things with presentation role

ss: example shows nested column headers

can I apply aria-level?

mck: AT should support colspan

ss: that comes out of HTML

but is it sufficient?

mck: unsure, but seems to work afaik

Charter

<MichielBijl> scribe: MichielBijl

joanie: recently revised charter template now has a fill in the blank format

What are the other charters doing?

We needed at least a 75% completed implementation for each platform

We also need that for at least one AT.

I thought that was a pretty high bar to get over

And it proved to be just that

scribe:

Lots of discussions

<joanie> https://rawgit.com/w3c/aria/charter/charter/index.html#success-criteria

What I’m going to do now is post a link:

<joanie> For the ARIA specifications, implementability and interoperability of every feature will be demonstrated by having at least two independent browser implementations of that feature. In addition, for the Accessibility API Mapping specification(s), each ARIA feature will be shown to have at least one implementation in each of: ATK/AT-SPI2, MSAA+IAccessible2, AXAPI, and UIAutomation.

Proposed solutions to SC issues

Worked with W3C and individual member organisations

<Zakim> Judy, you wanted to also clarify my role in the charter discussion

Judy: in terms of introduction

I was also directly involved with trying to solve some of the issues

Joanie: we appreciate your help

*joanie reads paragraph she just pasted*

This kind of holds us to an even higher bar

Now we have to have every single feature implemented

A 100%

The good news is that we don’t have 100% in a single UA.

We could have 75% in WebKit, 75% in Gecko, and 75% in Blink, but those might overlap and cause 100% implementation.

Same for AT.

mck: Something that strikes me about this high bar

On Windows there are two accessibility APIs

It strikes me as odd to have both of those to have to implement every single feature.

Joanie: it’s not a too high bar

It’s not implementabilty in Windows

It’s implementability in general

In the end the AAM is bascially gonna be “here’s aria-foo, how are you gonna implement it in *insert accessibility API*

RA: *asked a question I didn’t catch*

<joanie> platforms are included. If needed, an Accessibility API Mapping specification will be split into platform-specific specifications, e.g. one for ATK/AT-SPI2, one for MSAA+IAccessible2, one for AXAPI, and one for UIAutomation. This will allow each platform's specification to progress along the Rec track at the timeline that best suits them. For specifications which are not split apart in this fashion, no

<joanie> platform will be dropped out of the specification without prior consultation with that platform's owners.

<joanie> Every effort will be made to take member organizations' schedules into account and to ensure all platforms are included. If needed, an Accessibility API Mapping specification will be split into platform-specific specifications, e.g. one for ATK/AT-SPI2, one for MSAA+IAccessible2, one for AXAPI, and one for UIAutomation. This will allow each platform's specification to progress along the Rec track at the

<joanie> timeline that best suits them. For specifications which are not split apart in this fashion, no platform will be dropped out of the specification without prior consultation with that platform's owners.

joanie: what this says is “I can’t get the API to support aria-foo”

because it has a different release cycle or such

This won’t block ARIA

We can currently test platform agnostic ARIA implementations

And that means that if gnome release cycles screw everything up

it won’t block ARIA releases

RA: If this is the current charter

Would we pass today?

Joanie: we would be close, and otherwise I could get us there

The two ways to address this

Let everything progress on a separate time line

On the one hand we want complete implementations

We are doing this for end users

If we don’t have 100% across the board that impacts end users

All platforms and UA vendors say they’ll implement the spec

Perhaps not today, but we’ll get to it

For pure implementability, if someone says aria-foo isn’t implementable, I can submit a patch to proof it is

RA: Assuming you’re speaking of a usacase

in which UA already has support for a given feature

and, in the cases where there’s missing platform support

I will point you back to 20-30 minutes about annotations

about missing UA support

this current charter would then that UA needs support on the platform

that’s not something that we can require or mandate

joanie: we could split it out (we split AAM into four specs)

It’s not that hard

If there was just this one feature (aria-annotation)

If every last feature was implemented aside from one

Can we scrap just that one feature

plh: do you mean we remove it from the spec?

jamesn: it would just not be mapped

we have stuff in some of them that isn’t mapped on some platforms

mck: my question is directly related

high level question first

so you have the ARIA spec, say ARIA 1.1, and if it has dependencies on four other specs

normative dependencies

Can ARIA 1.1 become a REC if one of those other specs is like earlier in the process?

How do these normative dependencies work across specs?

You could remove something from the dependencies

But the first bullet says “each feature”

But it wouldn’t be each feature because you removed something

plh: first we do not have that today

ARIA does not depend on mappings

It’s the other way around

<joanie> Mea culpa

It’s what we call the nature of the dep

In the case of ATK, you must implement the mappings over there

If in the ARIA spec you say this specific role must be implemented as described in the mapping doc

We must make sure that it’s done that way

It’s about how specific you want to make that normative dep

mck: I’m glad there isn’t

plh: In terms of the ??

???

We’ll give them a week to respond

Your AC rep can still reply

Judy: I think that Matt’s question is good

I appreciate your assurance Phillipe

I was lookiung for the exact language

And would like to just make sure that it’s crystal clear and doesn’t leave any ambiguity, since specs have gotten blocked for unexpected interpretations of dependencies before

plh: There’re no a normtive depencies

mck: in the past I thought they were dependencies because you need those docs to implement it

If it can progress through the REC track that’s really cool with me

I’m glad to hear that

I had this impression in the past that that created the dependencies

plh: I don’t think a charter should say which spec depends on another

mck: I wasn’t sure if the current wording of the spec created this dependency

???

mck: that makes it pretty clear that’s how you expose it

joanie: the testing dependencies is where I got confused

I think this is doable

Going back to the aria-foo and aria-bar, if we pull that one aria-attribute out of your ATK, are you guys okay with that?

RA: I’m gonna use Philippe’s opportunity

I’ll get back to you

Judy: We’vge been having a fair amount of email discussions

About this meeting

We thought we had that before this meeting

Grey area, that additional week

With the extention

Have to sent this out to addition commenters

plh: if something comes up

Give them a week to say “Are you good with this or not?”

Not gonna send that in a week, gonna send that today.

We’ll go on a case by case basis at this point

Joanie: It’s not what end users need

But removing the frontrow ???

If we don’t want any failures

Yes, we prefer to have all the implementations

RA: There could be additional implementations

Then we’re on the receiving end in a completely different way

jamesn: the difference is that the spec couldn’t advance

joanie: you could have all this awesome additional stuff that’s only in your platform

But if the things from the spec aren’t implemented

I’m not sure how you’re on the receiving end

jamesn: if it’s one other it would be fine

If one of the mappings sits in CR for a bit is that okay?

three months past? six months past? I think that’s okay

joanie: as chair, and implementer, I can’t look at other stuff.

jamesn: the whole point of splitting them up is that they don’t have to progress at the same time

plh: If after six months a new implementation comes along that’s a lot better

That’s fine'

jamesn: essentially you’re providing us with the mappings that we4 put in the document

joanie: it could be that initially

The other thing: I’m very pro to updating the AAM

I think the AAM should be current

Not be out of date because we updated our API

MichaelC: I’m already thinking of ways to automate AAM production

Judy: Philippe knows how to do it

joanie: so you need that week to mull it over?

RA: Yes

joanie: if the AC reps are OK with are we okay with it?

If people have doubts I’d like to hear them,

RESOLUTION: Accept draft charter in 2018-10-26 form, send CfC to confirm during AC final check

<Jon_Gunderson> For rhe APG discussions in the afternoon will WebEx be available?

CSS AAM

IanPouncey: CSS accessibility API mappings

As far as we got so far is that MC created a repo

That’s pretty much the last time something happened on it

I’ll drop a link to it

<IanPouncey> https://w3c.github.io/css-aam/

I’m not a 100% clear on what a CSS AAm would look like

but some things sound obvious

Like core AAM contains things on hiding content

joanie: that’s now in ARIA

IanPouncey: there are other things that are likely candidates for CSS AAM

Ordering content with various layout

Like flexbox/gridlayout

It’s worth specifying whether DOM order or layout order should take precedence in the a11y tree

There’re bound to be others

But an awful lot of CSS doesn’t have accessibility issues

This is a question I really don’t know the answer to: there’re plenty of things that don’t influence the a11y tree that perhaps should

Something like typographical styles

joanie: it’s exposed no?

melanierichards: the exposure isn’t exposed

IanPouncey: I would like to hear from joanie in particular her thoughts on this

We don’t yet have an editor yet

joanie: I can help be an editor

mck: I have some thoughts that need to be in there

There’re are some things that need to be specified someplace

We had a discussion in Toronto

With ???

Right now in the generic role one fo the things we’re talking about is the default styling like block and inline

A lot of people have pointed out that a lot of browsers will guess how a text node should be rendered

They’re different between browsers like Safari and Firefox

That’s one area of exploration

Is the way that visual spacing and placement affects the accessibility tree

joanie: I want to make sure we have the same interpretation of accessibility tree

IanPouncey: we’re talking about how things are exposed

Order as much as anything

joanie: the strong attribute is not

mck: essentially the thing what we use in the ARIA spec

Like a node in the tree

I was talking about whether two words are part of the same node

Is it one text node or two nodes

joanie: does it have two spans or divs or something?

mck: like <span>hello</span><span>world</span>

In VoiceOver these will be two nodes

In JAWS they’re announced as one

Not sure if it’s represented differently in the tree

IanPouncey: we’ve 12 minutes, so maybe we can focus on next steps

joanie: I can be an editor

just to make sure we’re on the same page

different people tell me what accessibility is that are not in this WG

given these HTML elements how are these exposed

for ARIA is the same things

How are those exposed on a platform?

Right now you mention text elements

If something is bold

Gecko will give it as “weight 600”

And webkit maybe gives us “bold”

No matter what the UA is, I get the exact same attributes

One thing you could map

is get a table

if there’s a CSS style bold

Something like ATK should expose that as bold

aaronlev: I linked to the table

joanie: they’re descriptive and they should be prescriptive

What I’d probably do is start with the table aaronlev linked to and do a sanity check

Find out what each browser is exposing

And if it’s the same thing and call up the AT vendors

Is this right or are you hacking around it?

Given this CSS, this is the canonical way it’s exposed

If that’s not what a UA is doing then we can file a bug

That would be a concrete way to start

IanPouncey: yeah that’s pretty good

Starting point is put together a list of things that are relevant to this

Font and styles, layout

joanie: if we want SRs to expose grid layouts as a grid

We might want to expose positional information

Maybe it’s just an ?? attribute

What do screen readers need to do?

But we can discuss that with AT/UA vendors

IanPouncey: the CSS AAM right now is a reference to other AAMs right now

joanie: SVG AAM is kinda doing now what HTML AAM is doing

Yeah you have this dependency chain

But I can use SVG without ARIA

Another thing would be a simple statement

I’m of the opinion that table shouldn’t be exposed

I have all this code in Orca that decides wether something is a table

IanPouncey: table heuristics have been around for a long time

I know there’s documentation but wether it’s canonical documentation I don’t know

aaronlev: we expose it as a table

We’ve been asked to

The screen reader can use our guess

joanie: WebKit now bases it spacing

aaronlev: We used to do that

joanie: if CSS layout table should work that way

???

aaronlev: yeah I’d like it to work that way but there may be different opinions

mck: ?? chops engineers off at the knees

joanie: Engineers of web apps?

mck: ???

to the extent we can remove ambiguity

<Zakim> aaronlev, you wanted to say here is our IA2 and ATK expose text attributes: https://wiki.linuxfoundation.org/accessibility/iaccessible2/textattributes

aaronlev: remind to remind me to look at this for AT2

We don’t expose every CSS attribute for font style

mck: so it’s color 0 = 0?

aaronlev: it’s up to the AT to understand that

When the AAT doesn’t see the value, it should assume it’s the value in the column

Over the years we’ve talked to the AT and they agreed

IanPouncey: should we write an AAM for this?

*laughter*

joanie: if we have to figure out what all the different platforms are gonna do…

aaronlev: yes that’s what we agreed upon

joanie: but that doesn’t mean expose everything

in terms of AAM language, HTML AAM will say something like ???

IanPouncey: CSS is developed by module

That provides a logical grouping to tackle this one thing at a time

joanie: an authoring practices, be it ARIA APG or a CSS APG

IanPouncey: As I said this at the start

What we need is

I’ll talk to Rossen

Who is a co-facilitator for the CSS WG.

joanie: you can sign me up as not full time editor

MichielBijl: you can sign me up as copy-editor type situation

APG

<melanierichards> scribe: melanierichards

Discuss patterns needed, how to get help creating them and direction of APG

matt: we're approaching almost a year since our first formal release of APG for ARIA Authoring Practices 1.1, covers a small but vital portion of ARIA. The vast majority of ARIA widget roles. Goal is to have all widgets covered by release 3 in this December, possible exception focusable [missed]
... we have 37/46 properties being used throughout current ARIA examples. this is all covered by main section, the design patterns. The big gap is it's one thing to show people how things are used and prescribed how to used in pattern, but that doesn't teach them how to use outside the context of the pattern and use it generally
... we don't necessarily teach web devs how name from contents or author works
... upcoming plans around aria-label, aria-labelledby, etc
... the only role that has a section is role presentation, don't have guidance on the other approx 86
... we've been doing a relase every 6 months. Going to do one in December, June. End of next year we'll publish APG 1.2, which goes with ARIA 1.2
... for a long time, our roadmap has been we will have all of 1.1 covered at that time
... at our current velocity, that looks unattainable unless we get a whole lot of help
... I have a plan to get decent help (for ex contract work, that's what we did to get regression testing into examples)
... have some budget to generate content, but not sure if that'll close the gap on its own
... we have another big project in our plan which the entire industry has been clamoring for, a sort of "can i use" for ARIA. we will structure based on pattern, roles in isolation doesn't make sense
... if all the patterns cover all the roles, you essentially have a Can I Use
... we will test specific browser + AT combinations and assess how well they support that specific pattern
... this project I refer to by its repository name, aria-at

https://github.com/w3c/aria-at

matt: goal is not just to define the patterns but how well they support it
... we don't have normative reqs on AT, so defining and negotiating the methodology is probably one of the hardest parts of the project
... from a practical standpoint this is what we all need

aaron: how often do you plan to retest stuff?

matt: once we have a methodology in place and have proof-tested it across 10-12 patterns in all the browser + AT combos, we'll build into this a way of providing feedback loops within the infrastructure itself. so we can update as updates some from screen reader updates
... part of this depends on how difficult it is to do the assessments

<Zakim> yatil, you wanted to say MDN is trying to do some similar things like aria-at, might be a way to cooperate. Also there’s the accessibility support database infrastructure from a

<jemma> https://twitter.com/a11ylondon?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor

yatil: I've been at the MDN accessibility hackathon in London and they tried to do something similar, might be a way to cooperate. There's an accessibility support database in the W3C a few years ago, very dormant because people don't know about it. Can either use that or its learnings

matt: going to reach out to Shadi [spelling?] about that tool
... the one thing I'm not sure about when it comes to there being an authoritative reference for guidance when it comes to roles, states, and properties...I know that MDN is well regarded but it's not W3C.

<Zakim> jamesn, you wanted to ask whether the discussion about which combos we will look at has been had yet

jamesn: I don't recall us having a discussion about browser + AT combinations, we should understand that

CurtBellew: would be handy to know what's not supported now

<jemma> lauriat

Lauriat: it's been awhile since we've caught up on this, I want to reiterate the support I have for this. As you and I have chatted, in Google, my team has done parallel effort on this. Implementing ARIA widgets and see what works or doesn't. Want to see what we can contribute for alternate ways of doing things or pointing out gaps
... have done testing as well, have started with most common browser + AT combos, ones that have claimed to have done well
... I have work to do to figure out how to contribute
... want to track updates so that we can link them to known bugs
... from those bugs we can also cross-reference back to aria-at
... need to have a full regression test once in awhile and don't have a good answer for that

jamesn: are your examples public?

Lauriat: I am working on making them public. We started in January and "finished" in April. On an internal public repo but there's nothing inherently private. Before I take a repo and make it public I have to go through lawyers
... I can file bugs on Github

aaron: some ATs and browsers update automatically and others don't, something to think about for strategy

matt: this would have latest, current status vs. different browser and AT versions (history)
... we're also not going to be testing each release of browsers and ATs
... will be a record of which one was tested
... you would have historical results perhaps for a specific pattern, but when you look at the table of current statuses, you might be able to open something in Github and find out the history

jamesn: always useful to have that history

IanPouncey: can always track the point at which it starts working, supposing it never breaks

[general laughter]

aaron: people most often ask about JAWS a couple versions back

jamesn: we're not going to go back and do historical work

matt: if someone wants to do that, that can be their own thing
... idea is to get industry up to a point where if you're using recent browser and screen reader, you're going to get a robust experience. Not the state of things today but we would like it to be
... not sure if 2 year, 3 year goal
... can go way beyond that. can include mobile browsers (not included in initial scope)
... might have to add AOM and other things that pop up over the years

MichielBijl: object to not including mobile VoiceOver in initial scope

matt: I mean the very first go-around here, concept testing in a very small number of browser and screen reader combinations to test if it's feasible

MichielBijl: would really like to include touch screens in that because we've been terrible about supporting

matt: we can include touch screens on a couple patterns
... ...it is possible to make a slider that works on mobile but AT has to see plus and minus buttons
... point of APG is to show how we intend ARIA to work, and not to provide polyfils

<Zakim> jamesn, you wanted to say is it not useful to report that

MichielBijl: we could always say "this pattern doesn't work with touch" to have that data point

matt: we've tested certain patterns with mobile, like dialog and menu button. have a couple bugs open. we do have a giant gap here. If anyone wants to join the task force to focus on mobile, please let us know!

aaronlev: I think we need to do something about mobile. It takes so much longer to update the experience for mobile users so the sooner we have data the better
... can be up to a year and half from the fix to getting to the user (due to OS updates)

matt: we need people. Our current group is already stretched to its limit

<jemma> we have abstract info about "Browser and Assistive Technology Support" in each APG example. https://www.w3.org/TR/wai-aria-practices/examples/grid/dataGrids.html

jamesn: we also have our new workflow where we require a pattern in APG for each new feature, and we still have the same number of people in APG, so backlog is growing

matt: if any companies are willing to invest in this and oversee contract, contract work went really really well for us, got a lot done
... if I could double my budget, that would be great. I'm happy to provide project management aspect
... that's going to be a method I'll use more and more to max our output

Lauriat: happy to help sponsor mobile testing
... most of the work we do is to support apps, we have fewer mobile apps. didn't bother testing our ARIA implementations in mobile because we knew everything would be broken
... though we wanted to test mobile

<jemma> +q

jemma: potential place for that information...browser can add support info in each example

jamesn: [struggles getting people to commit to get involved in contributing]
... how can we make that better?

Lauriat: part of it might be the format. the page inherently includes a whole lot of stuff: documentation, multiple examples on a page, etc. Maybe if the example opens its own new tab, clean namespace with docs around it, that makes it easier

<yatil> [Notes that we are working on our examples in EO, too.]

melanierichards: is there a human element where people don't feel that they are entitled to contribute? (imposter syndrome)

matt: there a some better starter points for new contributors (mobile testing, bugs, etc), developing a new pattern from scratch is not the best place for a new person to start

jamesn: [mentioned before matt that the first review can be rough, a lot of people jumping in to review]

IanPouncey: maybe that first review doesn't happen, it's a pair review / mentorship [paraphrasing]

jamesn: could consider for new people

<jemma> +q

matt: we want to create some UIs we know people can actually use, at this point we know it's spotty

Lauriat: first part is getting map of support, second part is filling it out

david-macdonald: contributions are just pull requests?

jamesn: we have branches with stuff that haven't been merged

david-macdonald: so file an issue and say you'd like to work on it?

jamesn: yes and someone can tell you go ahead or we already have something

MichielBijl: some kind of docs about directing new folks to the right place for help in contributing

matt: we have something like this
... for a little while, was putting a lot of effort into startup documentation. Ian contributed style guide. Docs on getting linter set up, all that
... whatever you can do to help us improve that, would be great

IanPouncey: we should have not just "here's what you need to do" but also "here's what APG will do for you if you contribute"
... happy to look this over

yatil: good idea would be marking issues as "good first issues"

matt: we have a link to "first good issue" query on the docs
... I have a hard time figuring out what might be a good first issue
... sometimes it seems straightforward to me and then when I'm reviewing the PR, it seems harder than it looks. Sometimes it's apparent.

yatil: APG is a document in the TR space and it looks like one, and I'm scared of TR space

jamesn: talk about moving out of TR space, only problem is versioning
... don't want to put stuff in there that's not well supported

MichaelC: we can do versioning wherever we want. open to the discussion of moving things

matt: with a lot of the ideas, it's a question of where it sits in the priority list. even something simple takes up time. I'm just trying to get version 3 out the door for December, so January is best time to have the convo

jamesn: can EO help?

yatil: happy to help how we can, we have a lot of stuff on our plate, but if we can have a shared doc, great

matt: this has been really helpful

jemma: any plan on how to create shared doc?

matt: we're just planning a meeting to get in touch in January (myself and Eric will coordinate)

yatil: want to align so we don't have separate examples

missing gaps in APG

Stefan: we need a reference signaling pattern for unobstrusive notifications needed
... we need some more patterns to signal to the user, so much data fetching that has nothing to do with DOM building. Yes, could re-use live regions or this and that, but there's no patterns on how to signal business loading logic
... single control data loading, busy state is busy fetching data, need examples for how to achieve this. aria-busy intended for another purpose
... announcing results of search performed, "x results found" etc. No established pattern to indicate this
... when you try to experiment with different browser and screen readers combos with live regions, you don't always get expected result
... need some patterns about "the UI has done/is doing something" and "the UI is about to do something"
... any data-containing field needs to show it's busy fetching data
... readonly or disabled not enough because you don't know reason why

jamesn: these all seem like instances where the only way to do them is live regions. Wrong or right about that?

matt: we did make some mods to aria-busy when we added feed role in ARIA 1.1
... one of those situations where the ATs haven't done anything with it. If you just read the ARIA spec is not obvious what you're supposed to do
... I think this is one of these places where the practices task force really does need to step in a nd come up with examples of how we think the problem would be solved, and then suggest some reasonable expectations on the part of assistive technologies
... would love some good use cases there, Stefan, thank you

jamesn: often when I use live regions, I'm using it as a hack to throw messages to the user
... what do people think about some kind of aria notification mechanism to send messages to user

joanie: +1

matt: dispatch mechanism?

jamesn: yes

matt: you could potentially do it in javascript instead of having to have it in the DOM

Lauriat: in my previous experience of using the crap out of live regions in G docs, we learned a lot. Chrome Vox when it was an extension had a speech API that we could just hit
... there are downsides. Such as the richness in formatting, since you're getting a literal string that potentially has some emphasis that gets lost
... loses intonation for emphasized words
... you get a lot from HTML

matt: this is where speech markup would be really awesome
... it would be good if this ARIA notification thing could support pronunciation

jamesn: would like Lauriat's expertise

Lauriat: sure thing

jamesn: will need sufficient warnings not to abuse this

Lauriat: doesn't solve the brittleness problem. anything else that's happening can stomp on speech. interruptions

Stefan: agree interruptions are a problem

aaronlev: booleans, "isInterruptable" etc

matt: screen reader support for live regions and this new thing...in both cases there's a lot screen readers coul do to make the end user experience a lot better. confounds me that SRs can't give history of latest live region utterances

JF: there is a task force that has been stood up to re-address SSML in education for pronunciation. Mark Hakkinen leading that. Caution this group not to re-boil the ocean, coordinate with this group

jamesn: resolve to open an issue to look at this idea of ARIA notifications for messaging to the user?
... Stefan, can you log it

Stefan: yes

<jemma> +1

aaronlev: I've seen this issue with G docs, a lot things coming in and a lot of talking
... maybe companies w/ use case need to ask SRs to implement something

<jamesn> logged https://github.com/w3c/aria/issues/832 for notifications issue

Stefan: we should have some sort of expectations documented

aaronlev: so we should include guidelines for how SRs should deal with the aria-busy state

matt: screen readers need us to come with very specific examples

joanie: can be brittle when the UA or the web dev sets something as busy but never unsets it

matt: some sighted people can read half the page when the other half is loading, and it frustrates me not to be able to do that

Stefan: complete list of valid role="application" + aria-roledescription use cases needed
... guidance says to reference the original role of the element in the aria-roledescription before the more specific role

joanie: very long, takes up a lot of space in braille display

aaronlev: role attribute is semantic role, the other is a localized string

stefan: if both are spoken it's fine

[a couple people disagreed]

aaronlev: I think the way it works right now is good, space delimited name in the roledescription

(summarizing, Stefan had wanted both the role and aria-roledescription to be presented to the user by AT)

jamesn: aria-roledescription is poorly supported, what should do we do in the meantime?

james: we should file bugs against ATs

Stefan: recommended method how to indicate custom control props using existing ARIA 1.1 needed
... is that possible to get in APG?

matt: if we had an open issue for something like the "filtered" example that would be good...I can't say until we start working on it how I would communicate filtered state

Stefan: in discussion with Rich, he said it was ok to use aria-describedby but can that be recommended by APG?

jamesn: have problems with using aria-describedby for things, not always spoken especially if verbosity turned down. that's why we have aria-errormessage. will have to work around these kinds of things in the future

matt: if you tes something and it works, you don't have to have that exact same technique in APG. The APG is never going to cover every possible UI, though I appreciate you're trying to do things as a standardized best practices

<JF> To get to Best Practice, you first need to start with "Practice"

matt: may need to build own best practices in order to unblock your engineering efforts, great if you contribute to APG when you're confident with it

<jemma> +1

Role parity

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

<CurtBellew> joanie : should we consider not allowing naming certain rules

<CurtBellew> I would argue that we've already had the issue

<CurtBellew> generic divs wiht names for instance

<CurtBellew> with the creation of generic roles

<CurtBellew> we might want to not let those have names as well

<CurtBellew> opened this issue - https://github.com/w3c/aria/issues/833

<CurtBellew> mck : i specifically asked for this for the generic

<CurtBellew> this thing has to be nameless. maintains interoperability for divs and spans

<Jemma> can someone explain what is the scope of "generic name"?

<CurtBellew> Adding this new value would for this to be part of hte accname

<Jemma> definition scope of "generic name"

<CurtBellew> joanie : if everyone can review and thumbs up/down

<CurtBellew> we need a specific list of elements that 'must not be named'

<CurtBellew> melanie : if someone adds a tabindex to a div, should we just say you can't do that

<CurtBellew> james : could be a region or a group?

<CurtBellew> mck : there are situations wher eyou might put a tabinidex on a div, like a dialog that contains a lot of content.

<CurtBellew> melanie : seems like it would be good to get author input

<CurtBellew> maybe we need some semantics if there's a tab stop here

<CurtBellew> jamesn : we do need semantics if there's a tab stop there

<CurtBellew> mck : there could be a situations where a span of text is something that you focus to and then has some other user popup but you don't want the content to be .... there are use cases ... it shouldn't have an accessible name

<CurtBellew> the focus should be on th econtent

<CurtBellew> joanie : generic is going to derive it's name form content?

<CurtBellew> mck: pretty sure it's not going to derive it's name from content. we need to find out if the content of hte text node is the label

<CurtBellew> jamesn : maybe we need to do some queries to find out

<CurtBellew> joanie : i will file the issue and ask Steve Faulkner to do some investigations

<CurtBellew> jamesn : move on to talk about generic role

<CurtBellew> carmacleod : you've been talking about my number one question. what attributes do we allow?

<CurtBellew> has been working on generic role today

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

<CurtBellew> jamesn : role none doesn't happen if you put a global on it

<Jemma> https://carmacleod.github.io/playground/generic-role-tests.html

<CurtBellew> would we ever want any of the globals on the generic

<CurtBellew> mck : we might need to allow arir-invalid for instance

<CurtBellew> mck : the problem wiht putting a label on the generics causes other problems but among them is how does that get added to the tree

<CurtBellew> aaron : isn't it better ot have a label so the user has an idea of what's happening : worst case sceneroi

<CurtBellew> mck : maybe a browser coud do that even though the spec dosen't support that

<CurtBellew> one thing the spec doens't do is force you to do things that aren't support unless it says specifically to 'not'

<CurtBellew> aaron : if there's information there then I'd rather give it to the user and let them decide if it's usefull

<CurtBellew> mck : this might be one of those cases where it might be good that this doesn't work - it's bad code

<CurtBellew> mck : a div with a label - screen reader shouldn't read the label

<CurtBellew> otherwise the author might think it's good authoring

<CurtBellew> macdonald : testing it quickly and it doesn't seem to work on many statics

<CurtBellew> aaron : it's true. it shouldn't. when we get questions we can just say that it shouldn't work so it doesn't

<CurtBellew> jamesn : how do we solve the global attribute issue?

<CurtBellew> where we have things that are allowed but don't make sense

<CurtBellew> should we just say that they aren't allowed

<CurtBellew> currently as it's written if you put a role of none and an aria-label then it's as if the role of none is removed

<david-macdonald> http://davidmacd.com/blog/does-aria-label-override-static-text.html

<Zakim> MichielBijl, you wanted to ask about reversed role parities

<CurtBellew> mck : if something has support that is spotty how can author use it?

<CurtBellew> michiel : do we have any plans to go the other way - making HTML parity with what we can do in ARIA

<CurtBellew> might be good to at least open the discussion

<Jemma> +1 :-)

<CurtBellew> mck : the gap is a big one

<CurtBellew> caroline : the pull request is out of date at this point

<CurtBellew> it's not indicative of the current conversation

<CurtBellew> all the current information is in the issue and not in the pull request

<CurtBellew> mck : I put a bunch of stuff in the pull request

<CurtBellew> jamesn : mck comments opened a bunch of questions

<MichielBijl> To add: I’ll start a discussion with Scott O’Hara.

<CurtBellew> caroline : mck comments will be addressed

<CurtBellew> stay with the issue

<CurtBellew> jamesn : we will most likely not resolve this issue today. this should be a postponed to a future ARIA meeting

<CurtBellew> mck : i would like to walk away form this having answered an open question in the issue or the pr feedback

<CurtBellew> jamesn : nothing really waiting on you.

<CurtBellew> mck : maybe we need to get consensus on issue 833

<joanie> https://github.com/w3c/html-aam/issues/160

<joanie> Consider prohibiting author naming certain elements #160

<CurtBellew> mck : question on 160. how much of this an HTML issue?

<CurtBellew> is this any of this HTML AAM'

<CurtBellew> joanie : issue posted above

<CurtBellew> 'add generic case for name calculation'

<CurtBellew> if there is no aria role and no tabindex then it's not nameable

<david-macdonald> https://github.com/w3c/aria/issues/815

<CurtBellew> mck : both working groups should have input on this

<CurtBellew> joanie : if we expect users and authors to dig through docs to find elements that shouldn't be named

<CurtBellew> we should define that. these two issues don't seem to be duplicates

<CurtBellew> macdonald : is a heading a user interface element?

<CurtBellew> aaron : 'the nameless is the beginning of heaven and earth'

<CurtBellew> caroline : aria text separation

<Jemma> https://github.com/w3c/aria/issues/699

<CurtBellew> we need ways for the leading and trailing to specified separately

<CurtBellew> a token list would be a good way to do that

<CurtBellew> restricting it to two tokens?

<CurtBellew> feels similar to CSS

<CurtBellew> like before or after

<CurtBellew> mck : it's worth writing that way so it might be easier to get feedback

<CurtBellew> jamesn : we need something like this

<CurtBellew> jamesn : anything else anyone would like to discuss?

<CurtBellew> jamesn : next meetup? somewhere on the west coast of the US? next spring?

<CurtBellew> joanie : western canada?

<Jemma> scribe:CurtBellew

- DRAFT -

Accessible Rich Internet Applications Working Group Teleconference

26 Oct 2018

Attendees

Contents