[SVGMobile12] collected WAI Last Call comments

<note class="inTransmittal">

Please accept the comments in this message as
reflecting the rough consensus of the Protocols and Formats
Working Group on behalf of the Web Accessibility Initiative.

We don't claim to have understood all the details or
prospective uses of the format, nor do we claim that
all these comments are ready for a justDoIt instruction
to the editor.

We look forward to the opportunity to working with
you including real-time dialog to resolve these issues,
whether that winds up clarifying a problem or a
non-problem.

Al
/chair, Protocols and Formats WG

</note>


Baseline:
SVG tiny 1.2, url http://www.w3.org/TR/SVGMobile12/

<section>
<title>Some outdated language survives in the prose discussion of WAI 
docs.</title>

<quote cite=
"http://www.w3.org/TR/SVGMobile12/conform.html#ConformingSVGViewers">

"The Web Accessibility Initiative [WAI] is defining "User
Agent Accessibility Guidelines 1.0" [UAAG]. Viewers are
encouraged to conform to the Priority 1 accessibility
guidelines defined in this document, and preferably also
Priorities 2 and 3. Once the guidelines are completed, a
future version of this specification is likely to require
conformance to the Priority 1 guidelines in Conforming SVG
Viewers."

</quote>

<comment>

This statement seems to indicate that UAAG guidelines are
still under development.  It is not clear what "Once the
guidelines are completed, a future version of this
specification" is refering to UAAG or SVG.

</comment>

</section>

<section>
<title>Inline references to key UAAG sections.</title>

<topic>
While the blanket references in Appendix D are necessary
for completeness, the readers of this document will understand
what you mean in various inline remarks about what processors
should do if the pertinent sections of the UAAG10 are
directly referenced at key points in the text.  A few examples
follow.
</topic>

<quote class="changeFrom" cite=
"http://www.w3.org/TR/SVGMobile12/struct.html#DescriptionAndTitleElements">
For reasons of accessibility, user agents should always make the
content of the 'title' child element to the 'svg' element available
to users.
</quote>

<draft class="changeTo">
For reasons of accessibility, user agents should always make the
content of the 'title' child element to the 'svg' element available
at user option [UAAG10].
</draft>

<note class="linking">
The putative link target would here be the Conditional Content
Checkpoint and not the root of the document.
http://www.w3.org/TR/UAAG10/guidelines.html#tech-conditional-content
</note>

</section>

<section>
<title>Exemplify accessible use</title>
<comment class="general">
We are not satisfied that this document yet meets
the requirement to demonstrate accessible usage
in its examples.

The following few examples show roughly the kind of improvements
that should be made.  They are neither exhaustive nor for that
matter sufficient.  We would be glad to work with you on upgrading
the examples in response to this comment.

</section>


<comment cite="http://www.w3.org/TR/SVGMobile12/intro.html#defining">

The entity.svg example needs
<title>Smiley Face</title>
... within the 'g' element (excluding the background
square).  Excluding because of the prevalence of this icon as a
physical, pin-on button.

This 'g' would be a good home for a <meta> reference using the SKOS
vocabulary to associate this drawing with the Unicode smiley &x263A;
Since this is an icon with a common connotation, SKOS-ifying it with
some sort of a linkage to another representation of the same concept
in widespread use would be of benefit in serving symbol language
users and those with learning disabilities in general.

It would be reasonable to give the outer 'svg' a 'title' and lose
its 'desc' if you are concerned to be chewing up space.  The
smiley face is too clearly an idiom, a symbolic entity appealing
to a stable colloquial connotation, to pass up annotating the face itself.
</comment>

<comment>
Could not find where in the document it discusses user disabling play
of audios and videos. No matter, this provision where mentioned
should apply to the inhibition of animation as well and cite UAAG10
Checkpoint 3.2 at:
http://www.w3.org/TR/UAAG10/guidelines.html#tech-configure-multimedia
</comment>

<comment>
Examples in general use mouse-specific events.  This should be
upgraded in line with the intent-based event philosophy developed
by the HTML WG.
</comment>


<example>
<cite>
5.5 The 'desc' and 'title' elements
</cite>
<quote>
>From example 5_12.

<svg width="100%" height="100%" xmlns="http://www.w3.org/2000/svg"
     version="1.2" baseProfile="tiny">
     <desc xmlns:mydoc="http://example.org/mydoc">
       <mydoc:title>This is an example SVG file</mydoc:title>
       <mydoc:para>The global description uses markup from the
         <mydoc:emph>mydoc</mydoc:emph> namespace.</mydoc:para>
    </desc>
    <g>
    <!-- the picture goes here -->
    </g>
</svg>
</quote>
<remark>
Examples use an artifical arbitrary namespace.
While the point is there to be made that SVG
does not limit the markup used here, the
preponderance of example should use realistic
namespaces such as the mobile profile of XHTML.
</remark>
</example>
</section>

