<trackbot> Date: 23 January 2015

<richardschwerdtfeger> meeting: W3C WAI-PF ARIA Caucus

<richardschwerdtfeger> meeting: W3C SVG Accessibility Task Force

<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-pfwg/2015Jan/0116.html

scribenick AmeliaBR

Why should you care about SVG + Accessibility API

Richard: At the end of the day, your browser is a software application. Access. guidelines for content are not enough.
... What you put in to your content, it's job of the browser to expose that to the accessibility platform on the operating systems.
... with HTML, a gap was discovered for JavaScript custom widgets; no way for browser to know what these were, or how to tell Accessibility API.
... How it works: the accessibility tree mirrors the DOM tree. It is a tree so that event propogation works, and there is correct context for accessibility technologies (AT)
... e.g., options in a listbox are all members of same container. Container knows how many objects there are. Each item communicates information.
... Info for each item includes role infor (e.g., listbox item) and also state info (e.g., checked vs not checked)
... Also includes label information. Various ways to compute this, either from names provided by the other or by descendent content (e.g. text inside a button element)
... This info is used to create the name. You can also provide description for more info. One way is of course the SVG <desc> element. Alternatively, the aria-describedby can point to any element(s) you want.
... That element (pointed to) doesn't have to be part of the accessibility tree itself, could be hidden.
... With the Access tree and info, technologies can pull this information every time something changes, e.g. from user interactions.
... One thing not fully addressed in ARIA 1.0 is rich text. Still not sure how we're going to deal with that. E.g. contenteditable attribute in HTML5 -- need to know caret position, selection region. But also need to know paragraph breaks and so on.
... There are new developements, allowing ATs to really drill down into embedded objects. Not sure if we'll get to that on SVG.
... For SVG, the key is having a way to describe the basic essentials of drawings and charts.
... This has never been done before on an industrial scale. To have authors be able to provide this information in the main content, and have it be properly exposed to ATs.
... There are a number of features of ARIA that have turned out to be relevant, e.g. aria-flowto can help organize the reading order of content from different parts of the document. There may be others we haven't discovered yet.
... One difficult, vs HTML, is that there isn't a natural, flowing order to the content where markup matches display on the screen.
... However, SVG does have grouping information, and this can sometimes replace special attributes.
... re the Accessibility API mapping guide. This was a major change in strategy overall.

<richardschwerdtfeger> http://rawgit.com/w3c/aria/master/core-aam/core-aam.html

<richardschwerdtfeger> http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html

Richard: For ARIA accessibility guide, it originally did not fully integrate with HTML. There isn't always a clear association between native HTML 5 elements and platform accessibility roles. This is may the Core accessibility mapping guide was created.
... Also a separate spec for Accessible name and description calculation.

The original name calculation was too specific for HTML. We needed to generalize, so that there are rules for HTML and other rules for SVG, according to the semantics of the language.

On the Core accessibility mapping, we cover a number of features:

richard: (still) One is keyboard focus control.
... SVG introduces tabIndex. It's a good start, but it won't be enough; it's not enough even for HTML.
... As a developer, you can go in and control keyboard level at a much more detailed level, according to what you're seeing on screen.
... Core Accessibility also talks about native language semantics. You can't override native semantics (e.g. checkbox) with ARIA. For SVG, this is less of an issue since there are fewer native semantics, although there are a few (highlighted in the mapping).
... Similarly, for native semantics of attributes, these need to be pulled out and included in the accessibility tree.
... The role mapping in the Core accessibility API describes how the ARIA roles are mapped to roles within the operating system's accessibility API
... One thing we can't do is tell the accessibility techs exactly how they should present information. This is a cottage industry, people don't like being told what to do. We can try to get the browsers on board.
... We need to work with people from the various platforms to be sure we have a solid mapping across the board from ARIA to accessibility API.
... There are also mappings for ARIA states and properties.
... The final info is the list of allowed features -- descendent content as well as states and properties -- for each role. This becomes the signature of that role. This hadn't previously been defined in accessibility APIs, and as a result ATs had to somewhat reverse engineer.
... Different authors were using things in different ways. Now, ARIA validators can text whether the tree organization makes sense.

shepazu: to confirm, this means that if you have a list box, children have to be list items. You couldn't have a button as a child of a list box?

Richard: Exactly.
... One other thing we did was make sure that most relationships only had to be specified once. This avoids error from inconsistent relationships. The browsers automatically create the reverse relationships when the accessibility API requires it.
... Another thing in APIs that we dont' currently have on the web is Actions.
... The big problem with access keys and buttons and such is there is no way to communicate to the user what that input action will do.

<chaals> [noted the comment on accesskey, since the HTML accessibiltiy TF is working on that topic. Agreed that having a description of what an action is for would be useful]

Richard: Other pieces that are really important, generic to SVG and HTML, is things like dynamic content. When something changes, the accessibility API is notified, and AT has to re-calculate their view of the document.
... E.g. the virtual buffer in JAWS, which stores the part of the doc being viewed.
... Because this is all in the core accessibility, we don't have to deal with it SVG specifically.
... Another issue is menu events, which are available on MS platforms to track progress through menus.

