Accessible Rich Internet Applications Working Group Teleconference -- 09 Nov 2017

<jongund> I can hear really well

<jongund> Yes

<jasonjgw> Joanie notes the IRC channel and the wiki.

<jasonjgw> Participants introduce themselves.

ARIA 1.1 post mortem

<MichaelC> https://www.w3.org/WAI/ARIA/wiki/ARIA_1.1_Post-Mortem

<jasonjgw> Joanie: Core AAM, ARIA 1.1 and two publishing-related specs have reached Proposed Recommendation. Accessible Name computation is still to come.

<jasonjgw> Michael: earliest date for ecommendation is 7 December.

<jasonjgw> Joanie: introduces a review of the ARIA workflow..

<jasonjgw> Joanie:notes that testable statement writing had to be put on hold while API mappings were developed/complete for all platforms.

<jasonjgw> Obtaining platform mappings from UA developers is sometimes challenging and was a time-consuming activity.

<jasonjgw> Joanie notes the complexity of editing complex tables (of testable statements) in the wiki fomrat. This further delayed completion of testable statements.

<jasonjgw> Manual testing (as carried out for 1.0) was time consuming. Automated tools were developed for testing ARIA 1.1. Automated testing brought to the surface errors in the testable statements on the wiki.

<jasonjgw> Joanie developed code for automating test generation for the core AAM.

<jasonjgw> While all of this work was being carried out, milestones were missed.

<jasonjgw> Where implementations were absent, Joanie filed bug reports. In one case (at least) this led to belated comments from UA developers.

<jasonjgw> Joanie notes challenges in integrating/using automated test support provided by developers working on different platforms/accessibility APIs.

<jasonjgw> Matt: notes an issue with the CoreAAM with aria-haspopup.

<jasonjgw> Joanie clarifies: aPopup became a named token rather than a boolean. Joanie notes inconsistencies in the accessibility APIs on different platforms in their ability to expose the semantics of the token values.

<jasonjgw> A further example is autocomplete.

<jasonjgw> Joanie: notes significant bugs disclosed by the testing process.

<jasonjgw> Joanie: errors in the AAM were discovered after entering CR.

<jasonjgw> Changes in the CoreAAM could not be made without exiting/re-entering CR.

<jasonjgw> It turned out there was a case for such change.

<jasonjgw> Joanie notes that after reaching CR, many WG participants were limited in the contributions they could make.

<jasonjgw> Many of them wanted to contribute but needed support.

<jasonjgw> Joanie summarizes: we need to develop the mappings and the features simultaneously.

<jasonjgw> Joanie notes the need for greater involvement from user agent and AT developers.

<jasonjgw> Using AAM as the test for implementability is problematic. Evn if the mappings on a platform aren't correct, if how the ARIA features are being exposed on the platform can be determined, this should satisfy a criterion of implementability.

<jasonjgw> Joanie reiterates that using wiki table markup for writing testable statements introduced more problems than it solved.

<jasonjgw> Programmatic generation of testable statements reduces the necessary commitment of human resources.

<jasonjgw> This amounts to performing tests in minutes rather than in hours.

<jasonjgw> Joanie's conclusions: if we adjust our workflow, complete test automation, provide support for working group participants, and improve timeliness of testing/implementation, we'll all be able to improve Web accessibility more effectively.

<jasonjgw> Joanie: notes the proposed workflow and the upcoming session on improving interaction with UA/AT developers.

<jasonjgw> After lunch: presentation of AOM.

<jasonjgw> Joanie expects questions regarding the AOM.

<jasonjgw> We also plan to discuss the next versions of ARIA - being able to use a platform accessibility API to set the state of a widget - the relation with AOM and division of responsibilities need to be determined.

<jasonjgw> Later this afternoon: ARIA and SSML demonstration/discussion from Educational Testing Service - if time permits. If schedule does not permit, this will be hifted to otmorrow.

<jasonjgw> Michael: proposes to discuss reactions to the "lessons learned".

<jasonjgw> Question: whether the work can be divided into smaller units.

<jasonjgw> A(question by Aaron Leventhal).

<jasonjgw> Alice: asks for an expalnation of where the input comes from to introduce features and mappings into the specs.

<jasonjgw> Joanie's answers are in the "modifying workflow" topic.

<jasonjgw> Matt: ARIA 1.1 was meant to be an extension/iteration of 1.0 to solve real-world problems encountered in using 1.0. For example, all of Matt's feature contributions were based on needs arising from solving actual engineering problems.

<jasonjgw> The improvements were intended to provide better experiences for users - in particular, screen reader users.

<MichaelC> https://github.com/w3c/aria/issues?q=is%3Aopen+is%3Aissue+label%3A%22ARIA+2.0%22

<jasonjgw> Michael: for ARIA 1.2 we have an explicit requirement, as primary focus, to attain parity with HTML features.

<jasonjgw> Michael also notes the role of the issue tracker in requirements gathering.

<jasonjgw> Joanie: working group participants and members of the public introduce their issues (including requests for new features) on, nowadays, the GitHub issue tracker.

<jasonjgw> Aaron: suggests a module system or another suitable approach to enable parallel development of features.

<jasonjgw> Micahel responds that we haven't worked out how to undertake modularization properly, while noting the existing modules and potential additional modules. How to develop modules without modifying the core remains a challenge.

<jasonjgw> Michael notes that the initial priority was to add to ARIA features not available in HTML, but features that were available in HTML were later added.

<jasonjgw> Aaron notes that implementors are treating it as a living spec.

<jasonjgw> Joanie proposes to switch the agenda by taking up "modifying workflow".

<jasonjgw> Participants opt for a 15-minute break.

<jamesn> scribe: jamesn

Modifying Workflow

<MichaelC> https://www.w3.org/WAI/ARIA/wiki/Modifying_workflow

Joanie: What didn't say explicitly is we enter PR when we meet long ago defined CR criteria
... this is a proposal not a declaration
... https://www.w3.org/WAI/ARIA/wiki/Modifying_workflow#Primary_focus_in_proposed_workflow

Alice: mappings and the features need to co-evolve

Joanie: if we come up with aria-foo as a boolean and becomes a token list that impacts mappings
... have to know enough about it to know how to map it
... just for that feature lets get the test files and results
... and put them where they belong in the webplatform tests
... we do all of that pretty much all at the same time
... sometimes we luck out where there are participants in the WG they implement it without bugs
... for implementations we don't have we file a bug
... alongside it we talk to AT vendors to make sure they are onboard to using it
... also getting those devs who we hope to take the feature - get their feedback and know if they plan to support it
... would like authoring guidance at the same time
... all at the earlty stage would like that

MK: see where we are talking to AT vendors about support. If we get the first implementation in any browser then we can make an experimental exmple in the APG right away and that can be conversation about support in AT. having that early on gives us real world experience

Joanie: was nodding violently

Aaron: have had a problem understanding what CR means and to whom. Implementors? No - not really. we have our own judgement. Authors? No - they care if they can use it and if it works
... what does it do other than a w3c checkbox?
... we are all working on an evolving blob

MC: what CR means and to whom? difficult. is it more than a w3c checkbox? reason is to show implementability of a spec
... things get done differently now. implementation tends to precede specs
... if we had our testing house in order could have done that with aria (0-length)

JS: RAND requirement predates CR. Does it come along with CR?

MC: double check on that at CR but that comes earlier

JS: in the real world the meaning of CR becomes 0 length value. check the box etc.
... doing it iteratively makes a lot of sense.
... time to pull things too.

MC: known problem is that we test a minimal level of implemntability - not broad implementation
... later will be talking about "living standards"
... CR is a kind of checkppint - but are finding that there may be other ways

Joanie: why I care so much. Enter CR and have to wait 60 days - and if have to exit and renter CR and wait another 60 days... it is a checkox which if we cannot check is a problem
... brings me to "Should we enter CR?"

(step 8)

Joanie: 1 feature at a time
... if answer is yes then we have to enter CR with all features that are "ready"*
... enter PR after approx 60 days. We will know that we have met our exit criteria

https://www.w3.org/WAI/ARIA/wiki/Modifying_workflow#Thoughts_on_implementation_details

"Single ARIA feature" workflow

Joanie: Features go into the editors draft until they are ready with EVERYTHING. only in WD once essentially done

MC: 2 models - after every feature - or perhaps every x months

Create test file(s)" meaning

Joanie: JS hacks at the moment - makes it possible to spew out test files
... once that is cleaned and documented it will be able to generate rather than spew test files
... as i have it all in my head - i will write the doc
... i will give training on everything
... wnat everybody to be involved in the process

SF: what is the timeframe for the creation of the documentation and creation of etc.

Joanie: 2 approaches

he creator/modifier of the feature does steps 1-6 (Joanie's preference)

scribe: we need to get more WG members able to do more of these things
... if Joanie is the only one who can do something and we have a bus we have a problem
... if we all know how to do it and we have multiple busses then the spec can keep going

OR Specific members focus on specific step(s) (Joanie's not preferred option)

Possible criteria for "readiness" of a feature

Joanie: these are just ideas

Positive confirmation of acceptance by a sufficient* number of user agent implementors in the form of a passing test result or a comment in a public issue tracker that they intend to implement as described in the spec(s).

Joanie: need reasonable confidence that we will have 2 implementations
... if we have none of that then have idea that it is not ready

Positive confirmation of acceptance by multiple assistive technology vendors in the form of implementing support, or a comment in a public issue tracker that they intend to implement support.

Joanie: want it written down

MK: 1 step was file a bug for missing implementations. We would at least need them to take some action on their own bug

Confirmation by the Authoring Practices task force that there are no unanticipated problems with the feature.

MK: here is out example as to how an author would use a feature. would get written confirmation from at vendors as to how they work.

Joanie: another possibility is that in the course of doing the authoring - we get a doh - if we check that checkbox then would call that feature ready.
... if we do those things then could be ready to ship at any given moment
... the 1 thing which is not addressed by this is "Platform owners cannot make changes in mappings without risking exiting CR

scribe: everything else as i scroll through is directly addressed by the new workflow.

JS: want to play devils advocate - hope it comes to fruition. 1) Authoring guidance - catching up is done.

MK: no - 1.1 will come out this year (hopefully). don't think it will stop us adopiting this workflow

JS: 2) what we have found in the past is we agree a feature makes sense - now 6 months later find something isn't right.
... I doubt that wil lstop

JN: hopefully will ahppen less frequently with new working pattern

Joanie: perhaps want to group things
... all features for a super custom foobar thing
... all in the WD/ED how often do we want to dhip

MC: 1stly - process requries public feedback. Have to plan for stuff to change
... can't have 100% and should expect to have to recycle.
... have to use known maturity to decide if ready
... possibly for bookmarking for later

MK: I believe that some of that happened in the past due to the monolithic approach. 1.0 has stuff which don't know why it is there. can avoid some of that by starting the cycles with conceptual planning discussions.
... where we talk about a vision for the release
... and at least whiteboard some of it so we get future dependencies etc. for tiny feature which could be basis for something else later

JS: tightening up the process would reduce the amount of change
... would agree that it won't eliminate everything entirely
... point of CR - there will be some people who won't want to do it twice. so that is part of the reason for CR

Glenn: as a screen reader vendor there is always the catch 22 - more to do than hours. don't want to spend time on features that wont see light of day.. If don't do it then can't figure out how would work for users
... sectioning and headings was a disaster - and noone started using it until after CR. early prototyping and experimentation would have been good

MC: wondering if (may be an anti solution)
... some implementors don't want to do things twice. and features can change as dont work how we thought. other way is more complex to author or don't meet user needs.
... wonder if want to have n idea of authorring practice early in the process

MK: could try to do it in parallel... have the pattern in my head. the spec text is just the speccy way of saying what is in the practices

MC: should have a wireframe

jOANIE: for no other reason than bus factor

Bryan: we have clients who are implementing right now. get questions if it is safe to use APG patterns for enterprise development. Level of support in AT and browsers differs
... dealing with legal requirement. prevents people from using widgets

MK: at the break we were talking about caniuse equivalents...
... falls outside our scope
... would be reluctant to make it part of the practice

MC: restict auto testing - with auto test file generation. seperatly from aria web platform tests... etc.. lots of tests daily. almost have ability to add aria

MK: in space of AT caniuse means can use everythign together
... issue is when it goes into a grid pattern

very different kind of thing At testing

MC: don't see it as the APG responsibility

MK: we all need it but whether do it under w3c umbrella
... it will happen at some point

MC: I think that sort of data is beyone the scope of the aria wg.
... i like to have reach goals. would like it to be on the horizon - not saying need to work on it now

JGW: looking at where it leaves us in the process. looking at proposing a feature or a smlal set of features
... what goes in the spec etc... writing mappings etc.. and aving some level of APG support.
... once that had been reached mugrate into public working drafts... is that the point that implementors would take it.

once enough can go to cr. is that a rough outline of where going?

scribe: need to fill in some details etc.

Joanie: need some time to think
... i am still leaning towards filing bugs etc. we have implemntors here - at what point should we file bugs
... curious when we should file a bug - this is an unstable feature etc.

MC: in terms of the whoops factor - if have tracking then we can make sure we know who has implemented.

AL: can reach us on email, irc etc.

AB: how can we experiment with these. webstandards have incubation process... allow people not from useragents to experiment
... so from a useragent point of view.. if things are lightweight can experiment fairly easily.
...
... if looking at an unbaked features helps mature then can

JC: some things that have worked well are @-ing on github repos where issue discussed. if stable (relatively) then please file bugs

MC: just occured - could add a commit hook to repos

<jongund> Got to go

<MichaelC> scribe: MichaelC

Better coordination and interaction with user agent and AT vendors

gg: what would you define as good collabaration with AT vendors?

jgw: implementations happening, not leading to unforseen problems too often, sending feature input to WG

general sense of knowing what´s going on

jn: open public dialog

sometimes there have been private conversations that a subset participate in, but not everybody knows

mck: not just about implementations, but about what problem we´re trying to solve

in the past requirements seem to have gone one-way from ARIA WG to implementer

and unsure how that worked out

e.g., aria-controls which has proved nearly useless in spite of an idea that seemed good at the time

but implementation not really helping user

or combobox, would have really benefitted from a conversation earlier on about what problems we´re solving, what features should work

aria-autocomplete we could have had richer imagining of AT support

have these discussions with multiple AT vendors

gg: the more targeted meetings ARIA WG can have on this topic, the more we can contribute

my org can´t focus on the bigger picture and always be there

a bounded discussion with tangible outcomes is easier to draw people into

also, sooner examples and at least one browser implementation make it possible for AT developer to prototype

need prototype to dig into the concept

<Zakim> MichaelC, you wanted to say sharing requirements and priorities

mc: we should do more sharing of requirements development and sharing to avoid collisions

and identify a common view of the priorities

al: can we plug AT into the issue tracker and schedule conversations when needed?

gg: a bounded box helps; issue tracker isn´t that

being ¨tapped on the shoulder¨ will help focus spread-out resources

mc: if we do a formal requirements gathering process we can engage AT and browser vendors intensively but short term

then we can have a ping in the feature development phase for ¨this is ready to play with¨

(requirements are high level about types of feature we want)

<Zakim> MichaelC, you wanted to talk about requirements doc and gatherng proccess and featre evelopment process

mck: the bounded box makes sense

could we break the work up into timeboxes to focus on particular topics?

e.g, one on grids, one on dialogs, etc.

gg: think that would work well

helps product developers feel more connected to the standards groups

vendors best contribution is at the point of fleshing out the ideas

not refining the wording

jd: I want interoperability between my AT and others

so would like to get in a room together and figure out the best user experience

gg: I´m not looking for that, ATs differentiate by how they express the feature in user experience

bg: at wireframe stage need consistent and properly programmed versions available

for orgs to reference

from my perspective ok if the accessibility is different, as long as it´s accessible

accessible wireframes help to ensure accessibility across the board

gg: +1

mck: +1 to BG

we need to answer the question of what needs to be rendered, not how

the actual rendering be as creative as you like, just don´t leave something important out

aria-autocomplete is a mess right now because of this factor

gg: I heard JD saying everyone should have the same experience; now I´m not

jd: confirm I didn´t mean that

want to make sure there is support for a common set of features

so users can expect support whichever tool they use

gg: a set of canonical examples will help with that

not sure what level of granularity the examples should be at

mck: that´s what APG TF does

gg: are there now tangible things in that we can test against?

mck: yes, now

took a while to build up, had to restructure

been working on process in APG TF

for ARIA 1.1 Rec plan to have a list of canonical examples in APG

would be helpful if I know AT vendors has a particular interest in an example so we don´t mess them up

gg: a ping when things are discovered not worky e.g., in a given browser will help

mck: so circling on status of support will help

jn: this is work we´re engaged in though it´s not final yet

jd: let´s summarize agreements

gg: during requirements phase, we´ll gather AT vendors to discuss in a bounded manner

participation on issue tracker

canonical examples

jd: face to face meetings?

gg: yes, as part of the first one I listed

jd: is travel budget an issue for anyone?

gg: varies by country

<scribe> ACTION: joanie contact stakeholders to feel out potential for travel budget for FtF meetings

<trackbot> Created ACTION-2139 - Contact stakeholders to feel out potential for travel budget for ftf meetings [on Joanmarie Diggs - due 2017-11-16].

mck: in ARIA.next discussion should flag features that need strong AT coordination

maybe plan a couple FtF to bash

look for sponsors etc. to help the budget issue

jd: +1 +1 +1

think this needs to be part of our scope

jgw: JD is brilliant

canonical examples are also ones to which I refer web application developers

so keeping them in mind for both audiences will increase consistency and reliability

even though some people make their own, this sets a consistent base

bg: @@ accessible software if supported yet

AAMs as "living standards" (problem statement)

jd: just to update the WG on the issue - we want to discuss solutions later when some known stakeholders can return to the room

the AAMs map roles, elements, properties, attributes to platform accessibility APIs

each AAPI has a different feature to best represent a given [role|element|etc.]

not always 1:1 between AAPIs but there is some commonality of featuresets

we need to define how the web content maps to those features

which is the role of the Accessibility API Mappings

there are multiple platforms

creating and dropping features in their AAPI at different times

we don´t have control over that in W3C

so the AAMs need to map to a moving target

we get the mappings right for a moment in time, then enter CR, then the platform changes and now the AAM is wrong

but re-entering CR under W3C process is unwieldy to address this use case

we have AAMs shipping with known incorrect mappings as a result

and AAMs with mappings that go obsolete later

user agents that follow the AAM would be right per spec but wrong per reality

so we need a process to update these specs as needed

mc: while keeping them normative

js: view this as a contractural problem

W3C owns parts of the picture, and doesn´t own other parts

in other fields there are contractural obligations to maintain the product in this type of situation

registries is one way

need to define who is responsible for what piece

and keep accurate

jgw: multiple UAs and ATs using an AAPI means best interoperability comes from following spec

but when just one implementation per platform, that´s not a consideration as much

so while some benefit to the AAMs being normative, maybe that creates more problems than it solves

mck: what needs to be normative?

can see AAM as a service to developer, documenting what we think is the right way to implement ARIA spec

our reason for that to be accurate is to be able to test the Web feature

but if they come back to us with an updated mapping, should we care? as long as we an update mapping

to help testing

