<MichaelC> meeting: APA TPAC Day 2
<mck> scribe: matt king
<mck> js: Most important aspect of prep now is to ensure wejs: what should we accomplish in the joint meeting?
<mck> ip: Make sure people know the css tf exists
<mck> ip: Make sure they have awareness of resources and links, issues in github, etc.
<mck> Encourage participation in github as new modules come up.
<mck> js: beyond that, talk about navigation
<mck> Leonie has an illustrative example to demo.
<mck> lw: I have na mp4 showin a simple set of 3 buttons layed out usin flexbox
<IanPouncey1> https://www.w3.org/TR/css-grid-1/#placement-a11y
<mck> ip: The flexbox example is a good one.
<mck> ip: I have a qick agenda
<IanPouncey1> - Introductions [Janina]
<IanPouncey1> - History [Ian]
<IanPouncey1> - Call for participation [Ian]
<IanPouncey1> - public-css-a11y@w3.org
<IanPouncey1> - w3c@ipouncey.co.uk
<IanPouncey1> - How to interact with WG - best way to raise issues [Ian]
<IanPouncey1> - https://github.com/w3c/csswg-drafts/issues/1925
<IanPouncey1> - Specs under review [Ian]
<IanPouncey1> - https://github.com/w3c/css-a11y/projects/4
<IanPouncey1> - Navigation [Ian or Janina]
<IanPouncey1> - https://github.com/w3c/css-a11y/projects/1
<IanPouncey1> - https://www.w3.org/TR/css-grid-1/#placement-a11y
<IanPouncey1> - AAM?
<IanPouncey1> - Spatial navigation?
<mck> ip: review agenda
<mck> I will cover how to interact with the css ax tf
<mck> when discussing speces in review, the point is to help peopl understnd that we should review new specs and modules
<mck> Discuss current css grid guidance on content order vs display order.
<mck> js: Is there a section of wcag that addresses this
<mck> ip: logical readng order combined with logical focus order.
<mck> ip: 1.3.2, meaningful sequence
<IanPouncey1> https://www.w3.org/TR/css-grid-1/#placement-a11y
<mck> mk: Is our point that the css grid ax uidance is too constraining?
<mck> ip: A question is whether the css grid guidance for accessibility sufficient
<mck> And, how can spacial navigation work with this?
<mck> Spacial nav is effected by these methods of layout.
<mck> LG put forward proposal for spacial navigation using css.
<IanPouncey1> https://lgeweb.github.io/spatial-navigation/
<janina> present_ janina
<mck> lw: LG does not have the only spacial nav proposal.
<mck> lw: Florian believes we need to be sure people understand the use case for spacial nav
<mck> How do we give user confidence that they know where their focus is going to move next.
<mck> This problem has existed for years, e.g., absolute positioning.
<mck> flexbox just makes the problem more prominent because of its useulness.
<mck> ip: It has been possible to break the correlation between DOM and display order for a long time.
<mck> Question: is the documentation and warnings currenty in css sufficient?
<mck> Is the spacial nav propsal worth working on?
<mck> Does there need to be a method for specifying whether focus order should follow DOM or spcpacial layout ?
<mck> ip: Phrasing as question is a goood approach for the joint meeting.
<mck> questions:
<mck> Is exsiting documentation sufficient?
<mck> Is there a place this can be better place to do thi, e.g., css AAM is on posibility.
<mck> Is the spacial nav spec from L some for the css w to pursue.
<mck> Should DOM order be the only method for contrling keyboard navigation order?
<mck> js: these are question that we need joint work with css for answering.
<mck> js: for those who have been in css for along time, these are not new questions.
<mck> but now we are ready to work on this systematically; we have the css accessibility tf in place.
<lisa> janina, do you want me to join a meeting now?
<MichaelC> Minutes of joint meeting with CSS
<MichaelC> Minutes of joint meeting with Editing TF
<aboxhall> Does anyone want to dial in?
<mck> scribe: matt-king
<mck> dm: will discuss limations of aria and a11y api's, syntax proposal, and use cases solving.
<mck> Some of this is implemnted behind a flag in Chrome.
<mck> Some of this is already in Canary.
<mck> First gap: limitatins of IDREFs
<aboxhall> https://tink.uk/playing-with-the-accessibility-object-model-aom/ by @tink explains how to use the command line flag enabling AOM in Canary
<mck> aria-labeledby and activedescendant requies an IDREF
<mck> Not always possible to have one.
<mck> Gap 2: Inputs from AT are not always possible to captue.
<mck> Think about aria slider.
<mck> On desktop, arrow key conventions work fine.
<mck> For incrment and decremnt.
<mck> We do not have analogous conventions on mobile
<mck> Gap 3: 1 to 1 correspondence between DOM node and accessible nodes in AX tree.
<mck> We don't have this limit on native.
<mck> gp 4: Limited ability to inspect the AX tree.
<mck> We also have some annoyances.
<mck> There are no reflective APIs.
<mck> A11y details are difficult to encapsulate.
<aboxhall> Further to the encapsulation issue: if an element "sprouts" attributes, they are available for the embedder to modify, but there is then no way to recover the original semantics if the embedder removes the ARIA attributes
<aboxhall> cf. if you use <button role="link"> and then remove the role attribute, it goes back to being a button
<aboxhall> vs. <custom-button role="button"> where you change the role to "link", if you remove the role, it's no longer a button or a link
<mck> ip: tabindex is not specific to AX tree. So is that in the scope of AOM?
<jcraig> Slides/Demos (Note: many details TBD or subject to change) https://wicg.github.io/aom/demos/
<mck> dm: The ability to have a custom element that is focusable by default, without tabindex, could be.
<aboxhall> Use demos in Canary with flag enabled as described in https://tink.uk/playing-with-the-accessibility-object-model-aom/
<mck> A: Page focus, from tabindex, is out of scope for AOM.
<mck> However, readability by AT is in focus.
<mck> correction in scope.
<mck> Showing the current AOM API.
<mck> Describes syntax for checkbox.
<mck> For somethig like activedescendant, you could directly reference objects.
<mck> Once you have accessible node attached to every DOM element, you can attach input event listeners to them.
<aboxhall> Whitelist of event names e.g. "accessibledecrement"
<aboxhall> Receiving AT events has a privacy implication; we propose showing a permission prompt to allow the site to handle AT events
<jcraig> dm: normally, a11y api “press” is abstracted by the browser engine into a “click” event in the web content
<aboxhall> Event then falls back to a standard "click" event which would be handled via event handling on the element
<aboxhall> JC: Example: Firefox trying to implement "slide to unlock" on phone
<aboxhall> Handled differently via Screen Reader vs. for sighted users - sighted users would need to grab a slider and slide it, vs if an accessible click event happened it couldn't be an accident so it would trigger the unlock
<aboxhall> Example: a custom slider (e.g. canvas based)
<aboxhall> listen for "accessibleincrement" event which can be sent by AT
<aboxhall> e.g. "flick right" gesture on some mobile OSes
<aboxhall> q: how is this different to IndieUI?
<aboxhall> IndieUI was trying to solve a much broader problem; this is narrowly scoped to assistive technology APIs
<mck> The next phase is virtual nodes.
<mck> You should be able to create nodes in AX tree that do not existin in a DOM.
<mck> Rather than somehow makrup the unerlieing document, let's just create an AX tree that matches what is going on.
<mck> JC: examples are like Google Docs.
<aboxhall> and iWork for iCloud
<aboxhall> These are heavily customized HTML and/or canvas/SVG
<mck> Similarly, for iCloud, which uses an SVG image.
<mck> Even though there is a document structure, it is too complicated to mark it up in a way that is accessible.
<aboxhall> Lots of live region announcements are used so these are in effect "self voicing" to a large extent
<mck> Today, they use off screen input so it it is sort of like a self voicing app.
<mck> This falls far short of desired experience.
<mck> JS: Didn't realize we have anything in Web GL.
<mck> DM: Today we have to create hidden DOM elements.
<mck> Demostrating a tic tac toe that you can only play with a screen reader.
<mck> The cells are exposed to VoiceOver. Visually they are drawn on a campus.
<mck> One canvas element in the OM.
<mck> Using the AOM, we create virtual accessible nodes.
<mck> SOM focus may be on the body or canvas.
<mck> But, AT needs to know that focus is on a specific cell in the grid.
<mck> Next example: a remote desktop.
<mck> In this case, the browser only sees pixels; there is no DOM representation of the remote app.
<mck> You coudl expose the remote AX tree from another omputer and explore it in your local web browser.
<mck> SL: Sheets used to render with HTML table but moved ot canvas.
<mck> Phase 4 is intraspection.
<mck> An auditing tool could query the AOM and find out the computed role, computed label, etc.
<mck> JC: one thig not now possible is detect which role was actually applied.
<mck> For example, you could have role="switch checkbox"
<mck> The web app cannot know which role ended up in the AX tree.
<mck> Similarly, the web app can't know if the role string was invalid.
<mck> AB: describing alternate syntax.
<aboxhall> el.accessibleNode.activeDescendant = child.accessibleNode
<mck> IP: Were you saying that the first syntax proposal is less familiar?
<mck> JC: The thing that is not familiar is the eistice of the AX tree.
<aboxhall> Alternate syntax long-form https://gist.github.com/alice/c684bd031adcd0483d0306d95c32d0e9#using-virtual-accessiblenodes-to-set-default-non-reflected-semantics
<aboxhall> oh no, accidental deep link, apologies
<aboxhall> https://github.com/WICG/aom/blob/gh-pages/explainer.md explainer for current syntax
<aboxhall> https://github.com/WICG/aom repo with links for explainer and spec
<mck> mk: what is the path to getting this outside the experimental space?
<aboxhall> Please file issues on the repo for any and all comments!https://github.com/WICG/aom/issues
<aboxhall> all feedback is welcome
<aboxhall> https://wicg.io/
<aboxhall> https://www.chromium.org/blink/origin-trials
<aboxhall> https://github.com/GoogleChrome/OriginTrials
<mck> JC: Feedack and experimentation while in incubatio leads to the kind of info needed for a well formed w3c standard.
<mck> We see a standard in the future.
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Present: MichaelC matt_king janina Found Scribe: matt king Found Scribe: matt-king WARNING: 0 scribe lines found (out of 261 total lines.) Are you sure you specified a correct ScribeNick? Scribes: matt king, matt-king Agenda: https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2017 Found Date: 07 Nov 2017 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]