<richardschwerdtfeger> http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html

Richard: But I want to get to the SVG specific specs.
... Except first, the accessible name specs. This is itself complicated enough to take a whole call.
... But basically, it talks about how you find the name when you have different attributes or content types.

<richardschwerdtfeger> https://svgwg.org/svg2-draft/struct.html#implicit-aria-semantics

Richard: We broke this into different steps based on the computation that is usually used. This is mostly based on HTML, but there are some things specific to SVG; we'll have to get Ray (editor) to make sure everything works with SVG, e.g. a document title inside a <defs>
... Now, for SVG. We have implicit roles. What is the default for each element.
... Right now, we're using group role for a lot of things. It's probably not the right role, but it reflects a problem across ARIA languages that we don't always have a specific role.
... So audio and video are mapping to group role, because they are containers for other content. Except on Linux platforms, where there is a specific audio/video role in the platform API.
... Another thing you'll notice in the mapping is that many things map to none. This is important.
... For the accessibility tree, if we create nodes for things that have no value, that will really slow things down.
... E.g. circle. *Unless* the author has specifically given labels, etc., by the author, it won't be included in the accessibility tree.
... If there is info, ideally we would map to a specific role for circles, but that doesn't currently exist. So for now we are also mapping to group role.

<richardschwerdtfeger> http://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html

Richard: We still have other things to adjust (e.g. ellipse had incorrectly not been treated like other shapes).

On the specific mapping guide. Thanks to everyone for their detailed feedback. It both helps with this spec, and other docs we will create down the road.

richard: ... Notice that, wherever possible, the SVG mapping spec just references the core accessiblity mapping spec, to avoid having things in two places.
... One thing, from erik's comments, is whether this SVG2 spec, or is this a generic SVG spec?

shepazu: I agree this is a generic SVG spec.

richard: But what about when SVG 3 adds new elements?

shepazu: Then we update the accessiblity spec.

richard: so should we use a version number.

shepazu: That works. Because I agree (with Amelia's email), that this spec should also apply backwards to SVG 1.
... We revise this spec when required. But we always have a current version of accessibility spec that applies to all versions of SVG.

richard: If we're going to support all versions of SVG, will other things like tabindex also apply back to SVG 1.

Amelia: One thing to remember, the SVG has basically gotten rid of the idea of explicit versions. Browsers will apply latest SVG rules to all SVG content.

Richard: Okay. We may have to explicitly state some things from SVG 2, such as tabindex, and how they work with other content.

<chaals> [you won't *have* svg3-only elements in SVG1 content, right?]

Doug: For new elements, it's not a big issue. Since browsers will just ignore new elements they don't support.

Richard: Does that include SVG Tiny? Cause that included new elements we don't yet have accessibility mappings. Should we mention that?

Doug: I doubt there is a lot of overlap between agents that support SVG Tiny and ATs.

chaals: That sounds like a big assumption...

<chaals> [That is a big call - are you sure?]

Doug: Ok, well we can talk off line.

Richard: So, to go back to the mappings we have.
... For many elements, we have the none role. "none" is new in ARIA 1.1.; it was formerly called presentation. It just means that it isn't in the accessibility API.
... is this clear?

AmeliaBR: I had suggested grouping similar elements, so that you could avoid repeated content and also provide more of a prose description of *why* certain roles are used.

Richard: Is that required for FPWD?

AmeliaBR: It might help with questions and comments

Richard: What about keeping things as "group"? We're working on this in ARIA.

AmeliaBR: Probably keep it, but add an editor's note explaining why it is used and that work is ongoing.

jason: It's generally a good idea in WD to include editor's notes for anything that is likely to change.

Richard: One more thing that needs to be addressed is the recursive name and description computation. We need to make sure that <desc> is ignored when using contents to calculate a name.
... Amelia, what was your concern about <title> elements?

Amelia: Not sure.. (discussion ensues)
... So main thing is that <title> and <desc> have special role (step D) in the computation, they should be ignored for generating names from contents

Richard: We're over time. I'm going to go through all the comments. We're still aiming for a FPWD in February.
... I'm going to change the title to SVG Mapping Guide form SVG2; I'll let Michael know.

<richardschwerdtfeger> RRSAgent make log public

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/(someone)/chaals/
Succeeded: s/chaals/jason/
No ScribeNick specified.  Guessing ScribeNick: AmeliaBR
Inferring Scribes: AmeliaBR
Default Present: Fred_Esch, Doug_Schepers, Rich_Schwerdtfeger, Charu_Pandhi, Jason_White, +1.941.266.aaaa, LJWatson, AmeliaBR, [IPcaller], ed, chaals
Present: Fred_Esch Doug_Schepers Rich_Schwerdtfeger Charu_Pandhi Jason_White +1.941.266.aaaa LJWatson AmeliaBR [IPcaller] ed chaals Chaals DougS Jason
Found Date: 23 Jan 2015
Guessing minutes URL: http://www.w3.org/2015/01/23-svg-a11y-minutes.html
People with action items: