HTML Accessibility Task Force Teleconference -- 01 Feb 2010

<trackbot> Date: 01 February 2010

<richardschwerdtfe> meeting: W3C HTML Canvas Accessibility Meeting

<richardschwerdtfe> just a sec

<richardschwerdtfe> coming

<davidb> i can't dial in yet

<frankolivier> frankolivier == [Microsoft]

<richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0144.html

<scribe> scribe: Gregory_Rosmaita

<scribe> scribenick: oedipus

Action Item Review

<Stevef> oedipus: ip caller is me

FO: super simple mock-up -- not rocket science but a bit of work author has to do -- more than alt text on img, but fairly straightforward; if map controls bnack to HTML UI elements, easy to do

RS: no problem with focus mangement and drawing image?

FO: did simple - 2 checkbox example; text boxes more intricate, but follow same pattern; as control gets more and more complex have to do more mapping, but that doesn't mean it isn't feasible

RS: looking at it

<richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0147.html

http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0147.html

FO: if ignore shadow dom still visible, this is like JCraig's example; if pretend shadow DOM not there, to AT would like like 2 checkboxes; all interactive behavior and focus interactions work as if actual control
... fake focus in background
... in future, have UA do surface interaction, if programmatically control focus, can control tab order and interactivity of other controls
... biggest hassel - if click on CANVAS element, have to figure out where user clicked; what event to fire (onClick or onFocus) - author needs to do state management not prohibitive, but takes specific wiring

SF: what is in CANVAS spec as regards focus mangagement

FO: nothing specific; very simple to do; no special features required; only thing can't do is put shadow DOM inside CANVAS - could wire up if manipulate DOM but would be tricky

SF: is it in agreement with what is specified?

FO: yes
... once wired up in web browser, can put shadow dom underneath

RS: tabbing?

FO: works in safari, didn't have chance to check with FF

RS: can't get it to work in safari

FO: strange....
... using safari on windows
... we can talk outside of meeting

RS: ok

FO: what you see in CANVAS are 2 checkboxes and a selection rectangle - need API to support that; works like any other control - should be able to tab to first and second checkbox, use spacebar to toggle checked/not checked

JRG: works for me on the mac
... tabbing to controls with safari; can see shadow DOM checkboxes beneath it

RS: space to select and deselect works fine

FO: biggest part getting state synced up between users of keyboard and users of mouse -- once figure out, though, all the same pattern; hopefully toolkit for canvas will do this on author's behalf

RS: hiding it in ACCESSIBLE won't have impact

FO: once support for ACCESSIBLE node, should work
... will try and get it to work

RS: shadow DOM outside canvas

FO: shouldn't have impact on stability of concept

JRG: one potential issue - when inside CANVAS technique for IE to do canvas is a VML plusin -- VML goes inside CANVAS not sure how other content would react to that

FO: using plug-in in IE6, IE7 and IE8 -- side effect of how implemented plug-in -- fixable problem

JRG: running snow leopard, latest version
... will try on windows, too

RS: have to play around with it -- if put inside CANVAS spacebar no longer works

FO: works fine with me in snow leopard -- happy to debug after call

RS: great progress, thanks Frank

JRG: works with FF on mac, too

RS: tabbed to it and didn't see any visual focus

JRG: salmon-colored border

FO: yeah, red border

JRG: saved to desktop and opened it

FO: should work from the get-go

JRG: with FF on mac, tab to it from address bar

RS: running 3.5.7

GJR: current release is 3.6

RS: try to put inside CANVAS to see what is happening

Progress on Chart Example with data table for alternative selection

http://www.w3.org/WAI/PF/HTML/track/actions/16

davidb: http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0145.html

http://devserv.dres.uiuc.edu/ita/jongund/citaweb/test/aria/canvas/canvas1.html

<davidb> oedipus, I saw that email, but haven't gotten to it yet today

