<scribe> scribe: tink

<aboxhall> I threw some notes into http://bit.ly/a11y-tree

<AWK> +AWK

<Rossen> Rossen Atanassov, Microsoft

<aboxhall> Alice Boxhall, Google/Chromium

<rniwa> Ryosuke Niwa

<CurtBellew> Curt Bellew, Oracle

<gpellegrino> Gregorio Pellegrino

<david_clarke> David Clarke - I18n Invited expert - with interest in accessibility

<stevealee> steve (steve lee) w3c

<anne_thyme> Anne Thyme, Siteimprove

<Wilco> Wilco Fiers, Deque

<jofranchetti> jo franchetti from samsung internet

<mrobinson> Martin Robinson

<AWK> Andrew Kirkpatrick, from Adobe. Co-chair of Accessibility Guidelines WG

<mrobinson> (Igalia)

<IanPouncey1> Ian Pouncey, The Paciello Group

Léonie (tink) Watson, The Paciello Group

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

<joanie> Joanie Diggs, Igalia

<RedRoxProjects_> Amy Dickens - Samsung Internet

<marisa> Marisa DeMeglio, DAISY Consortium

<irfan> Irfan Ali from Educational Testing Service.

<TabAtkins> Tab Atkins, Google

<clapierre> Charles LaPierre, Benetech

<tzviya> Tzviya Siegman, Wiley, Publishing WG

<Rachel> Rachel Comerford, Macmillan Learning

<JuanCorona> Juan Corona - Evident Point Software, PWG, Readium

<notabene> Stephane Deschamps (Orange), Education and Outreach WG

<Avneesh> Avneesh Singh DAISY Consortium

Intended audience

Alice: Discussion in the CSS WG on Monday, about display:contents;
... The lack of a normative definition of the accessibility tree was part of the problem.
... The Core and HTML AAM specs describe it, but neither spec actually defines it.

Ryosuke: Is there a problem statement for what we're solving?

Rossen: A common pattern starts with "In the accessibility tree...", and there are assumptions about what that means.
... There is no one single point of explanation.
... It's also a complex model and easy for people to make assumptions about it.
... The accessibility tree has had many versions over the years too.

Ryosuke: So the goal is to describe the accessibility tree?

Alice: Yes

Rossen: We don't want to extend it.

Alice: The indended audiences
... UA implementors, spec editors (particularly CSS and HTML).
... Web developers (using dev tools).
... Web Platform Test (WPT) developers.
... testing tool authors.

Ryosuke: Do you see this as a non-normative note?

Alice: Good question. Any thoughts?

Joanie: If we make it normative, do we say there is an official accessibility tree, and if an implementation differs from it, it is a problem?
... We are likely to get push back if we do that.
... Could we get that spec out of CR? Probably not.
... Doesn't mean don't do it.

david_clarke: We have the same type of problem in internationalisation (i18n).
... We have best practice documents that are intended to be live, and they're updated as things change.

<notabene> +1 for Best practice

Alice: A living document makes sense.

Rossen: I lean to having a Note because of the observability of the tree.
... Most implementations have a different version of the accessibility tree.
... Making it difficult to observe and test them all.

<joanie> https://w3c.github.io/aria/#accessibility_tree

Joanie: This links to some editorial changes to the core AAM
... There is content in the AAM and ARIA specs that could be taken out and put into an accessibility tree spec.
... It would need to be a spec with minimal normative text and a lot of informative text, but that couldn't be a Note.

Alice: What would the focus of the Note be?

<Zakim> joanie, you wanted to mention the inclusion/exclusion stuff(tm)

Steve: If Assistive Technology (AT) implementors don't have a standard definition, that's not a good thing.

<nigel> +1

ac rn

Ryosuke: That's slightly different I think.
... To describe the model that UA will use to create their implementations of the accessibility tree.

Steve: What about exposing this to JavaScript?

Alice: Yes, I would like to.

SteveLee: Also in browser AT.

Steve F: If there is a relationship between the abstract and the applied implementations, if it isn't mapped normatively, it wn't be much use.

Wilco: It's hard to definitively test at the moment.
... Not having clear requirements makes it difficult.

Janina: We may not want to end up with a single document.
... Normative on the agreed stuff, a Note for the rest.

tink: There is a proposal from the AB for an Evergreen/living standard, which has a session at some point today at TPAC.

Alice: Depending on what you want out of the spec, a different approach might work better.

Ryosuke: There are two approaches to writing the document

<TabAtkins> Living Standards topic is Saint Claire 3B at 2pm

