Minutes, 9 October 2015 SVG Accessibility Task Force TelCon from Amelia Bellamy-Royds on 2015-10-09 (public-svg-a11y@w3.org from October 2015)

From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
Date: Fri, 9 Oct 2015 11:14:35 -0400
To: SVG-A11y TF <public-svg-a11y@w3.org>
Message-ID: <CAFDDJ7yEZNWnLFfQw0Pf+5m5VmVu2n-X35ijPhWNczkpm_cZ+w@mail.gmail.com>

Formatted minutes available here:
http://www.w3.org/2015/10/09-svg-a11y-minutes.html

Plain text pasted below:
______________________________________________

[1]W3C

[1] http://www.w3.org/

- DRAFT -

SV_MEETING_TITLE

09 Oct 2015

See also: [2]IRC log

[2] http://www.w3.org/2015/10/09-svg-a11y-irc

Attendees

Present
Fred, AmeliaBR, chaals, Rich_Schwerdtfeger, shepazu,
LJWatson, Jason

Regrets
Chaals

Chair
Fred

Scribe
AmeliaBR

Contents

* [3]Topics
1. [4]SVG Accessibility API Mapping Spec
* [5]Summary of Action Items
__________________________________________________________

<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>
[6]https://www.w3.org/WAI/PF/Group/track/actions/1733

[6] 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).

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.

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

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

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

[7] 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>
[8]https://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html#mapp
ing_role_table

[8] 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
[9]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>
[10]http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#ht
ml-element-role-mappings

[10] 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
[11]http://www.w3.org/2015/10/09-svg-a11y-minutes.html#action01
]

[End of minutes]
__________________________________________________________

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

[12] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[13] http://dev.w3.org/cvsweb/2002/scribe/

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 [14]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/

[14] 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, LJ
Watson, 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: [15]http://www.w3.org/2015/10/09-svg-a11y-minutes.
html
People with action items: rich

[15] http://www.w3.org/2015/10/09-svg-a11y-minutes.html

[End of [16]scribe.perl diagnostic output]

[16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Received on Friday, 9 October 2015 15:15:09 UTC