JRG: wanted to make sure it is what people are expecting before moring to some place permenant
... status sequences; doesn't work in IE with plugin
... took OurGraph library and added features to it; a lot inaccessible -- sketchbar can be drawn on using mouse; rightClick; if click on bars, brings up tooltip with a click; need to activate focus -- can't i do with aria live regions?
... added content to static chart is one thing, collaborative much more complicated

GJR: couldn't access fallback content with JFW or NVDA and FF 3.6

RS: is TABLE outside of CANVAS

JRG: contained in CANVAS

RS: explains GJR's problem with screen reader access

SF: nothing currently in any implementation exposes anything inside CANVAS

GJR: gotcha

RS: 2 examples to work off of -- need to do something with ContentEditableText
... need to do something with focus for magnification?

SF: yes

CANVAS API

RS: anyone implemented

SF: not the one implemented in spec

RS: need UA implementation of fallback in CANVAS

SF: status of work with Alexander Surkov and DavidB?

RS: how to get into IE

FO: adding other features into IE; can't promise work on this for forseeable future

RS: need to see if can get alex to prototype some of this

Define CSS Attributes and meta data for alternative content selection

http://www.w3.org/WAI/PF/HTML/track/actions/17

RS: started that work
... raised a few questions

SF: did you see my email about opera implementing IMAP ontop of CANVAS?

http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0102.html

RS: collection of links in IMAP?

SF: [breaking up badly]
... underlying HTML DOM elements can relate to AREA elements so can add aria ontop of those

RS: role="image" etc.

SF: yeah -- different approach than being discussed here

RS: how?

SF: using existing concepts extant in HTML, imagemep in different context; focus management would be done as done in imagemaps
... this example that frank had, would have 2 AREA elements with coordinates; would have programmatic focus supplied by IMAP, so wouldn't have to draw focus rectangle yourself; AREA elements would hve role="checkbox"
... works partially now -- what you get, when move focus, will say "button"
... if have role="button" will say "button" -- can override native role with ARIA

RS: violating host language strong native semantics

SF: at this piont in time, there aren't strong native semantics in spec; trying to modify them -- wouldn't define A as button; AREA is similar to anchor

RS: draw visual focus on canvas

SF: same way UA does with imagemap; layover

GJR: can understand why investigating because there is pre-existing code that can be reused

RS: show it instead of shadow DOM approach?

SF: their version of shadow DOM is use IMAP with AREA

RS: within CANVAS?

SF: doesn't have to be; mapped onto imagemap by UA

RS: problem may be that not going to be navigating elements in context of DOM
... when get to canvas, what happens?

SF: think of canvas as static image; has areas defined as hotspots, so tab through those as would tab through normal imagemap

RS: between the canvas tags?

SF: presume that if want to, can put AREA elements and IMAP inside CANVAS, but don't need to -- that's tyhe point ; already mapped via mapping for MAP with AREA inside can be anywhere in document as long as coordinates define focus in image

RS: if put at end of document; WCAG says "put in logical order"

SF: ask you to do in manner that AT can interact with it; AREA element can be anywhere

RS: if want to ReadAll, starting above AREA, you're going to end up at end of document

SF: that's how it works today
... nothing new -- works on IMAP model

RS: problem not with use of imagemap, but putting outside of CANVAS

SF: what people do with images on imagemaps now
... way opera proposal doesn't matter if in CANVAS or outside

RS: if navigating imagemap and there are checkboxes, those would be out-of-context

SF: no, physical focus and information as far as contextual info, AT gets that when has focus on imagemap

RS: no problem with that; what is problem is if context is put in document in document order, mouse interaction not going to be anywhere near a11y for that element; if stick at end of document, have to tab to end then back

SF: way works with imagemap, have image, associate image with imagemap, if have 2 area elements with coordinates on them for that image, when you get to the image, the 2 focusable hotspots are in focus oreder within the imagemap; can go from link to first focusable hotspot, second focusable hotspot, etc. focus order is defined by coordiinates

<Stevef> http://www.paciellogroup.com/blog/misc/canvas-pie/pie.html