Ryosuke: One is to write what the browsers are doing, and that will be hard to write normatively.
... And there is the map approach.
... So we could move the bit that talks to the platform layer into its own place.

Rossen: The idea is to collect all of the different accessibility tree normative candidate requirements, and start this new document.
... Then fill in what's missing, either as Notes or normative text.
... Defining what the tree lifetime is supposed to be, as well as how it can be ehanced.
... Offering to be a guinea pig for the Evergreen standard would be good.
... Wouldn't be opposed to starting in WICG.
... With the assumption that we will not do anything destructive to existing specifications.
... When we have enough interest, we'll think about merging.

Alice: Could we do this with AOM?

Rossen: Could do.

Joanie: To be clear, this is not ARIA, but ARIA would start depending on this spec.

<Zakim> joanie, you wanted to say why it's not ARIA

Joanie: It is likely that ARIA people will contribute, but it is not an ARIA spec.

tink: I have a slight preference for a separate place.

Steve F: Is AOM a CG?

Who will do the work?

Alice: Rossen and I will.

Joanie: I will contribute.

Wilco: I will.

melanierichards: We'll chime in.

Ryosuke: I think we'd be interested, but I don't know who the person would be.

Judy: Why wouldn't you join this with AOM?

Alice: The question was where this work would be done, and one option is putting it in with AOM.

Judy: It was your response I was curious about.

Rossen: We were considering rejoining AOM anyway.

Lifecycle

Alice: There needs to be interplay between HTML, CSS, and ARIA.
... How should specs refer to this document?

Tab: The things I need to know are how big is the tree and how does it relate to other features on the platform.

Joanie: In some cases we'll point to it.
... Sometimes informatively, sometimes normatively.

Ian: Is AAM a place to reference this spec too?

Joanie: Mostly in ARIA.

Ian: Directly in ARIA, not the Core AAM?

Joanie: Yes.
... Unless this document normatively prescribes what the accessibility tree must look like (not what it must contain, we already have that).
... If that changes so that everyone ust have the same accessibility tree, then it would become relevant to all the ARIA and AAM specs.

Ian: There is a repo for a CSS AAM, and I'm not actually sure what that look like.

Joanie: Lets take this to the ARIA WG meetings.

IAn: Works for me.

Nigel: You mentioned CSS and the accessibility tree
... If you take a confined space like a video, there is a limited number of available pixels.
... We can prioritise pixel use, captions over controls or something.
... I'd like to be able to define that in accessibility terms, and have that flow back to the CSS/presentation layer.

Rossen: This goes back to some of the core reasons for this discussion.
... All of the accessibility tree implementations provide some way to do this
... Lots of the heavy lifting is done by the AT, that do it on behalf of the browser instead.
... In Edge we have a clear sense of process isolation, and locked the AT out.
... So all the heavy lifting had to be done through the accessibility API, UIA.
... To your point Nigel, this is exactly why we want to dfeine accessibility tree.

Nigel: There may be other parts of the DOm that layer on top again.

Rossen: Yes

Nigel: You want the accessibility tree to define the layout.

Rossen: You're talking about something like spacial navigation?
... I think that's different.

Nigel: I'm saying that the CSS should be able to respond to the accessibility.

Rossen: For us, accessibility is just a different presentation framework, that builds on top of DOM and style.
... It takes information from the layout tree, but that's about it.
... After that it's its own projection.

Nigel: This is why I raise this point.
... Now the information flows in one diection, and I'm suggesting it could/should flow in the other direction.

<Zakim> nigel, you wanted to ask about the order of flow of information and if it can go in two directions

rossen: We've decided where it will live, who will work onit.

Alice: Now we get into the weeds.

Joanie: What is the weeds list?

Alice: It's at the URI I posed before.

Joanie: Oh. That is weedy!
... In a good way.

Alice: Thank you everyone.

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/Steve:/SteveLee:/
Succeeded: s/David/david_clarke/
Succeeded: s/jaonie/Joanie/
Succeeded: s/Mealnie/melanierichards/
Succeeded: s/Alice;/Alice:/
Present: Léonie (tink) david_clarke Wilco aboxhall Janina mrobinson jofranchetti IanPouncey Joanmarie_Diggs irfan clapierre anne_thyme gpellegrino Rossen CurtBellew tzviya Rachel steve JuanCorona gildas Irfan_Ali TabAtkins estes JF Nigel_Megitt jaeunku_jemma SteveFaulkner melanierichards Judy_Brewer gowerm
Found Scribe: tink
Inferring ScribeNick: tink

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)