See also: IRC log
scribenick LJWatson
Title: SVG A11y TF telecon
<fesch> Rich has some an issue having to do with title and describedby in the SVG 2 spec and accessibility
<fesch> http://www.w3.org/Graphics/SVG/WG/track/actions/3728
<fesch> https://svgwg.org/svg2-draft/struct.html#DescElement
<fesch> look at issues 24 and 25
<fesch> The title attribute represents advisory information for the element, such as would be appropriate for a tooltip.
<fesch> HTML5 link: http://www.w3.org/TR/html5/dom.html#the-title-attribute
<fesch> descriptive element
<fesch> An element which provides supplementary descriptive information about its parent. Specifically, the following elements are descriptive elements: ‘desc’, ‘metadata’ and ‘title’.
<fesch> ‘desc’
<fesch> Categories:
RS: Spec text (2nd link) is too
strong. Says authors should use <title>. Ok for SVG 1.1,
but not for 2.0.
... What do we want authors to do with <title> and
<desc>?
<fesch> Authors should always provide a ‘title’ child element to the outermost svg element within a stand-alone SVG document.
<richardschwerdtfeger> Authors should always provide a ‘title’ child element to the outermost svg element within a stand-alone SVG document. The ‘title’ child element to an ‘svg’ element serves the purposes of identifying the content of the given SVG document fragment.
LW: Why is it too strong for 2.0?
RS: It translates to a visual
tooltip, and that isn't desireable in every situation.
... Think we need to provide guidance, but requiring
<title> is not needed.
ABR: That's not what the spec
text is saying.
... This is document title, not SVG title.
RS: If a label were provided could the UA create a tooltip?
ABR: Don't know. Doc title doesn't show up as a tooltip though.
FE: Worry that diff between doc and other title is too subtle.
RS: With harmonised DOM, it's
just a container that may/may not have semantic value.
... For <title>, with exclusion of SVG container, what
should we be doing?
ABR: Author expectation is that
it'll be used as tooltip. We should say it should be available
(some way) to all users.
... Current text is: UA may display <title> as tooltip,
but acknowledge that alternative presentations are also
possible.
RS: If you don't have text that's
visible/obvious, some alternative text should be made available
to all users.
... Could take a pass at drafting something for this.
JW: It's an <svg>, which
means it should be rendered by the UA in some way.
... If not there should be some way to access it.
<richardschwerdtfeger> http://www.w3.org/TR/html5/dom.html#the-title-attribute
<richardschwerdtfeger> The title attribute represents advisory information for the element, such as would be appropriate for a tooltip. On a link, this could be the title or a description of the target resource; on an image, it could be the image credit or a description of the image; on a paragraph, it could be a footnote or commentary on the text; on a citation, it could be further information about the source; on interactive content, it could be a label for, or
<richardschwerdtfeger> instructions for, use of the element; and so forth. The value is text.
JW: Giving SVG container it's own title would not be good. Don't want it to have it's own identity necessarily.
RS: Should we try to harmonise
with the ^^ text?
... Want me to take a pass at rewriting that text?
+1
<fesch> +1
JW: Yes, but would like to see point about if there is no label in content then importance of <title> increases.
FE: Talking about stand-alone SVG doc, need to highlight that.
ABR: Question - if you have top level title in SVG in HTML doc, I think all browsers ignore it except for a11y purposes.
JW: Don't think tooltip is correct rendering for <title. on doc.
ABR: Doc level/stand-alone titles should be made available. Titles that are children of graphics content should be made available, possibly as tooltip or through alternate rendering.
<AmeliaBR> Demo of top-level title vs tooltips in inline SVG: http://fiddle.jshell.net/z3jfprta/
<richardschwerdtfeger> ACTION: Rich Author new text for the <title> element in SVG [recorded in http://www.w3.org/2015/02/13-svg-a11y-minutes.html#action01]
<trackbot> Created ACTION-1582 - Author new text for the <title> element in svg [on Richard Schwerdtfeger - due 2015-02-20].
FE: We have a wiki page.
<AmeliaBR> https://www.w3.org/wiki/SVG_Accessibility
FE: Could start to walk through on the call?
JW: Understanding it by way of disability is useful for ensuring we capture everything, but it isn't a good way to think about SVG and how we design in accessibility.
LW: We should gather requirements based on disability, then look for solutions/appropriate guidance.
FE: Can we gather it all in the wiki?
LW: Don't think we should do both at once. Should start with requirements/use cases.
JW: We're not always aware of the
capabilities of some technologies.
... Do think there will be possibilities that haven't been
explored. Haptic or sonification solutions for example.
FE: If we used a media queries
type of thought we could plan for technologies we don't yet
have.
... Flags for different things.
JW: Yes, and ARIA could be useful in the sense it'll point out what the important features are.
FE: We should focus on requirements and use cases, then look at accomodations?
+1
ABR: Makes sense.
... Then looking for solutions with common benefits.
FE: Looking at blind users...
JW: Screen readers can be used
with braille display, input could be keyboard or touch.
... Research into haptics on touch devices. Tactile display
research is ongoing too.
... Question is how do you support each of these?
FE: What are the requirements?
LW: Think we need to keep the requirements simple. A person who is blind and unable to see SVG content needs to be able to access and understand the content in a way that is meaningful with their chosen AT.
FE: Doesn't it matter what the
SVG is?
... Technical drawing, map, blueprint etc.
JW: It guides the solution. We don't have a measure of it yet, but there is the issue of complexity.
FE: Removing noise from data is important.
LW: This is where use cases will help. For example a blind student studying economics needs to access a datamap of historical financial information.
FE: We will need 20+ uses cases for every disability.
LW: Wouldn't think so - need to find use cases that typify key issues, not document every one.
JW: Good idea to think about large numbers of use cases, but in the doc just include those that illustrate different requirements.
LW: Right.
FE: Do we have requirements for Deaf users?
RS: There are audio/video tags in
SVG.
... Likely to be authoring guidance not spec guidance.
LW: I can put together requirements and uses cases for blind users and circulate to list?
<scribe> ACTION: Léonie to put together use cases and requirements for blind users. [recorded in http://www.w3.org/2015/02/13-svg-a11y-minutes.html#action02]
<trackbot> Created ACTION-1583 - Put together use cases and requirements for blind users. [on Léonie Watson - due 2015-02-20].
<scribe> ACTION: Amelia to put together use cases and requirements for cognitive and mibility impaired users. [recorded in http://www.w3.org/2015/02/13-svg-a11y-minutes.html#action03]
<trackbot> Error finding 'Amelia'. You can review and register nicknames at <https://www.w3.org/WAI/PF/Group/track/users>.
<scribe> ACTION: Fred to put together use cases and requirements for Deaf and hard of hearing people. [recorded in http://www.w3.org/2015/02/13-svg-a11y-minutes.html#action04]
<trackbot> Created ACTION-1584 - Put together use cases and requirements for deaf and hard of hearing people. [on Fred Esch - due 2015-02-20].
<AmeliaBR> ACTION: AmeliaBR to put together use cases and requirements for cognitive and mibility impaired users. [recorded in http://www.w3.org/2015/02/13-svg-a11y-minutes.html#action05]
<trackbot> Error finding 'AmeliaBR'. You can review and register nicknames at <https://www.w3.org/WAI/PF/Group/track/users>.
<scribe> ACTION: AmeliaBR to put together use cases and requirements for cognitive and mibility impaired users. [recorded in http://www.w3.org/2015/02/13-svg-a11y-minutes.html#action06]
<trackbot> Error finding 'AmeliaBR'. You can review and register nicknames at <https://www.w3.org/WAI/PF/Group/track/users>.
<richardschwerdtfeger> https://www.w3.org/WAI/PF/Group/track/products/17
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/UA may display/Current text is: UA may display/ Succeeded: s/uers/users/ Succeeded: s/guidacne/guidance/ No ScribeNick specified. Guessing ScribeNick: LJWatson Inferring Scribes: LJWatson Default Present: fesch, Jason_White, +1.512.238.aaaa, LJWatson, AmeliaBR, Rich_Schwerdtfeger, CharuP, Amy Present: fesch Jason_White +1.512.238.aaaa LJWatson AmeliaBR Rich_Schwerdtfeger CharuP Amy Got date from IRC log name: 13 Feb 2015 Guessing minutes URL: http://www.w3.org/2015/02/13-svg-a11y-minutes.html People with action items: amelia ameliabr fred l onie rich WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]