jd: see initial comment in https://github.com/w3c/w3process/issues/79

if there isn´t consistent mapping, hard for ATs to figure out what to do with content

mck: what we want to say normatively is what the specific result should be

jd: because otherwise potentially inaccessible

mck: can we be softer on normative requirement without being so specific on implementation?

jd: there´s a right way, everthing else is a wrong way

mc: in 1.0 we just documented mappings and threw out there

in 1.1 we mainly received mappings from implementers and documented them - less prescriptive

sometimes uncovered inconsistencies between platforms, and fixed, so that was a valuable role

this has straddled nature of normative vs descriptive

js: we´re finding it´s insufficient for this to be just a W3C product

let´s make it a cooperative venture

jd: in Core-AAM there´s now a credit at the top for Platfrom Mapping Maintainer

so that´s how we did it within W3C but in collaboration with external platform owners

I view as a partnership to maintain (vs contract)

this work has helped to drive diversity of UA accessibility

implementations with partial a11y support can look at the mapping and easily expand in a way compatible with other UAs on the platoform

when we get to the solutions discussion, I like what Jeff put in the issue as a proposal

though any process changes wouldn´t happen until Process 2019

so meantime we need to agree on how to do things within the current Process

so let´s shake out; and see if it informs any process changes we want to see

Proposal including SSML in HTML via WAI-ARIA

<jeanne> Irfan: I work for ETS as an accessiblity engineer. I was asked to present this by Mark Hakkinen

<jeanne> ... Mark presented this at TPAC last year

<jeanne> ... SSML to provide standards for incorporating SSML to provide pronunciation and hints for emphasis

<jeanne> ... there is important in the educational model

<jeanne> ... we want SSML, CSS3 Speech, PLS in a perfect world

<jeanne> ... proposing ARIA SSML uses JSON to encapsulate SSML functions, attributes

<jeanne> ... features: Say-as, break, phoneme, sub, emphasis

<jeanne> ... coordinate (consensus) vs coordinate (GPS)

<jeanne> ... slide with specific examples

<jeanne> ... I have created samples

<jeanne> ... with properties inserted that change the way the text is spoken by screeenreaders

<Zakim> MichaelC, you wanted to ask why aria attribute vs native attribute and to ask about quote escaping in complicated attribute values

<jeanne> Michael: Two questions. 1) You are proposing it as an ARIA attribute, but it fits more into HTML

<jeanne> ... 2) the JSON syntax has a high error rate with authoring

<jeanne> Irfan: The reason JSON was selected was so you can wrap multiple properties. JSON is widely supported.

<jeanne> ... the Apple Speech Synthesizer has to wrap JSON in brackets so that it is recognized by the synthesizer.

<jeanne> Michael: HTML is the more direct route. It is a sideways route into ARIA.

<jeanne> Irfan: I can discuss it with Mark.

<jeanne> Michael: We might want to look at ways that are easier to author to increase uptake.

<jeanne> Jason: Whether this should via ARIA and this group or HTML. This also needs to be picked up by assistive technologies.

<jeanne> ... more than one developer with synchronized timing tools are interested in this kind of approach. How do you deliver it to AT that read from the DOM via scripting.

<jeanne> ... there needs to be some mapping the accessiblity interface for each platform

<jeanne> ... digital publishing worked on this with EPub, but that doesn't support multiple properties.

<jeanne> ... the IMS global learning consortium has some interest in this.

<jeanne> Janina: I suspect that figuring out where this fits in W3C is the work of APA.

<jeanne> ... I'm happy to add it to that list

<jeanne> ... if it's appropriate for ARIA, great. We don't want to assume that. We want wide uptake.

<jeanne> ... we don't want to bless an approach where the coding had to be adapted to specific platforms.

<jeanne> ... that would be counter-productive on many levels

<jeanne> Michael: In addition to doing it directly in HTML, it may be an element so you can continue to use the attributes of SSML. They have done that with MathML and SVG. Something to think about.

<Zakim> MichaelC, you wanted to say more than attribute, element might fit HTML pattern to date

<jeanne> Janina: We have other requiremnts, multiple representations for different audiences, especially for multiple languages. We need a more elegant solution. It's important to address.

<jeanne> Jason: I can work with Irfan and Mark to bring this to APA.

<jeanne> Joanie: Then since Janina agrees, we will pursue that direction.

agenda changes

<jeanne> Joanie: Moving the static AAM discussion to tomorrow to accommodate people's schedules

SVG

<jeanne> Michael: We didn't put on the agenda the SVG graphics module, the @@. SVG group has recently re-chartered and is getting back up to speed. They are interested in talking with us about the graphics module.

<jeanne> ... they own the graphics module, and ARIA owns the AAM, or maybe the other way around

<jeanne> Joanie: We should clarify that. My understanding is different.

<jeanne> Michael: They expect us to do Graphics Roles, not the AAM.

<jeanne> ... they would like to talk aobut that with us this week.

<jeanne> Joanie: I do think we want to work with them. I want to check with Bogden about whether it is a single deliverable.

<jeanne> ... in terms of the implementation, I did some of the implementation for the SVG AAM. I don't think I did anything in Gecko.

<jeanne> Joanie: I don't think we need to do anything else at TPAC.

AOM

<evan> scribenick: evan

Dominic We have a few slides that we’ll use to describe everything

scribe: I’m going to talk about a few specific gaps in ARIA and the spec in general
... at the end we’re going to show some AOM demos
... we’re looking to see that we’re on the right track here
... The big problem we’re trying to solve here is the gaps between web a11y and native apps
... this is targetted at more advanced web developers: people who are developing custom controls and complex apps
... ARIA is meeting almost all the needs for smaller, simpler applications

Alice: This is focused more on people who are creating custom widgets, rather than those who are using them
... people using custom libraries will use ARIA to override

Dominic: slide 1: “Limitations of IDREF”
... if you’re using custom elements with the shadow DOM, they don’t even exist in the same space, so idrefs will not work
... that’s one small issue we’d like to address
... Gap 2: “No way to capture input events from AT”
... if you’re trying to build (example) an ARIA slider with lots of keyboard support, this won’t work on mobile

<aboxhall> http://wicg.github.io/aom/demos/

<aboxhall> https://tink.uk/playing-with-the-accessibility-object-model-aom/ describes enabling the flag

Dominic: on Android and iOS, there are specfic gestures that are used to capture those actions
... the broader issues is web developers not having access to those actions from AT
... Gap 3: “Every accessible node requires a DOM element"
... you have to create a DOM element for every accessible element, which is not always ideal
... Gap 3: “no introspection”
... if you use an attribute incorrectly, there’s no way you can know
... there are tools that you can use to audit the page, but you cannot easily discover the (example) accessible name

<aboxhall> see also the explainer: https://github.com/WICG/aom/blob/gh-pages/explainer.md

Dominic: (annoyance 2): if you’re building a custom slider, custom elements can’t have any default semantics
... it’s a leaky abstraction
... We’re looking to solve these issues with the Accessibility Object Model (AOM)
... . these are things that are a little different in ARIA because it doesn’t require buy-in from AT
... We’re just working in the web platform, so we can simply map things that exist in the current web to give developers extra tools
... (Warning!) the exact syntax of what we’re showing might change
... We want feedback about this syntax
... Some of the syntax might change, but the concepts and use-cases are the same
... AOM in 4 phases
... each phases attempts to solve separate aspects of the spec
... Phase 1: “Accessible Properties”
... anything that you could normally do with ARIA, now let’s just do that with JS
... example: el.accessibleNode.role = “checkbox”; el.accessibleNode.checked = true;
... advantage is that these aren’t just string attributes
... instead of setting a reference to an id, you can simply set the reference to the element
... (phase 1 demo): top section has native button with ids
... label an icon button with a separate element
... bottom section has the .accessibleNode API assigning labels
... Phase 2: Background on events from AT
... examples include a slider or a scrollable map
... “Accessible Actions / Input Events”: button.accessibleNode.addEventListener(…);
... many events are already included
... when you think about voice control or click access, these events are really critical
... it’s a different control system that requires sending more discrete actions to the webpage instead of keyboar or mouse events
... these input events are already supported by native elements
... this (phase 2) allows you to intercept those events earlier

matt: looking at the list of events, where can I find more detailed info about these?

<aboxhall> https://wicg.github.io/aom/spec/phase2.html#idl-def-accessiblesetvalueevent-value

Dominic: details are in the referenced phase 2 document
... we need to tighten the specification here though

<jcraig> mck http://wicg.github.io/aom/demos/

matt: it would be good to have that link in the README

dominic: with these input event, the UA will immediately know that the use is using AT, which is a potential privacy concern
... some sites might try to detect AT, but that’s not terribly accurate
... this would be accurate and not a heuristic
... some sites or apps will sometimes try to give you a different experience
... On the plus side, for sites that want to be responsible, it’s great to have the feature detection
... it signifies that it might be worth potential performance impacts
... (phase 2 demo): “click to use AT” triggers a permissions dialog

matt: to get that dialog to show, you kind of have to know that the user is using AT

dominic: it’s just an added event listener. the permission dialog would show on first click, which would then allow all future events through
... this is more user-friendly now, especially in newer Android and iOS
... apps ask for permission on first-use of that permission
... this AT request follows a similar model, and could be used responsibly or poorly (like current permissions requests)
... example: a cool canvas game also has a good AT experience. clicking play for the first time would trigger AT event permissions request

jcraig: explanation of the demo. clicking the demo triggered a native browser dialog

matt: would screen reader virtual clicks trigger this?

jcraig: you won’t need to know whether the user is using a screen reader. only after permissions are given would we know

glen: JAWS sometimes clicks the mouse, sometimes it triggers an onclick event, etc.
... all of those things sprung up from a heuristic for determining the best desired result for the user
... from a simple case, asking for permission on a site seems like a good idea
... but it seems like it might be prone to leaking
... e.g. if I notify Facebook that I’m using AT, what’s stopping Facebook from then telling other sites/ads that information?

jcraig: nothing is stopping that. it’s a policy issue

glen: I want to make the point that I don’t want this information to leak to other sites

jcraig: the current location API works this way currently. many sites are benign, while others clearly are not. it’s up to the user to click no

dominic: this isn’t an area that is confined to accessibility
... this isn’t technically very different from knowing your location. all the same safeguards for all of these issues could be applied here
... many groups policy bad actor usage of these data
... (paraphrase) there are a lot of social solutions being explored for these systems and models

glen: does the experience degrade gracefully if the user says no?

jcraig: it depends on what the app is doing. it would behave as it currently does

glen: bad choice of words. would someone be worse off if the object model was not in place?

dominic: not necessarily. it depends on the app
... there are some examples that we’re going to show that would not be possible without the AOM
... Canvas slider demo: canvas element that is using the .accessibleNode
... without actually running the JS, it’s just an image (not accessible at all)

jcraig: right now, this works on the desktop, but not on mobile without passthrough gestures (which might still miss the activation point)

matt: they don’t even really work on mobile when using a bluetooth keyboard because of how VO maps the arrow keys

jcraig: mobile expects keyboard events to simply behave differently
... keyboard events don’t pass through in exactly the same way (on mobile)

dominic: “Phase 3: Virtual Nodes”
... the AccessibleNode class constructor allows you to create nodes that are part of the a11y tree, but they don’t have to exist in the DOM
... caveat: we don’t allow you mix and match
... it must always start in the DOM somewhere
... we’ve added extra properties to define bounding boxes (offsetLeft, right, etc. offsetParent)
... Tic-tac-toe demo: a bit unusual because you can only play with a screen reader
... clicking, tabbing; nothing happens
... (VO reads buttons inside each tic-tac-toe cells)
... to clarify: there are no DOM nodes here. this is just one canvas
... (live region on the right announcing what’s happening as the user clicks cell buttons)
... not demonstrated: focus and selection
... once you have virtual nodes, you might need to focus them and manage focus
... focus syntax: virtualNode.focusable = true; virtualNode.focus();
... when using the DOM, you might use activedescendant to indicate which cell is being focused inside the widget element
... this isn’t necessary in the AOM
... AOM and DOM focus are separate
... Selection management is similar
... Remote Desktop / Virtual Machine demo
... MacOS calculator on screen, and a screenshot is being served in the browser
... calculator is navigable and described via screen reader
... clicking a button refreshes image and displays correct state
... why would I want to do this?
... this could be a VM or desktop application
... but more realistically, there are a lot of applications that are doing custom rendering
... in those cases, you might have an underlying accessibility model
... but the codepath pushing pixels is different
... to handle that today, you have to create a bunch of fake DOM elements
... this could be used as “glue code” to generalize mapping from one application’s accessibility API onto the web
... this allows me to use the low-level API rather than hacking up the DOM
... (end of demos)
... Phase 4: Introspection
... right now it’s not possible to do feature checking, error checking, etc. with just ARIA markup
... we’re not as far along with this one, but we have an idea of how it should work
... in this example: myListItem.accessibleNode.compute() => return promise with computed properties
... this allows you to check feature availability
... example shows walking the tree to output the role and name of every element
... this also allows someoe to write AT in the browser
... not a lot of code to do this

