ARIA WG F2F TPAC - Day 2 -- 17 Sep 2019

<jamesn> we are in #pwg

<jamesn> https://global.gotomeeting.com/join/994278485

<jamesn> we are in #pwg

<ZoeBijl> we are in #pwg

<ZoeBijl> scribe: ZoeBijl

Repeated content

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

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

JD: James Craig how strong do you feel about linearised?

JC: *scribe fell behind*

Who is the primary client fo this CSS spec

It felt like this was a similar thing

In medium/long form articles

scribe: or books

The pullquotes which were he primary case

You might want to navigate to them

But read them in the linearised version

This is kinda like a CSS media type

If you tell your SR to “read all” you don’t want it to announce repeated content

JD: So repeated content are things that you’d want to be read in certain context

JC: yes

Like with VO if you do a two finger swipe down it’ll read the entire page

You might no want tthe repeated content to be read

My issue with the current proposal is that it might be too narrow a usecase

Perhaps we can apply this a broader use case

*James Nurthen makes a joke about aria-sometimes*

JD: So you’re saying… aria-linearised set to default?

The content author sets when the content is read.

But should it be the SR that says “hey this is repeated and my user said they don’t want that”

ZB: Would something like an aside be another example of “not entirely relevant content”

*group is unsure*

JN: Redundant links

Anything that’s not repeated you want to read all the time right?

*group agrees*

Can we come up with anything that’s not repeated content

MK: I like the word redundant bettter

JD: You do? I think I do too.

JC: We should look at vocabulary

I think repeated content is a lot clearer and easier to understand than redundant

ZB: I agree, I think repeated is easier and more appropriate than redundant

Maybe we can make redundant a synonym ;)

MK: I’m not entirely sold on the use case period

If we’re trying to craft the end user experience

the screen reader experience

in ways that assume the SR user’s intent

you need to somehow, the screen reader, needs to somehow communicate their intent

JD: SR would have to implement an option for this

MK: JC you said something about the two finger swipe down

JC: if we know the authors inttent

and it’s declaritive

MK: Having it be a SR option instead of a content option

Would make it a per user thing

I don’t think SRs need more options

ZB: could this be incorporated into a SR’s verbosity settings?

JC: We already have something for repeated labels

MK: That could be

But the difference between reading a text book

<scribe> continues reading

versus not wanting to skip them

ZB: do you find it annoying to get repeated content read to you in articles

MK: That can be a bit confusing

<Jemma> +q

Just trying to figure out who is responsible for that

MK: it feels like something that has good intent and could be useful

But before you put it in a spec it ought to be tested with real people in real situations

What would implementations look like?

JN: Isn’t that the way we work?

Freedom Scientific already said they’re interested in it

JC: Just want to emphasise that I don’t like redundant

JD: Can you comment on the issue?

JK: we already have landmark roles

if we look at the landmark concept

you can skip the navigation

JD: using pull quote as an example
... you can mentally ignore it

Because it’s styled differenly

So visually it’s easier to ignore it

That’s a lot harder if you use a SR

<jcraig> Issue?

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

*something about repeated headers*

Well he and others are debating that

JN: That’s not our debate

MK: It’s kinda interesting

Like 90% of the headers is repeated

But the page numbers aren’t

But I often like to hear page numbers when I’m reading a book

It makes you aware of the transitions

JD: dPub has a role for that

Perhaps we can use that

But for truly repeated content we could use aria-repeatedcontent

MK: I’m not too annoyed by repeated content

JN: Yeah but if you get a long pull quote it might be different

MK: I agree

JK: Are you saying that a pull quote can’t be a separate issue?

JD: Most users probably don’t want to be interrupted by all this content

<jcraig> Commented in the issue: After the F2F discussion, I withdraw the suggestion for the broader approach. I think “repeated content” or something similar is easier for authors to understand than the concept of linearized content for screen reader reading modes.

Unless you’re proofreading or something like that.

MK: It could be a nice feature to have

<chrishall> The minutes from yesterday don't seem to have set <tink> as scribe for "HTML Accessibility Issues" https://www.w3.org/2019/09/15-aria-minutes.html

<chrishall> Yesterday this was resolved by someone inserting a scribe historically via `i/Table Ontology/scribe: ZoeBijl`

<inserted> scribe: tink

