W3C

- DRAFT -

SV_MEETING_TITLE

09 Oct 2015

See also: IRC log

Attendees

Present
Fred, AmeliaBR, chaals, Rich_Schwerdtfeger, shepazu, LJWatson, Jason
Regrets
Chaals
Chair
Fred
Scribe
AmeliaBR

Contents


<fesch> action-1733

<trackbot> action-1733 -- Fred Esch to Create a definition of "graphical document" for the glossary. Pass to Joanie when done. -- due 2015-10-15 -- OPEN

<trackbot> https://www.w3.org/WAI/PF/Group/track/actions/1733

<fesch> Definition of graphics document. The parts is square brackets can be removed if you don't want any references to the WAI-ARIA Graphics Module.

<fesch> graphical document

<fesch> A document containing graphic representations with user navigable parts. Charts, maps, diagrams, blueprints and dashboards are examples of graphical documents. An img does not have navigable parts and is not a graphical document. You can compose a graphical document with any combination of [symbols,] imgs, text and graphic primitives (points, lines, paths, rectangles, etc).

<fesch> When the user navigates an element assigned the role of graphical document, assistive technologies and user agents SHOULD provide keyboard support for navigating to the parts of a graphical document. [The WAI-ARIA Graphic Module defines the roles and properties that can assist user agents and assistive technologies in supporting graphical document navigation.]

<scribe> Scribe: AmeliaBR

Fred: In the ARIA meeting yesterday, we were asked to provide a glossary definition of graphical document. This is what I've come up with (Reads text pasted above)

shepazu: I think you've covered all the main points

Fred: OK, I'll take that back to her.