jcraig: this is something that’s been missing from a lot of the a11y in the w3c: testing via introspection
... we could at least test the browser portion of this
... last slide: alternative syntax

dominic: let’s take a break now and come back for questions after

<jnurthen> scribe: jamesn

<jnurthen> scribe: jnurthen

JD: Is the answer we give to web components folks - just use AOM?

<mck> scribe: matt_king

JD: jcraig said things which make me happy... do you have a guestimate when can use it for testing?

JC: a ways out from phase 4
... not clear that platform tools will be able to do everything

<mck> jd: one thing we will do for aria 2.0 is the setters/reflection.

<mck> should we still do that?

<mck> or are would we be stompin on each other.

<mck> Whhen reading th explainer, I don't care if both AOM and aria props are being used, I don't care which takes precedene.

<mck> I am wondering if we might have a debuggin nightmare.

<mck> jc: great quextios. some we have answers.

<mck> Do we give precedence to aom.

<mck> AB: For components, we thought AOM would take precedence.

<mck> We see component builders as using AOM and users as using ARIA.

<mck> JC: One idea is both that shadow root and the shadow which each have their own accessibility tree.

<mck> DM: I think there are a few oncerns with web components that are not related to accessibility tht still need work.

<jcraig> Ryosuke had a good idea to solve the precedence order of AOM versus ARIA in the context of web components

<mck> We have run into issues. Do not assume AOM solves all those prolems.

<mck> AB: AOM defers to ARIA for the list of roles, states, and props.

<mck> Where do we draw the boundaries of responsibilities.

<mck> For events, AOM is a good place to begin answering that question.

<mck> Which comes first is not cirticial. could go etierh way.

<mck> JD: Can we use AOM for future ARIA testing.

<mck> You ar meeting with web platfomrs tomorrow as are we.

<mck> RD: We are building web components today, and using this to help us design AOM.

<mck> We are not at an impass with web components.

<mck> Maybe we ask the web components wg to use AOM.

<mck> JD: For ARIA 1.2, we are focused on HTML parity, which is necessary for web components.

<mck> RD: what do you mean by parity.

<jcraig> Gist: The shadow root and the shadow host would each have their own accessible nodes, so the component author could define the default props on the shadow root node, but the component user could override with ARIA on the host node. Precedence/overrides would be: 1. shadow host node, 2. shadow host ARIA. 3. Shadow root node… (so on each node, AOM overrides ARIA but web component users can override the default for a component)

<mck> AB: Imaine you want to re-implement HTML using ARIA, there are a bunch of gaps.

<mck> DM: One thing I ran into creating demos, they are a lot of thngs that are in HTML but not in ARIA.

<mck> When it comes to roles, states, and props, we think it makes sense that AOM has an equivalent.

<mck> We should not have things in AOM that do not exist in ARIA.

<mck> You ask about input events.

<mck> That does not exist in ARIA but is in AOM right now.

<mck> A simpler example is offsets.

<mck> Should we define them in such a way that they could be defined in ARIA.

<mck> We need them for virtual nodes. Maybe they only need to be in AOM and not in ARIA.

<mck> MC: We have enough similar intentions that we should do some common requiresments gathering.

<mck> Let's share plans to avoid clashes.

<Zakim> MichaelC, you wanted to talk about requirements gathering and core review dependency

<mck> JD: Wondering if we want open github issues for things that are in your spec ut not in ARIA

<mck> DM: For something like offsets, let's get a quick answer on is it something we want sometime, never, ...

<mck> JC: Joanie asked about reflection in ARIA.

<Zakim> jcraig, you wanted to continue through Joanie’s questions…

<mck> I think it makes sense to have AOM properties for all the ARIA properties.

<mck> Everyone seems to be in agreement that we should have reflected ARIA attribs.

<mck> JD: I thought there was a conclusion in github that said there wud not be reflection.

<mck> DM: there are finer points here.

<mck> For element defining its defaut semantics, you don't want that reflected.

<mck> However, when overridng, you want it to reflect.

<mck> When components author themsselves, you don't necessarily want that refelcted. It could create perf issues.

<mck> JW: in the html 5 spec, you find description of IDL and everything in one place.

<mck> We are looking at a future where this could e diided into two places.

<mck> It seems a bit complicated to have this spread across multiple docs.

<jcraig> ARIA property reflection makes sense to a lot of people… e.g. el.role could reflect el.getAttribute(‘role’);

<mck> What's the end plan for accessibility of web in next decade or so?

<mck> JC: open quextion.

<mck> One reason why aria should define aria properties and then have AOM reference them except when something needs toe different.

<mck> DM: we are already in a situation where a web dev can't reff the specs. The aria spec by themselves is not enough. Hve to look at many docs. It is already very complicated.

<mck> This makes it more importnat to have good dev facing docs that pull all this together.

<jcraig> what was not reflected was that (for example) Element.accessibleNode.hidden would not reflect back into el.getAttribute(“aria-hidden”)

<mck> AL: Where do we want thing like offst defined. I think it would be good to have a single list. Put it all in ARIA.

<Zakim> MichaelC, you wanted to ask if ARIA missing major features to meet AOM needs right now (modulo HTML parity)

<mck> MC: o you think there are missing features beyond html parity that you need in ARIA?

<mck> JC: Not sure we need offsets in ARIA. They are not necessary. They could be useful.

<mck> DM: there ae necessary if we are going to have one list.

<mck> If we are not going to have in props unique to accessible nodes, it is needed to have them in ARIA.

<mck> But, we could have some things that are only in AOM.

<mck> MC: We should examine that question. we don't have to answr it right now.

<mck> JC: we shoudl prioritize based on where they are needed.

<mck> One example parallel to reflected concept in css.

<mck> the class attrib on element.

<mck> For 15 years or more has been reflected.

<mck> A few years ago was standardized as a class list.

<mck> Somethings that don't make sense in a direct reflection.

<mck> For example, IDREFs.

<mck> Maybe there is a reflecti list for aria-labelledby.

<mck> There can be a sync problem with refelction.

<mck> RD: there is work to answer this moe broadly, rather than AOM having to answer it for itself.

<mck> DM: In one of the early drafts, we discover it can expose the internal guts of each accessibility tree.

<mck> These are solvable problems ... bu it is complex.

<mck> We wnat to make progress on the spec of phase 4 as we wrap up the first 3.

<mck> JN: would it be eaiser if phase 4 was only doen for dev tools?