<chrishall> So something like `i/HTML Accessibility Issues/scribe: tink/`should resolve that.

<chrishall> heh

<chrishall> ty

<jcraig> https://github.com/w3c/csswg-drafts/issues/3708

<jamesn> we are now in #css

https://bocoup.github.io/presentation-aria-and-webdriver/#/

<spectranaut> https://bocoup.github.io/presentation-aria-and-webdriver/#/

<scribe> scribe: ZoeBijl

<Boaz> link to slides: https://bocoup.github.io/presentation-aria-and-webdriver/#/

Note: this meeting will not be minuted as the script for the talk is in the speaker notes. Potential discussion after the presentation will be minuted.

Example of pushButton documentation: https://bocoup.github.io/aria-practices/aria-practices.html#automation-pushbutton

*JC pointed out that close attention should be paid to how the role of an element is determined*

Related to the “inferring the role” part of the proposed documentation linked to earlier ⤴️

*start of discussion/feedback*

Val: again there are multiple ways to check something like a button’s label

Do you think the guidelines are stable enough to use it for this?

Is the time now to do this?

So we’re testing ideas that are in the APG

Those are the topics and questions for now

SP: This is webdriver extensions

In that sense it makes sense to document them in the webdriver spec

AutomatedTester: the webdriver spec tries to give us primitives to allow people to automate

with WD we think we have three audiences

web qa person

spec authpors

and people that want to write automation for something

Like a webcrawler

We try to cater to these three audiences

and we try to make the primitives as low as possib;le

I’m not against this being in the WD spec

But perhaps it’s a new primitive

It’s not like a core…

Not how e historically thought about this

It’s not a subset of people

that’s why I wasn’t sure if it fits in the WD spec

That’s where my initial gut feel came from

average user, it’s kind of like, fitting those three groups of people

The spectrum is incredible broad

How does that fit in

With push button as an example

No one has come to us to ask “how do I push a button”

ZB: I think it would be good to automate this, take away people having to think about accessibility

Even if no one asked for that

AutomatedTester: absolutely

And then you would go and try and do a click or keyboard interaction

And at that point it uses the accessibility tree rather unlike DOM commands

So what Val and Simon were saying

You get these stale ????

If you did find it

and you try to interact with it

you throw an error saying “hey this isn’t in the a11y tree”

JJ: I was thinking in the case of the examples

the dev would have alrteady have given the role to the element

I think it would be more interesting to tell them ??

Would rather have it say click this role via the accessibility tree

Val: I think that’s the intention

JC: Pitched this idea years ago

Probably in some other repo

Some of the primitives that this could pile onto is element.computedRole

Not necessarily go through the script but ask the engine

You can get the role and label from there

You can find elements by computed roles

AutomatedTester: can we get this via JavaScript?

JC: No

<aboxhall_> element.computedRole is experimental and buggy

It’s going through the DOM tree, but that doesn’t necesarily mean that the browsers are doing the right thing, you can’t check that through the DOM.

JN: I believe you can get it in puppeteer now

JC: Getting access to the entire accessibility tree is going to take a long time

Getting access in webdriver would be trivial tho

SP: Why wouldn’t we give access to all developers

JC: That’s a good question, right now there’s a significant performance hit

SP: Is it heavy to request the role of an element?

JC: Not necessarily but there are complications

ZB: Would it be heavy to get all elements of a certain role?

JC: Yes. I suggested a :role selector for CSS years ago. But when we tried to implement it with the CSS WG we found that it was too heavy.