AmeliaBR: My only concern is where it says that a graphical document is composed of things including graphic primitives, does that imply that those are separate roles (because they aren't).

Jason: I do not see that as a problem.

<richardschwerdtfeger> ack

Leonie: I have a concern that img is explicitly excluded from being a graphical document. I don't see why that is necessary.

Fred: An image cannot be navigated.

Leonie: But that does not make it not a graphical document.

Amelia: An img could still be a restricted subclass of graphical document.

Leonie. I would just want to remove that sentence with respect to img.

<fesch> graphical document

<fesch> A document containing graphic representations with user navigable parts. Charts, maps, diagrams, blueprints and dashboards are examples of graphical documents. You can compose a graphical document with any combination of [symbols,] imgs, text and graphic primitives, shapes such as (circles, points, lines, paths, rectangles, etc).

<fesch> When the user navigates an element assigned the role of graphical document, assistive technologies and user agents SHOULD provide keyboard support for navigating to the parts of a graphical document. [The WAI-ARIA Graphic Module defines the roles and properties that can assist user agents and assistive technologies in supporting graphical document navigation.]

shepazu: Actually, an image could be an image map, which would have navigable parts.

Fred: (reads off modified definition)

Rich: Is this the glossary definition? You shouldn't have SHOULD in a glossary.

<fesch> A document containing graphic representations with user navigable parts. Charts, maps, diagrams, blueprints and dashboards are examples of graphical documents. You can compose a graphical document with any combination of [symbols,] imgs, text and graphic primitives, shapes such as (circles, points, lines, paths, rectangles, etc).

Leonie: Can we just drop that second paragraph?

Amelia: I would like to still have some mention of navigation.

shepazu: It still refers to user-navigable parts.

Amelia: That's right. That's clear enough.

Leonie: That's good to me.

Jason: Good to me.

Rich: What about a canvas? Is that a graphical document even if it does not have accessible fallback content?

Amelia: I think so. It's just the most reduced subset, a document with one element.

Leonie: In many cases, you might start with something very simple, but add more content to the document as you go on. You wouldn't want to change the role.

Rich: Another question that came up on the ARIA call was the difference between a figure and an image. The Mozilla team was basically interpreting it as a figure may have multiple parts.

Amelia: That's not the main distinction we were using. We were emphasizing figure based on its role in the document structure, how it is referred to from the text.

Leonie: A figure is distinct from an image. It's a concept that is well established in print for centuries.

Rich: OK, so we're going to need to go back and tweak the definition of figure that has been adopted into ARIA.

Fred: But can we get a resolution on the graphical document definition?

<fesch> RESOLUTION : glossary indention of graphical document

<fesch> A document containing graphic representations with user navigable parts. Charts, maps, diagrams, blueprints and dashboards are examples of graphical documents. You can compose a graphical document with any combination of [symbols,] imgs, text and graphic primitives, shapes such as (circles, points, lines, paths, rectangles, etc).

shepazu: I think so, though knowing it might be torn to shreds by the other group & they might send it back to us.

Rich: I'm still a little concerned about canvas, since that's all JavaScript.

Amelia: That's authoring guidelines issues. If a canvas should be an interactive document, it's up to authors to make sure there are DOM elements to interact with.

SVG Accessibility API Mapping Spec

https://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html

Fred: We were talking about items that served as hit regions & how the accessibility tree should be affected?

<fesch> https://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html#mapping_role_table

Amelia: I think we agreed that we weren't going to decide that right now, just leave it as an issue in the spec. I'd rather address some of the other issues which we may be able to fix.

Fred: Let's move on to the mapping table then.

Rich: The main change I made since last time we discussed is that instead of saying elements are mapped to a role of none, I explicitly say "no accessible object is created".

Amelia: One issue you've already noted is that, for most of these no accessible object is *ever* created & no role may be applied, but for a 1 or 2, such as iframe, no object is created by default but it can be if the author specifies a role.

Rich: I do have special text about that farther up.

Amelia: But maybe there should be text right there in the table, no accessible object is created unless an author-supplied role is provided. So it's easier to see it's different when scanning the table.

Rich: For iframe and the other elements adopted from HTML, it might be easiest to just refer to the HTML mapping spec.

Amelia: I think that makes sense. We want to make sure there is only one definitive reference.

Jason: For authors, they would really expect these elements to behave the same, and not worry whether an element is a child of <svg> or not.

Rich: What about the anchor tag? Is that going to be just a reference to HTML, or is it its own thing in SVG?

shepazu: I think it's it own thing in SVG, but there may be movements to harmonize.

Amelia: In yesterday's SVG call, we agreed to harmonize as much as possible, but there are going to be some differences for historical reasons.

<scribe> ACTION: Rich to edit Role mappings for elements borrowed from HTML (canvas, iframe, audio, video) to refer to the HTML mapping spec [recorded in http://www.w3.org/2015/10/09-svg-a11y-minutes.html#action01]

<trackbot> Created ACTION-1735 - Edit role mappings for elements borrowed from html (canvas, iframe, audio, video) to refer to the html mapping spec [on Richard Schwerdtfeger - due 2015-10-16].

Jason: And maybe look into the anchor element and see whether it's appropriate to do the same for that. Possibly after the SVG spec has been updated.

Amelia: I'm the one tasked with updating the SVG spec, so I'll look at the accessibility issues at the same time.

Rich: The other roles we might want to discuss are text and use.

Fred: We've received suggestions that text and tspan should have the default role of "text" instead of "group".

<richardschwerdtfeger> http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#html-element-role-mappings

Amelia: The concern, though, is that this is very different from other uses of the text role. It's purpose is for non-text content to be marked up as text, where the ARIA alternative text replaces the child content (usually an image or icon characters).
... E.g., if you add a tooltip in addition to a text label, it would probably be non-intuitive if the tooltip replaces the readable text content.

Rich: I've just looked up the HTML mapping for <p>. Most of the APIs have roles for paragraph, even though there isn't a specific ARIA role.

Amelia: So we could use that in our mapping, just skip over the gap in ARIA and describe the API mappings.

Rich: I could just copy this text in.

Fred: What about the "text" role, how would that be mapped?

Rich: It would really depend on the API, whether there is anything you can map it to.
... Can we at least add an issue to the spec?

Amelia: We already have a note there, saying additional work is required to figure out how best to map to the platform APIs.

Jason: Another issue I discovered, in the SVG spec it allows structured content in title and desc with other namespace elements such as XHTML. Sometimes, descriptions really need to be structured, and I would like to see this supported in ARIA.

shepazu: I second that. It came up a lot when working on data visualizations. I would like to allow <tspan> inside title and desc.

Amelia: The SVG 1 approach was just to allow HTML content within title and desc. But that was based on the assumption that screen reader users would be accessing the document through text-based HTML web browsers. Right now the spec doesn't really describe how it should behave in modern browsers.

Fred: Is there any other way to add metadata except through title and desc.

Amelia: There is a <metadata> element, but again it does not have a specific accessibility behavior. It's mostly used for content you want to include in the file but not have accessible to users.

shepazu: E.g., licensing information.

Fred: Jason, so you don't think the current spec is sufficient?

Jason: The SVG content model is sufficient, it allows all this content inside title and desc. But we need to figure out how the ARIA spec should handle this. If you have structured content, we don't want this to be flattened into a single string.

Amelia: This has been brought up by others. It would be really nice to have navigable, structured descriptions.

shepazu: One thing to clarify, although the existing spec describes content from other namespaces, going forward we would have to work in an HTML 5-compatible way, rather than talking about namespaces

Amelia: Basically, would have to clarify that the namespaces in question are only SVG and HTML, and in an HTML document. The HTML 5 parser already accepts HTML elements inside title and desc.

Rich: If we get these last few edits done this week, does anyone have a problem with then publishing a heartbeat draft?

Doug: There's a moratorium on publishing starting Oct 20, because of TPAC.

Amelia; Next call is the 16, would there be enough time?

Doug: And remember, we're a joint task force, we can't resolve to publish ourselves. We need resolutions from the two working groups.
... Can we at least send out some emails, letting people know that we intend to publish an update? And then it also depends on how much cleanup work is required on the document.

trackbot, end telcon

Summary of Action Items

[NEW] ACTION: Rich to edit Role mappings for elements borrowed from HTML (canvas, iframe, audio, video) to refer to the HTML mapping spec [recorded in http://www.w3.org/2015/10/09-svg-a11y-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/10/09 15:06:32 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/, which ignores all namespaces./, rather than talking about namespaces/
Succeeded: s/Oct 20/Oct 20, because of TPAC/
Found Scribe: AmeliaBR
Inferring ScribeNick: AmeliaBR
Default Present: Fred, AmeliaBR, chaals, Rich_Schwerdtfeger, shepazu, LJWatson, Jason
Present: Fred AmeliaBR chaals Rich_Schwerdtfeger shepazu LJWatson Jason
Regrets: Chaals

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Got date from IRC log name: 09 Oct 2015
Guessing minutes URL: http://www.w3.org/2015/10/09-svg-a11y-minutes.html
People with action items: rich

[End of scribe.perl diagnostic output]