W3C

- DRAFT -

SV_MEETING_TITLE

28 Oct 2015

See also: IRC log

Attendees

Present
dcooney, Joanmarie_Diggs, chaals, JamesNurthen, Charles_LaPierre, Jason_White, Mark, Hakkinen, Cynthia, Doug_Schepers
Regrets
Chair
SV_MEETING_CHAIR
Scribe
ShaneM

Contents


<scribe> ScribeNick: ShaneM

UNKNOWN_SPEAKER: discussion to this point about JS APIs and what we have been doing. Is the accessibility tree / API just another API?

doug: We often find adoption is faster when a feature is useful outside of A11Y too.

cyns: Sure. But I have big developers that are looking for this specifically in an A11Y context.
... ranges are hard...

Doug: We are also talking about other things that are *like* ranges.

Cyns: A lot of the same people are in the room who were in the discussion yesterday.
... Dominic, you work on the Chrome team right?

Dominic: Yes - I work on Blink etc.
... our challenge is that Chrome needs to work with all of the various A11Y APIs. So if a feature isn't available everywhere, we aren't going to use it.

Cyns: The API has not yet been invented. There are 3 people who are working on stuff that is related.
... I am interested in the A11Y requirements that Google Docs and Gmail might have.

Dominic: I can talk to those people, but I don't particularly know anything about those...

Cyns describes some of the idiosyncratic aspects of various AT APIs.

scribe: pondering getting some people to do the API development work on the platforms to get some harmonization.

jamesn: We talked about some of this years ago and the vendors said it was too difficult. If that has changed, it would be a good thing.

Cyns: You mean like calculated Name, for example? I think you can get to that.

jamesn: Yes, but it's not a cheap operation.

Cyns: The web platform work... what is a good solution for web platform A11Y chaals?

chaals: Some people do everything with scripting and APIs. Others write piles of html to make stuff happen.
... these two sides will still exist.
... So you start out by writing APIs and scripted ways of doing things. Then we go back and try to make it available in a clean, declarative way. Because that's cheaper for authors. And less fragile.

Browser vendors get off cheap when everything is done in JS. Other than when the JS is bad.

chaals: so start with writing up the APIs. Then maybe make the declarative stuff on top of those APIs.
... ARIA is declarative. Ostensibly. Except when it is not.
... if you start with an API then you can decide what pieces you need to make the thing usable.

Then you can see about what of that needs to get into the A11Y tree.

<Zakim> ShaneM, you wanted to ask about uptake of declarative things

ShaneM: are there success stories about APIs that then picked up declaractive methods?

Doug: Yes. SVG had declarative ways of doing animation, that then moved into APIs, that then help drive new declarative features.
... At what point of adoption does it make sense to create declarative methods to use APIs?

Cyns: We already have declarative. We don't have good scripting access.
... Office 365, for example, has requirements to access information outside of the markup.

chaals: APIs get developed and some die and some dont. There might not be enough demand.
... but APIs feel like a better way to start.

cyns: So with custom elements, (e.g., an hours reporting thing), if you wanted to make it accessible would the implementation need to use A11Y APIs.

dcooney: you get reuse with components. So if you need ARIA you probably really just use ARIA declaratively. But with a component it has to reach outside the element and hang the attributes outside of the new custom element.
... and that's ugly. Some people want to exercise implicit roles from with the custom element, for example.

cyns: So, for example, if you wanted to support 'toggle' you could use an API to do it instead of hanging the ARIA declarative statement outside of the element.
... We spun up an activity in the WICG to look into this. Some people from Mozilla are working on it. And MS. Please come play.

Doug: do you think that what annotations dovetails with what we do.

cyns: I had not thought about text range scenarios. There might be overlap. We should talk.
... dominic, are you interested?

dcooney: Actually its the other dominic that might be interested. We are doing things with custom elements, so yes - there might be interest.

chaals: The Editing people might be interested (MCE, fidus, ckedit, etc as well as browser implementors of contenteditable=…).

dcooney: editing task force has burned it down to the ground. Just get raw events from the user agent and then do things with them.

chaals: some of the JS editor people have done a lot about A11Y.

jason: we have seen a number of different requirements that could be addressed partially in API development.
... we just talked about A11Y API. We have had s a discussion about web annotation. Digital publishing could use content annotation for assisting cognitive stuff.
... given the communities that are A11Y related and not who need to see trees and subtrees created, annotated, consumed, or passed to ATs.... how many mechanisms do we really need? Is there commonality of function?
... is there a way to have commonality at the API level?
... Is there a common management problem with how APIs access the information? And is there a way to have overlapping and common solutions?

cyns: Has annotation talked to lisa seeman about COGA?

Doug: Not yet.

cyns: Repo is under https://github.com/WICG/a11yapi
... spec in there is related to the mozilla proposal.

<cyns_> https://github.com/cyns/wapa

<cyns_> http://www.w3.org/TR/indie-ui-events/

ShaneM: asked about existing declarative things like input type='date' that don't have an underlying api?

chaals: there isn't a lot of clamor for an API for it. People roll their own.

cyns: the problem with declarative stuff and the reason people dont use it is when there want precise control and the environment doesn't support it.
... people in the A11Y community have been saying just use a checkbox for 15 years. People won't.

ShaneM: Can custom elements get full access for styling etc?

dcooney: Yes. Since the underlying DOM tree is available.
... there are lots of use cases that dont overlap with things in the standards. Like a map.

mhakkinen: One of the things we like about custom elements is that we can do complex things like multiple choice elements.
... we can also use the diagram content model as a solution for long descriptions. Provide a native UI to do complex things with controls.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/10/28 06:30:51 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Browsers/Browser vendors/
Succeeded: s/MCE/editing task force/
Succeeded: s/(MCE)/(MCE, fidus, ckedit, etc as well as browser implementors of contenteditable=…)/
Found ScribeNick: ShaneM
Inferring Scribes: ShaneM

WARNING: No "Topic:" lines found.

Present: dcooney Joanmarie_Diggs chaals JamesNurthen Charles_LaPierre Jason_White Mark Hakkinen Cynthia Doug_Schepers

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 28 Oct 2015
Guessing minutes URL: http://www.w3.org/2015/10/28-jsapi-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


[End of scribe.perl diagnostic output]