Select by label (similar to what’s on slide #8) is something we use a lot to find things

This works through the accessibility tree

So I hink this is a great idea

I think this should be closer to the APG (?)

AutomatedTester: whereever it lives doesn’t stop it from being implemented

ZB: As long as it’s not he APG, because that’s a note not a spec

AutomatedTester: webdriver puts lots of effort into extensibility into its spec

I think it fits better in WebDriver

Boaz: I think the idea here is to change web developer's mindsets

I don’t think this needs to be in the WD spec

AutomatedTester: the other thing I tried to advance is

this is very input driven testing

<jamesn> ?

which is one of the easier sides of testing accessibility

<Boaz> boaz: I think the idea here is to change web developer's mindsets

aria-details

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

<joanie> https://github.com/w3c/aria/issues/1001#issuecomment-521076833

<Jemma_> https://github.com/w3c/aria/issues/1009

<spectranaut> scribe: spectranaut

<Matt_King> From the spec:

<Matt_King> "In some user agents, multiple reference relationships for descriptive information are not supported by the accessibility API. In such cases, if both aria-describedby

<Matt_King> and aria-details are provided on an element, aria-details takes precedence."

<Jemma_> https://github.com/w3c/aria/issues/1009

mk: (describes jongunds issue) the way we spec'd aria-details, it is not meant to describe an accessible description

the challenge is that we don't know what an accessible description is, and what the difference of intent is between aria-details

the content in aria-details should be navigatable to, but accessible description does not have to exist in the dom because it could be a hidden element

the main thing we would like to accomplish is: what is the content referenced by aria-details in particular? what is the AT expectations?

if you use both, you maybe overwritting the accessible description?

so are the details the description?

cl: we looking to use aria-details int he publisher context for enhanced image descriptions

say we have an image that is complex, like a table (heaven forbid) we would like to use aria-details to put a table in aria-details

or if we had an image of a math equation

can we use aria-details in this way?

when a screen reader hits an element with aria-details, it says, "has details"

we would like it to be a linkable, clickable, navigatable section

have a mechanism to the go back where they were in reading

mk: question about images. is there a reason the image wouldn't be in a figure and all of that details content would be in a fig-caption, directly associate with the image?

cl: maybe a publisher wants all of those description sin an appendix, instead of encapsulated in a fig caption with the image

mh: I share charles's interest. We generate a lot of content with complex images.

we need to provide a link to image and structure description

without aria-details, we could use a figure with text descriptio. structure info about a image and flatten it into aria-describeby is bad

I'm not thrilled with aria-details. does the screen reader need to tell you how to get to the structure content. what if that content has another link.

jn: one good thing about aria-details is that we are about to get more implementaiton sof it because of aria annotations work

hopefully screen readers will add a way to navigate to the annotation

<Avneesh> https://github.com/daisy/epub-accessibility-tests/tree/master/content/epub30-test-0340/

av epub use cases link link above

aria-details and aria-describeby is huge. aria-describeby truncates tables and does not provide good descriptions

people do not want to put descriptions by image by at the end of the page

aria-details is not announced by screen reader, but we need a way to move between the image to where the description is and back again

jc: annotations. aria-details reminds us of longdesc. but there are benefits -- same page.

<Zakim> joanie, you wanted to state we need to do something about the mappings.

BUT aria-details actually has use cases unlike longdesc

<joanie> https://w3c.github.io/core-aam/#details-id-105

jd: if there are details and describe-by is due to UIA -- if they have one description.

if microsoft can add something to their api to differentiate between aria-details and aria-describeby

what happens if both appear and we can only expose one of them?

UIA is microsoft's user interface automation

mk: support for aria-details. no one is suggesting to get rid of it. Microsoft wasn't read to support it but it went into the spec anyway. if we can get rid of the conflict that only exist in UIA then we could make aria-details fully functional on all platforms

if in a year from now we have aria-details support. from an authoring perspective, it is not the accessible description.

<joanie> Identifies the element that provides a detailed, extended description for the object. See related aria-describedby.

<joanie> The aria-details attribute references a single element that provides more detailed information than would normally be provided by aria-describedby.

mk: "accessible name and description calculation" -- aria-details has nothing to do with that

jd: confirms that is in the spec

<joanie> Unlike elements referenced by aria-describedby, the element referenced by aria-details is not used in either the Accessible Name Computation or the Accessible Description Computation as defined in the Accessible Name and Description specification [ACCNAME-1.1].

jc: annotations are not descriptions

mk: we need to find another way to communicate this in the spec not using description

what will the authoring practice say? if annotations go forward, we can include information about that

<Zakim> joanie, you wanted to ask about the "alternatively... link to web page" bit

<joanie> Alternatively, aria-details may refer to a link to a web page having the extended description, as shown in the following example.

jd: something else the spec says that we should get rid of (above)

unofficial decision: get rid of reference to "Extended description"

av: some people want to put accessible restrictions at the end of the book

they say the authors have control of content on the pages

different webpage

each chapter is an html page

last page has restrictions

av: we want aria-details to be able to link to a different webpage

aria-details links to a link that will link to a different web page

mk: we will have aria-details that links to a link. the language of the spec (above) implies the user should be able to bypass that directly -- if aria-detail points to an anchor, then the use will not navigate to the location of the anchor tag but instead to the target

is there implied UA functionality?

aria-details can point to ANY structure content, like a thousand links instead of one link

does that line imply it can skip the user to another place without rendering/announcing the link

mh: trying to minimize navigation steps is what we want. description is part of image element, it's right there, they don't have to navigate

it's not a good user experience to jump around to what should be read in context

by: I'm using aria-details

is the question: is the content of the reference just a url?

if the fragment pointed to was an anchor without any text, might as well follow the href

jd: I'm worried about the accessibility API to move back .

by: I know within publishing in general the web annotation spec could serve a similar purpose, but it takes another page and merges it together

we should move it off to the publisher group

references in aria-details can point to things that are not in tree but could be added later...? but if there is a use case to keep them separate, there must be a way to combine them.

av: authors really want to the book to look like the printed book. And that is why they want to put the description at the end

some authors want in the same html files and some want it in different ones

mk: I want to echo what ben was saying and I think we need to strike the language about the links and the publishers that need to put the details content in another place out of the way then there are multiple other technical solutions and some of them could use aria-details and some couldn't -- aria-details needs to refer to directly to content visible int he page that can be moved to.
... we should entertain a resolution to strike the language about going to links

jd: I'm in favor

by: there is being discussed an include tag. go get a whole webpage and make that a description of the thing you are inside of. the include tag could provide that.

I want to bring in a whole iframe but like a description

<ZoeBijl> https://github.com/w3c/aria/issues/748

jn: read issue

<ZoeBijl> Live code example: https://s.codepen.io/Moiety/debug/3c14a0599ab1a6a6c491f7ebf4119f1d

<jamesn> https://github.com/w3c/dpub-aria/issues/15

the issue from this morning is related: dpub aria

(reads new issue dpub-aria #15)

s/#14/#15/

section number: 525 in 1.1

<Jemma_> https://www.w3.org/TR/wai-aria-1.1/#mustContain

zb: in issue 748, what is the problem with the code example?

jn: the problem is that it is defined as: owned is any descendant. In reality it doesn't work. If we need to count the number of list items in the list, it would be wrong. a list of one, then a list of one

jd: also the accessiblity tree is wonky. webkit removes useless divs. others don't, firefox and chrome have issues

jn: what do we want to do about this?

jd: I think we correct the spec and say it needs to be a direct descendant

we should change the definition of owned to be a direct descendant or direct child or anything pointed to by aria-owns

<ZoeBijl> https://html.spec.whatwg.org/multipage/grouping-content.html#the-ul-element

mk: we are forcing people to put aria-owns if there is an intermediate div

zb: reads link. if an li is a role of "item" then the code in the issue is correct

jn: you are reading the wrong section

that is the ul element -- it is flow content ... ???

zb: nevermind

<jamesn> https://github.com/w3c/aria/issues/748#issuecomment-473594928

jn: my proposal is in comment linked above

avoids problem of adding role=presentation on every random div

everyone: makes arounds of agreement with suggestion in comment

jd: I agree with principle of what you are describing but there needs to be more description. inbetween elements must have role none or generic or any other property that would force its inclusion in the accessibility tree

mk: they also can't be focusable or have text

jd: user agents need to do some tree pruning

jn: they don't have to tree prune but it is the easiest way

jd: if we put this change in the spec but ua don't do anything then it's usefully change

this doesn't work in ua and at -- so changing spec language is not enough

we can't normatively "must" the ua prune the tree

jn: I have one more question in the comment

should we also allow descendant elements of the aria-owns also be ignored in this way

<jamesn> Should we also allow you to reference a DIV with aria-owns rather than referencing the individual LI elements..... This would be really handy for tables split into scrollable regions.

jn: an extension spec. in dpub they are subclassing an aria-list expecting to be able to say an ul has these children, where our spec explictly forbids it

they would also have to subclass ul into their spec

jd: I'm ok with your proposal and aria-owns having the same funcitonality

jemma: are we taking care of the epub issue?

jn: its a similar issue but it is not the same

<Jemma_> https://github.com/w3c/dpub-aria/issues/15

mk: lets conceptual discuss how to solve the dpub issue

should we have explicit spec prose about how to extend aria?

jn: AT would have to support this

<joanie> https://w3c.github.io/dpub-aria/#doc-biblioentry

jd: the link I just put in

superclass role of .biblioentry is a list item

now dpub-aam

<joanie> https://www.w3.org/TR/dpub-aam-1.0/#role-map-biblioentry

this goes one step forward and says it exposes on all platforms as a list item. In the mapping it says that it is a biblioentry

some platforms communicate that

<Jemma_> https://w3c.github.io/dpub-aria/#doc-biblioentry

AT automatically support these subclassing

the problem with the extension spec is that the modifications to the list item made by biblioentry is in violation of the aria spec for required owned elements of list

vy: We need to change the spec to allow this scenario

jd: yes that is right

<Matt_King> What the spec says about extensions: The use of RDF/OWL as a formal representation of roles may be used to support future extensibility. Standard RDF/OWL mechanisms can be used to define new roles that inherit from the roles defined in this specification. The mechanism to define and use role extensions in an interoperable manner, however, is not defined by this specification, and RDF/OWL...

<Matt_King> ...processing is not essential to interoperable implementation of this specification. A future version of WAI-ARIA is expected to define how to extend roles.

mk: if we put any extension language in our spec right now, then do we need to change what it says here about how to extend roles?

jd: no because we still haven't defined how to extend roles

mk: if we add some language to the section about required owned elements and that language specifically says that if an extension subclasses a role, then that extension may define the required owned elements for that role?

<ZoeBijl> scribe: ZoeBijl

JN: could we just say just for the list role

are there other subclasses of listitem

treeitem is a subclass of listitem as well

<BGaraventa> I'm on the call as well

or we could have a different subclass

<BGaraventa> :)

there’s spec level subclasses and extension level subclasses

MK: That’s what I was saying

JN: It seems a bit hacky. but it works

<sarah_higley> wave! :)

MK: We don’t have anything else for making rules

I fear it’s a can of worms

JN: Sounds like a 1.3 topic o me

MK: Maybe we should post, have this issue

considering 1.3

I don’t think we should try to fix this in 1.2

Because we don’t know all the ramifications of it

We already have modeules

But we have nothing that governs them at all

JN: Is there another way to fix this?

JD: They could add a numeral, but they don’t want that

JN: They have a dpub-list which extends list

<sarah_higley> I don't see an issue with saying they should extend list

MK: I thought they had list?

They have listitem

That just means that in their markup, in their spec, all their implementations that instead of their bibliography

JD: Yeah but the bibliography is the whole thing

It has more stuff in it

MK: Whatever their ul is, they should have a bibliolist

If we were going to solve it it would be a 1.3 issue

JN: So we should ask ourselves (or them) if there are additional issues

If there are we should definitely move it to 1.3

MK: Either fix in DPUB 1.1 or we take a year to fix it in ARIA 1.3

ZB: W3C Nu Validator doesn’t throw an error on this.

aXe 3.9.0 does

Long term planning for W3C explanitory resources related to ARIA and other web technologies

<BGaraventa> I got lots of energy

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

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

MK: there’s a few things that we’d like to cover

but the ultimate goal of this is for me to walk away with some notion of whether or not the group supports some new more end user friendly approaches to helping web developers learn about accessibility from W3C resources.