RS: write a numerical tab index in there
... author would have to do that

SF: not if use imagemap
... fine if want to put in canvas; wanted to stress that opera investigating this, so we should be checking it out too

RS: besides location outside of CANVAS, don't have problem

SF: issue with focus not an issue with imagemap

RS: who is working on it

SF: Opera under chaals

RS: will talk to chaals

JRG: by using coordinates of area define interactive places, then use aria markup on AREA element to say what it is?

SF: yes
... in IE when access via MSAA tells you is a button -- by virtue of the ARIA spec, whatever roles are there should override, so ARIA roles should override native roles

RS: AREA flexible enough for all controls?
... if want to use standard control inside AREA, can't do that
... frank's example with real checkbox

SF: can't do that -- have to define role using ARIA on AREA elements

RS: don't have issue if works; if want to use standard controls, AREA has a lot of limitations

SF: agree

RS: could say is another vehicle if it maps

SF: advantage is that all the focus stuff is done for you using a known construct, the imagemap, so implementation would be trivial, which is a reason for investigation

RS: when get beyond buttons, may not be so simple

SF: then have to have multiple AREA elements

RS: have to find if there is a point of diminishing returns
... put tools in hands of authors to do what they need to do

JRG: question for FO -- when manage focus, rely OnFocus on standard form control, then update styling of canvas?

FO: yes, UA handle focus management
... doesn't work if inside CANVAS because treated as fallback content by current UAs; could re-write browser to support ACCESSIBLE tag
... if dynamically add it under CANVAS in DOM, but inconsistent from UA to UA

JRG: goal is that all is hidden inside CANVAS element

FO: today's UAs would have to be updated to support interactive elements inside DOM

JRG: could plug-in for IE do this?

FO: clear everything under CANVAS element is bug i filed

JRG: possible implementation problems unless coordination with developers of things for IE; going to have to be cooperation between IE plugin -- people will be manipulating VLM -- possibility of conflicts that will wipe each other out

FO: aware of that problem; where people using VML to add features to IE is a problem for us once we add features to IE natively; native feature conflicting with add on is situation to be avoided
... similar to requirement ot update all browsers; all implementations of CANVAS need changes to make this work

<richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0146.html

Access for All

RS: 2 types: accessforall meta-data for user preferences defined in terms of meta-data
... tried to simplify set down; chose core data to start with -- does all need to be in here for content, or can we reuse HTML constructs such as "lang"
... different content categories for HTML flow (secton, etc.) -- do we need new one for ACCESSIBLE since hidden behind CANVAS

FO: preference is not to add new element

RS: what categories would apply?
... flow content (in document flow) -- interactive content (keyboard navigatable within that spece

FO: what problem are you trying to solve with tagging

RS: HTML5 spec defines different types of content for each element, so need to catagorizwe

FO: can be anything - could be interactive, static or dynamically generated

RS: right

FO: good question

RS: a bit of everything

FO: as generic as possible

RS: if people have thoughts on it, please post to list
... talked about preceding attributes with aria-
... ARIA part of HTML5 spec links to ARIA spec, so no properties from meta-data about resource capabilites are, not necessarily to driver interoperability
... should we procede with afa- for attributes instead of aria-

FO: larger discussion than just CANVAS sub-group

<richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0146.html

CSS media types for tactual and tactile

tactile is defined as "capable of, allows for being touched"; tactual is defined as "arising from or due to touch";

GJR PROPOSAL 1. keep "tactile" as super-set in CSS media groups: [http://www.w3.org/TR/2009/CR-CSS2-20090908/media.html#media-groups]

GJR PROPOSAL 2. add the "tactual" media type (raised line maps, thermoformed objects, etc.) CSS's list of media types: [http://www.w3.org/TR/2009/CR-CSS2-20090908/media.html#media-intro]

that way we only need to ask CSS WG for new media type: tactual

rrch, minutes ARE world readable

- DRAFT -

HTML Accessibility Task Force Teleconference

01 Feb 2010

Attendees

Contents