<mck> JC: It is easonable to ship phase 4 to limited context sooner than the open web, e.g., only in web driver context where exact mapping for diff browsers is less critical.

<mck> That has downsides, e.g., having to test different in diff browsers.

<mck> No one is willing to promise an exact date. we though complex, and now iven more complex than we thought.

<mck> mk: is the main driver of coplexity the diffs in platform ax trees.

<mck> JC: no, primarily the way that the browsers build the trees.

<mck> If we have a leaf node, does every browser agree what the accessil parent is in the DOM.

<mck> GG: what is timeframe if all the stars align.

<mck> JC: Chrome is furthest along.

<mck> Webkit engineers announced intent-to-implement a week or two ago

<mck> for phase 1 and 2.

<mck> Hope by this time next year that there s something yu can turn on behind a flag and there are 2 implementatios.

<mck> JD: thank yo to the AOM team memers here!!

<mck> Exciting stuff!

AAM as Living Standards -- Possible Solutions

<jcraig> scribe: jcraig

<scribe> scribe: jnurthen

MC: we were summarizing issue of how AAMs can be incorrect when reach rec as things change at different rates
... we discussed ... things change on platforms and AAM - we feel it is useful to doc mappings in a normative way but also to be correct in the real world
... we don't want them to be non normative as the exercise allows us to find and fix things

JS: we also clarified that a good deal of the problem is who owns the pieces
... when it comes to what the mapping should be on UI automation it is not the w3c - it is msft. ditto for all other apis
... have different parties responsible
... we are not acknowledging that

JS: not putting responsibility where it would best sit

MC: also that the CR process has timelines which make it hard to be responsive

JD: have to come up with 2 things. Jeff mentioned as a possible way forward

JC: pasted link to w3c process

issue 79

JD: if we all agree with a solution - if it were magically approved tomorrow it will not get in until process 2019 - so need something as an intermediate workaround

<jcraig> Jeff’s proposal: https://github.com/w3c/w3process/issues/79#issuecomment-337175130

MC: does everyone agree that should do mappings differently than we do today
... anyone think we can't do better?
...
... does anyone think that a change to w3c process improve our workflow
... for AAMs
... in the issue I have tried to break down the issue
... Do we agree that some process change is desired or needed?

JC: frustrating in the past.. there was an AAM going towards CR and an OS update happened. AAM was then wrong but couldn't update the AAM
... current process discourages keeping things up to date

MK: if we can come up with an interim solution we can answer but until then we cannot answer whether we need a w3c process change

MC: make these things notes that can be updates

MK: notes can't be normative

MC: correct.

MK: if we had handshake agreements with browsers that say we are willing to treat them as normative until there is a w3c process for that
... but can we do something like that
... I'm on same page as Joanie - there needs to be something that people treat as normative

Joanie: on the 1 hand we know the implmenters by 1st name - but in principle what if there is a new useragent created and they want to know what the mappings are
... we had a handshake agreement

MK: it is interim
... means that no new useragent will get much of the market

Joanie: don't like the note idea

JC: we are already ignoring the normativeness of what is in the standard. We tell people to go to the editros draft
... if a new one showed up we would point them to the editors draft
... other than the title normative - i have no problem with note/living standard etc... have a TR that says look at the editors draft

MC: project management has been working on a way the URIs are created.... there is a proposal where it would be possible for a URI to load the latest editors draft of the latest version

<MichaelC> https://www.w3.org/2017/Talks/tpac-slides/plenary-project/#links

<MichaelC> e.g., https://www.w3.org/TR/core-aam/

MC: by default it would load the latest draft which is current

<jcraig> \/TR/foobar: proxy to [ latest | upcoming ]

<jcraig> \/TR/foobar: proxy to [ latest | upcoming | ed ]

MC: would that be ok for people having direct to latest draft

JD: implementation detail question... does FPWD show up - and is there anything bad about that

MC: didn;t want to distract from 1.1 with 1.2 draft... would also have to tell people to go to the new URL... would be some socialization of it
... a way of better pointing to what we want

<Zakim> MichaelC, you wanted to discuss the ¨upcoming¨ approach and to ask if handshakes are anathema

JS: makes lots of sense
... would become a problem only if somethign like 508 wants a referencable version.

Glen: could the official rec say you might want to look at the WD

MC: the recommendation can (I believe) say you should look at the latest draft - however that is in text no one reads

JW: liek the reference and the URI based solution as an interim measure... should look at the proposed pro cess change and if we would want to make use of it.
... what the min time period would be to go through a CR in a situation when have an AAM which has passed tests etc.. and have changes in a year if you could shorten the CR period

MC: if today we wanted to to a CR the soonest would be Jan 30

JW: not excluding the way MC was saying as a way of socializing a new version

MC: if we were upversioning would take until may 1

JD: still normative and not a note - could live with it
... what are the implications for testing if we have a 1.2 WD AAM - could we use it for testing 1.1

MK: mine is simpler.... if something becomes the URL for core aam and it has other things... why would you ever go to CR.
... if that is what people are going to reference

JC: Jason wants Jeff Jaffe's proposal

<Zakim> jcraig, you wanted to read Jeff’s proposal aloud at: https://github.com/w3c/w3process/issues/79#issuecomment-337175130

Jeff's proposal

The nth version of the standard is stable.

It is easy to add a few branches to this version and call it the n+1st version.

Initially there are no patent commitments to the deltas in version n+1.

At some point in time (maybe after n+2, or n+3, etc.) there is enough change that we formally take it through a REC process to finalize patent commitments.

Even while doing (4) we are already branching out to the next version.

JC: sounds like git trains
... there is a term for it
... more process in git... if the url proposal is ready to go then this is fine for me

JS: why is CR important is that you need legal sign offs
... patent stuff etc.

JC: but it is a mapping document

JS: the mappings come from the vendors
... we go out of sync for the lawyers
... it is accurate when it is reported. we talk about what version we tested with
... and what was in the CR

<jcraig> ck mi

<jcraig> a

<Zakim> MichaelC, you wanted to rejigger ARIA testing

<joanie> https://github.com/w3c/w3process/issues/79#issuecomment-337368521

MC: also want to reply on testing... might want to look at testing aria differently... used the mappings for 1.0 because didn't know what else to do... and in 1.1 did because that is what we did in 1.0
... but not creating new technology per se. if testing mappings seperately etc. would still need to test normative stuff.
... roles states and properties we would try to convince that didn't need to test them but would in the CR of the mappings guide

JD: my ears and brain heard that we dont need to test aria

MC: don't need to test as much as before beacause we are testing the mappings