HTML and potentially WCAG

But let’s discuss it among our selves frist

We need to know what this groups wants to support

I’m thinking about the multi year picture

But not less than two

But preferably a lot longer

So I want to talk about the problem

before we do that tho

I want to make sure everyone is up to date

particular the APG and the ARIA AT

APG does not yet explain all of ARIA

all of the new ARIA 1.2 stuff will be in APG 1.2

we have a new “role” coverage

Same for states and properties

So we can better explain what we have covered

But when it comes to guidance with example we have long way to go

So there’s a lot of work to do on the APG itself

My original goal is to close that gap by the end of the year

It’s realistic to think we can achieve this by the end of next year

especially with the help of Boaz’ team

have a more standard PR review process

trying to beef up that APG TF operates

so it can fulfill its mission

A big problem with the APG is that it does not help people make stuff that works with all the bugs that exist in all the AT and browsers out there.

It’s not a component library you can just grab components from and drop in your project

It’s a resource of how ARIA should be used

if AT and browsers didn’t have any bugs it would be a component library

If someone comes to the APG and thinks they can use it without testing it has a bad influence on the end users experience

providing support tables is not in the scope of the APG

That’s why we now have the ARIA AT CG

Its goal being to provide support tables or a supported score that would give some indication of how well supported these examples are