<section>
<quote cite=
"http://www.w3.org/TR/SVGMobile12/intro.html">

1.1 For accessibility reasons, if there is an original source document
   containing higher-level structure and semantics, it is recommended
   that the higher-level information be made available somehow, either
   by making the original source document available, or making an
   alternative version available in a format which conveys the
   higher-level information, or by using SVG's facilities to include
   the higher-level information within the SVG content.
</quote>

<comment>
<link rel="xhtml2:seeAlso" href="http://www.w3.org/TR/xag#cp2_11">
Good.  Thank you.
</comment>
</section>

<section>
<quote>
App D.4.2. Additionally, a Conforming SVG Authoring Tool must conform
to all of the Priority 1 accessibility guidelines from the document
"Authoring Tool Accessibility Guidelines 1.0" [ATAG] that are relevant
to generators of SVG content. (Priorities 2 and 3 are encouraged, but
not required for conformance.)
</quote>
<comment>
Good, this is the sort of explicit inclusion in the conformance requirements
that we have been asking for.
</comment>.
</section>

<section>
<quote class="changeFrom">
1.6  shape. A graphics element that is defined by some combination of
     straight lines and curves. Specifically: 'path', 'rect', 'circle',
     'ellipse', 'line', 'polyline', 'polygon'.
</quote>
<draft class="changeTo" >
1.6  shape. A graphics element that comprises a defined combination of
     straight lines and curves. Specifically any instance of the element
     types: 'path', 'rect', 'circle', 'ellipse', 'line', 'polyline', 'polygon'.
</draft>
<rationale class="forChange clarity">
The antecedent for 'specifically' is ambiguous without the change.
It could be interpreted as "specifically a combination of 'path', 
'rect', 'circle',
     'ellipse', 'line', 'polyline', 'polygon' elements."
</rationale>
</section>

<section>
<quote>
1.6 User agents include graphical desktop browsers, multimedia
   players, text browsers, voice browsers, and assistive technologies
   such as screen readers, screen magnifiers, speech synthesizers,
   onscreen keyboards, and voice input software.
</quote>

<comment>
suggest
<draft class="changeTo">
1.6 User agents include graphical desktop browsers, multimedia
   players, text browsers, voice browsers; used alone or
   in conjunction with assistive technologies
   such as screen readers, screen magnifiers, speech synthesizers,
   onscreen keyboards, and voice input software [UAAG10].
</draft>
The citation of UAAG10 is linked.
</comment>
<rationale class="forChange">
The Home Page Reader browser notwithstanding, many readers
will be confused if we use language that makes it sound as though
we think that an Assistive Technology (by itself) is a user agent.
It is much more of an OS extension and is part of the platform
on which the mass-market browser is used.
</rationale>
</section>


<quote>
6.4 ... An !important declaration within a presentation attribute
   definition is an error.
</quote>

<comment>
Nice to see.
</comment>


<comment class="new add">
8.3 path data

For semantic entities such as flowlines in flowcharts, how should
user information such as 'title' and 'desc' be associated with
complex paths?

How would you suggest that we get authors to observe this practice?

</comment>

<section>
<title>Relating text to structure</title>
<cite>
10.1 Introduction (text)
</cite>

<comment>
It is not clear how a User Agent or Assistive Technology is to
associate text that it finds with the structure of the scene
in the graphic depiction.

Diagrams often embed labels, but how is this semantic
relationship (of the label text to the conceptual object
labeled) to be recognized from the SVG representation?
</comment>

<cite>
10.11.2 The 'textArea' element
</cite>
<comment>
At last!
</comment>

<section>
<title>Media and alternatives</title>

How would authors use this notation to identify alternatives
for audio and video objects (as you see this notation being used)?

<comment

focusNext and focusPrev attributes.

See the example in 13.9.1 where it is possible to do this. A
nice feature to encourage would be a graphical means of setting this
within an authoring environment. This is a job for a person, not a
computer. Adobe would be a good starting point for this.

<cite>
13.9.2 Specifying navigation
</cite>
<comment>
This is a real step forward for accessibility!
</comment>

<comment>

The examples read as if all delivery contexts support pointer events.

The provision of alternatives to pointer events should be illustrated 
in the examples.

To what extent does this specification support a two-step identification of
user event handling with an intent-based event defined first and then 
bound in an
over-rideable way to a device-specific UI event?

</comment>

<comment>
<cite>
Section 16.
</cite>

If an element is animated, is there a way to provide
a static alternative other than the inital state of the
animation?

How can an AT perceive that a given animated
whatever is in the state of ongoing animation?
</comment>

<comment class="inPassing">

http://www.w3.org/TR/SVGMobile12/changes.html provides the change list
but only from the previous draft.  A comparison with the incumbent full
language might be more to the point for current users wanting
to use this version to go mobile.

</comment>

<history
class="originalPreparedBy">
--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk
</history>

Received on Friday, 27 May 2005 21:00:17 UTC