See also: IRC log
<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.
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]