I’d like to give Val some time to discuss our progress

Val: we joined in because of our background in testing

we have two goals

one is to design a test suite

for the APG and ARIA in general

designing a test suite is a big task because there are a lot of implications and difficulties

so we need a way to write test that can be understood by users and AT

We also need a document that describes how AT should behave

Such a document does not exist

So we’re also talking to AT companies to create such a thing

Designing a test suite is a huge bulk fo the work

As it is right now we’re breaking down the design patterns in the APG

into a bunch of expectations

The second goals is designing a test harness that assert these tests to manual testers

We’re not sure how much time and how frequent we can test

Bocoup and Facebook are working on this together

we’re trying to lock down the design for this test suite

In november we’ll build a prototype

that’s the timeline right now

<Jemma_> Timeline is finishing the design by the end of Oct, and delivering the product by the end of November.

<Jemma_> +q

JK: Part of my question was answered already

it was about timeline and the goals

I think it’s pretty tight

The last AT meeting I joined there was a table of AT and browser combinations

What does the final product look like?

MK: End of november is only the test harness

Val: yeah, it’s a prototype

We might start to record results

we won’t have a full suite

we want to have some initial tests

but it won’t have enough for a full suite

it won’t be robust enough

we’ll have to run test first

MK: This is an exploratory prototype

To see what kind of issues we’ll run into and how we can fix those

JN: What other kind of documents (other than APG and ARIA AT) do you have in mind?

MK: There are a lot of different W3C resources related to helping a web dev make stuff accessible

some is almost duplicated

but some are maintained by different groups

<Jemma_> s/strick/tight

<Jemma_> https://www.w3.org/TR/using-aria/

<Jemma_> https://www.w3.org/TR/html-aria/

the list of resources, the big buckets, are APG, ARIA AT both from ARIA WG, Using ARIA (from the WPWG),

ARIA in HTML (also from WPWG)

<Jemma_> I think we should define what we meant by "explanitory resources" precisely.

WAI Tutorials

from EOWG

not sure to what extent that covers WCAG techniques

they’re ment to be explanitory resources

<Jemma_> +q

The problem I see with all these resourcesw

there’s important information in all of them

they need to be known by the same people

from our perspective we can say that’s your groups scope, this is our goup’s scope, etc

clear for us at the W3C, but not from the outside

there’s confusion outside of the W3C.

Sometimes the resources say different things.

We need to look at how we can serve the community

that best servers their purposes

maybe there should be a community group that sucks up all of these resources

that forms a format that can combine all of them

I like how the WAI tutorials are represented on their own site

Why not have something similar for all of these resources

That’s the question I would like to put forward to the group

JN: I agree that it should be a website

Boaz: it should be like a bootstrap thing

MK: I would love fort there to be tutorials that explain our choices for a design pattern step by step

<zcorpan> scribenick: zcorpan

jamesn: as soon as you take accessibility practices
... you take away aria practices, since aria may not be the best way to solve a11y problems

Matt_King: encapsulating all of aria in apg is part of the scope of the new rename accessibility practices
... debate of the name
... and scope
... if we rebrand scope, tutorial is not just about aria

Boaz: accessible practices

jamesn: so that is beyond scope of this group
... if our pages are in a similar.. .can be integrated with theirs

Boaz: what's your preference for merging these things into a more coherent resource

jamesn: if they merge we can't own them

Matt_King: there are joint task forces

jamesn: there could be something like that

Matt_King: joint TF can have as part of its scope explaining the aria spec

jamesn: yes

Matt_King: it would have to have aria representation, aria wg would be a stake holder

Boaz: no matter how governance is in terms of ownership and scope, we need to talk to web platform wg or whatever about do we want to delete "using aria"

Matt_King: if it was mdn there would be a governance issue there too

Boaz: maube there could be a way to have that scope in APG, done by aria, in a way that can be consumed by e.g. MDN

Matt_King: next step in exploration?

- DRAFT -

ARIA WG F2F TPAC - Day 2

17 Sep 2019

Attendees

Contents

Repeated content

aria-details

Long term planning for W3C explanitory resources related to ARIA and other web technologies

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output