JD: the aria spec has many things that aria does that UA need to implement....

MC: need to test that but not the mapping

JD: If the AOM lets us do that then that would show it is implemented

MC: without AOM can still do it but it is harder

JD: straw poll

do we agree that will come up with a viable thing in the meantime or do we need a process change

MK: didnt hear what the process would be...
... was all about what you would do in github

JD: my undertanding would be every nth release need to do CR
... a TBD point where have to go through process

MK: on n+1... n+x you can say that that is a normative version

MC: details need to be worked out.
... would require - if understanding correctly - it seesm to me to get the process changed would need that the AC would allow some drafts to be published without the same amount of review
... would probably have to scope to certain types of documents

MK: would come up with the n+1 version and there would be a lightweight process to go through

MC: if there were interop problems could state a version number you conformed to

MK: seems like that would require a formal process change

JD: want to take Jeff's comment - when MC describes - I think we should do micro releases
... we already have 1.1
... 1.2 and 2.0 talking about
... normal software dev there are no api changes

if it is 1.2 feature put in 1.2

if change in OS which changes api without a mapping change goes into micro release 1.1.1. etc.

scribe: all micro releases dont need to go to CR
... would be lightweight
... could keep our specs current

MC: means we would be doing CR with non micro releases

JS: 2 variables.... 1 is the feature set
... 1.2 will be different
... goign to want to test that
... all the new stuff
... meanwhile if the vendors with the APIs change stuff in 1.1 whatever we call it... Don't know why we would need to test it.. keeping it up to date makes sense
... the only thing changing for 1.1 is the mapping.. with a big feature set go through the whole thing

JW: I'm in favour of the micro releases... think that is viable... the only other kind of model is where you have w3c rec which sets up a framework which can refer to the more frequently updated docs... bit like the IETF refers to media types etc..
... not precisely analagous... w3c doesn't have a process to do that kind of thing

JC: the core point of discussion si that any may solve some of it.. core thing i'm hearing is why do you need normative status on that data table
... if the majority of the document is that table why does the rest of the document need to be normative... still not understanding why those mappings need to be normative

AL: thing that keeps people implementing stuff the same way is the screen reader vendors... no one wants to do things 2 ways
... the property values or roles etc. that is not the things we get wrong.. things we get wrong are computing set size etc.. due to other logic in browsers.
... what we do is go to read the source code of the other browsedrs
... we are trying to do our best to make things work. way we find out what is broken is people tell us not this document.
... what really matters is the aria APG
... arguing for making as little process as possible
... most C++ programmers dont like to document stuff
... we want to make updating it as easy as possible
... they are coders and dont like doing this

Glen: think there needs to be some place where there are recommendations and encouragements for 1 browser to follow another

AL: i think it gets us closer to get people sort of on the same page is relationships and the authoring guides and filing bugs
... when we are implementing something new etc..
... we reach out to mozilla - the way it evolves is people talking to each other
... it is more of an output than an input
... i refer to it but primary way is a checkpoint
... getting us in the right direction.

MC: when first did mappings made them prescriptive now made them descriptive
... the work is importnant but not sure the normative piece is importnant
... originally was a wiki - there was a lot of weird rules... tried to put as many weird things in it as we could.

JD: we want these to be prescriptive documents. we want moz to implement it correctly. If we don't have mappings for a platform i do the descriptive approach.
... if it is what the owner of the api is doing then probably what the others should be doing on that platform
... started filling out more of the expectations

<aaronlev> jcraig: lol

JD: if no one is ever going to create a new browser - if someone were everything should be in the spec

<aaronlev> jcraig: ibm did it

<aaronlev> rich and andi snow-weaver

MC: I agree with what you said that consistency is importnat. done increasingly by negotiation... not sure this is working, can we work it out
... a lot of work
... have put a lot of work into it.
... would we do that if it wern't normativce
... hope our work isn't influenced by a beaurocratic thing but maybe it is

MK: autocomplete in 1.0
... for me was trying to figure out why screen readers were not figuting out combo boxes and autocomplete
... the APIs don't contain the descriptive info that the author put in

<aaronlev> i think it's good when we share and collect useful knowledge, and we should try to do it more -- browser and AT implementors aren't all that great at doing that

MK: thinking about what we are testing when we test aria

<aaronlev> we should try to do it but not get upset when we fail, not expect perfection in every case imo

<aaronlev> we get better results when we focus on the experience improving

MK: if we test the spec and the output in the browser tree is the same regardless of the token you use then that should be a failure. are we testing the spec or the mapping
... cant get different values available to the screen reader if the mapping isn't different
... when testing aria in the case like that we are tetsing both the spec and the mapping
... if the mapping isn't normative then can't actually test aria itself

JS: i'm persuaded that they need to be normative. Finding more places where we are finding an AM would be useful
... incresingly seeing that mappings are useful - there is normativety here and could be useful
... here is how you map things on a platform

JW: agree broadly with that - based on math example ensuring the api mappings are good. Final piece is AT - who make best decision on how to show to user. How reflected in the API is important.
... if we think that the fact this is going into a normative spec means people pay attention to it in ways it otherwise woudln't should seek to presever that
... want the most lightweight process we can get

Glen: have been swayed to the descriptive side... even if things are normative. descriptive seems liek good with cooperation.. when platforms diverge most seems when there aren't good ways to map things
... comes down to can the platform apis change to accomodate

MC: wanted to see whether we could more prominetly reference the latest version. doing minor versions more frequently
... continue to think if process change might help and continue to think about prescriptive vs descriptive etc

all we can really do for now

scribe: evolve towards a process change

JD: we agree that due to the amount of time we need a functional solution.
... if we say a year from now we really do want to do that process thing
... do we want to resume the discussions.

MC: I am not proposeing notes
... take advantage of the ability to highlight the latest draft to get rid of the problem of peopl finding old content

MK: does seem that looking at Glen and aaron's points that often it is realted to limitations in the platform APis. IN our experience to date is that a huge portion of the interia we experience when it gets to getting things mapped so they reflect all of the semantics in the spec

JD: whole other topic

<Zakim> jcraig, you wanted to say I’m not hearing consensus. perhaps table the normative versus lightweight discussion and agree to agree on the points we can agree on

JC: philipe's proposal seems to have agreement
... that is better than the oldest version of TR.
... wish to move it into a note.. no longer as active so this is more for others to decide
... seems like all agree on the redirect
... and github streamlining etc.

JD: can you look up that github stuff

Accessible Rich Internet Applications Working Group Teleconference

09 Nov 2017

Attendees

Contents