Re: PF group comments on WICD and CDR last call working drafts

I've tried to respond where a response is clear; quite a few of these points
are in the "let's talk" category, however.

[details inline below]

At 3:22 PM +0100 1 02 2007, Chris Lilley wrote:
>Hi Al,
>
>I took an action to respond to the comments on WICD Core sections 3,4
>5 and 10. Other parts of your message will be replied to in other
>responses.
>
>On Friday, January 19, 2007, 7:58:18 PM, Al wrote:
>
>AG> WICD Core 1.0
>
>AG> Section 3.2.1
>AG> * No text equivalent in example
>
>Would adding
>
>  <p>Text equivalent here</p>
>
>as a child of object respond to your comment?

It would respond; but let's try a little harder.  Consider something like:

<change>
<from>
      <object data="icon.svg" type="image/svg+xml" width="100%">
        <param name="render" value="static" />
      </object>
</from>

<to>
      <object
          data="http://librsvg.sourceforge.net/images/librsvg-header.svg"
          type="image/svg+xml" width="100%">
        <param name="render" value="static" />
        <h1><span class="alt4icon">librsvg</span> Free, Open Source,
           SVG Rendering Library </h1>
      </object>
</to>

>AG> * Clarification of the difference between "static" and "frozen"
>AG> rendering?
>
>The specification says:
>
>   "The terms static and dynamic have the same meaning as in SVG. The
>   term frozen implies a single conversion to a raster image."
>
>These terms are defined here (yes, they should be hyperlinked)
>
>http://www.w3.org/TR/SVGMobile12/conform.html#ConformingSVGViewers
>
>Note that static includes hyperlinking
>http://www.w3.org/TR/SVGMobile12/feature.html#Hyperlinking
>but not animation. Dynamic includes (as well as hyperlinking)
>animation, video, audio, discard (for streaming) and so on.
>
>The WICD Core specification also says
>
>   "The term frozen implies a single conversion to a raster image."
>
>Therefore, a static rendering has no animation, audio, video but may
>have hyperlinks; its also zoomable.
>
>A frozen rendering is a one-shot, client-side rasterisation. Its
>almost the same as sending a raster image from the server, except that
>
>a) The client will render it at a suitable size (small for small
>screens, larger for larger ones, depending on the layout of the html
>page)
>b) Any system-language preferences will take effect when it is
>rendered, so if the SVG contains multiple linguistic alternatives, the
>users first-choice language will be used if available
>c) Its likely to be faster to download.
>
>For a frozen rendering, the client is likely to dispose of the
>original svg afterwards. The text alternative in the object element
>(see above) is more likely to be useful as an accessibility helper.

This sounds like an accessibility hole.  If we get people to use SVG
icons so text content is sent as text data and not image data,
it's not nice to throw the baby away in the process of this down-shifting
right at the client.  Hope we can talk about this one.

>Note that the helper application can reliably distinguish frozen,
>static and dynamic cases because the attributes are right there in the
>markup.
>
>AG> * Why are links in "static" and "frozen" not selectable, this would
>AG> be very useful to people with disabilities who may need the "static"
>AG> or "frozen" state to activate the link
>
>It sounds like what you are asking for is to pause a dynamic SVG. This
>is already possible.

That's good.

>A static svg has nothing to pause (it has no animation). A frozen SVG
>is a one-time raster image and has no links to activate.
>
>AG> Section 3.2.2
>AG> * Need to specify a keyboard model for activating interactive
>AG> elements in sprites
>
>(Assuming you meant 3.2.3  Scalable Overlay Objects (Sprites))
>
>Why would this be different to any other content? Its simply styled
>differently (CSS relative and absolute positioning, CSS z-order).

Maybe we can talk about this one?

>AG> Section 3.2.3
>AG> * The use of transparency can be a problem for people with visual
>AG> impairments or visual processing disabilities.   There needs to be a
>AG> way for users to configure the user agent to render the objects
>AG> separately and to restyle content to meet their perceptual needs.
>AG> For example rendering content separately in document order using a
>AG> high contrast stylesheet.
>
>The WICD Core spec says (in section 3.2.3)
>
>   "Any transparent areas in the Overlay Object and in the XHTML root
>   document must allow the layer behind to be visible."
>
>Are you arguing that it is better to have the overlaid object
>completely obscure elements underneath?
>
>Or are you arguing that there is a need to style the presentation
>without relative or absolute positioning (which can already be done
>with a user style sheet)?

Perhaps a user stylesheet would allow the user to un-bundle the layers
and eliminate background interference.  But hopefully we can talk
about this a bit.  The key is "will the document meet the content
guideline of making sense if rolled out in 'document order'?"

>or are you referring to section 3.3.3 Transparency?
>
>AG> Section 4.0
>AG> * No requirements for keyboard support for moving keyboard focus in
>AG> and out of objects (Maybe Section 6??)
>
>Section 4 is about child formats. As you note, section 6 is about
>focus handling.

OK, redirected to Section 6.

>
>AG> Sections 4.2 and 4.3
>AG> * Two separate standards for support for audio and video "pause",
>AG> "start" and volume control,
>
>Yes, XHTML 1 and SVGT 1.2 are separate standards and allow different
>degrees of control over timed elements.
>
>In SVG 1.0 and 1.1, timing was provided by the SMIL timing model.
>There were no time containers; the entire document had a single
>timeline. Comments from WAI noted that this did not allow pausing of
>individual elements. After discussion of the SMIL timing model with
>WAI, SVG responded that this was a limitation in SVG 1.1 and would be
>corrected in SVG 1.2 by using time containers.
>
>AG> in XHTML the user will have no control
>
>Correct.
>
>AG> and in SVG there is at least an option for users to have control
>
>'at least an option' is not really correct.
>
>   "A Conforming SVG Viewer must conform to the Priority 1
>   accessibility guidelines defined in [UAAG], and should conform also
>   to Priorities 2 and 3."
>   http://www.w3.org/TR/SVGMobile12/conform.html#ConformingSVGViewers
>
>
>Please see the priority 1 guideline
>   4.4 Slow multimedia (P1)
>   http://www.w3.org/TR/UAAG10/guidelines.html#tech-slow-multimedia

Thank you for clarifying that.

>AG> * Users need control over playing
>AG> * Users should have an option to have a player with the controls
>AG>   play audio
>
>XHTML1 should have timing. However, it does not, nor is CDF able to
>perform the rather substantial modifications to XHTML 1 to add it.
>
>Thus, as befits a specification about integrating different formats,
>CDF says what facilities each format provides.
>
>Authors can make use of this information. For example, if it is
>desired to play some audio, wrapping this up in an SVG rather than
>linking to it from the HTML allows the audio to be paused and
>restarted.
>
>AG> 4.4 Child content accessibility guidelines
>AG> * "For accessibility, conforming WICD Core 1.0 user agents must
>AG> provide the option of pausing, rewinding, or stopping video. See
>AG> section 3.2 of [User Agent Accessibility Guidelines 1.0]."
>
>AG> needs to be changed to
>
>AG> "For accessibility, conforming WICD Core 1.0 user agents must provide
>AG> the option of pausing, rewinding, or stopping audio and video. See
>AG> Checkpoint 4.5 of [User Agent Accessibility Guidelines 1.0]."
>
>Yes. Sorry about the copy-paste error introduced by the editor; we
>will fix this one (and the other instances where the wrong part of
>UAAG was referenced)

Thanks.

>
>AG> * A section should be included on user control of Volume, see UAAG
>AG> 1.0 Checkpoints 4.7 and 4.8
>
>Agreed. How about
>
>    "For accessibility, conforming WICD Core 1.0 user agents must
>    provide the option of global control of volume. See Checkpoint 4.7
>    of [User Agent Accessibility Guidelines 1.0]. For audio in SVG,
>    they must also provide the option of independent volume control of
>    different audio sources. See Checkpoint 4.8 of [User Agent
>    Accessibility Guidelines 1.0]"
>
>The second part is already required by SVGT1.2, but it does no harm to
>echo that requirement (and test for it) here.

Sounds good.

>AG> Section 5 Hyperlinking
>AG> * Again support text equivalents in code examples
>
>The code example links to an SVG which consists entirely of an
>svg:text element. Why would this need a 'text equivalent'?
>
>AG> * Expected behavior or user agents in providing the alternatives for
>AG> selecting links
>
>We did not understand this point, can you rephrase? Links in both
>XHTML 1 and SVGT1.2 are inline, simple links with only a single
>target. There is no inline, compound link functionality (although SVG
>Full 1.2 plans to add this).
>
>AG> * Moving keyboard focus into and out of OBJECT elements (Section 6)
>
>(Assuming this is a reminder that this is covered in section 6)
>
>AG> Section 6 Focus Handling
>AG> * Keyboard support is very important for accessibility
>
>Yes, we agree (at least, for those devices that have them). Is that a
>general statement, or  a specific comment? The WICD Core spec says
>
>   "WICD compliant user agents must provide the ability for users with
>   a keyboard or joystick input device (and without a pointing device),
>   to navigate to any focusable element in the root document and all of
>   its descendants."

That is too easily misread to mean that "and without a pointing device"
is part of the condition.  We need to strike the parenthetical from the
specification clause.

The accessibility requirement is that even when a pointing device is
present, there must be a way to get there with discrete inputs, from
the keyboard, keypad or an emulator for those devices.

>AG> * Need to make sure there is keyboard support for ARIA techniques for
>AG> interactive elements
>
>The CDF WG would like more detail on ARIA to be able to understand
>this comment.

PFWG: I will need help clarifying this; I presume that script handling of
keyboard inputs is what is implied.

>AG> * When authors set "focusable" to "skip" can the user interact with
>AG> any of the skipped content, like with a pointing device?
>
>Yes, a pointing device allows random access to any focussable content,
>while keyboard access is sequential (and thus, troubled by long
>lists).
>
>So if we expand the example in the spec to
>
><p><a href="whatever">Link one</a></p>
><object data="static-icon.svg" type="image/svg+xml" width="50%" >
>   <param name="focusable" value="skip" />
></object>
><p><a href="whatever">Link two</a></p>
>
>then the markup allows the user to move from link one to link two in a
>single step. This might be useful if static-icon.svg had, for example,
>a few hundred links. Without skipping, the user would ned to get past
>all of them, one at a time.

Use TABINDEX="-1" instead.  Don't introduce a different way to do the
same thing.

>AG> NOTE: If users can still interact with pointing devices or some other
>AG> interface then the user must have the ability to override author
>AG> setting to use the keyboard to navigate content.
>
>The WICD Core specification says:
>
>   "In some situations, a user agent may still allow the user to focus
>   on a child element which was removed from focus traversal. For
>   instance, a user agent may allow a user to focus on a static SVG
>   image for the purpose of saving it or interacting with it in other
>   ways."

What DOM support is there, here?  Pardon my ignorance.

My impression is that elements removed from the tabbing sequence
with TABINDEX="-1" can be focused
a) with a pointer event
b) by scripts using DOM methods.  c.f. SVGSVGElement.setFocus
http://www.w3.org/TR/2006/CR-SVGMobile12-20060810/svgudom.html#svg__SVGSVGElement_setFocus

PFWG:

Do we afford more in our profile of XHTML 1.1?  What do we expect?

>AG> * Need concepts of "headers" or "sections" within compound documents
>AG> with support for keyboard navigation
>
>The CDF WG was unable to understand this comment. Given the following
>three svg children, where would the headers and sections be?

I don't understand:  I don't see how the collection of these three
children would be composed as a compound document.  Or are
these children in different contexts?

>
>a) An icon of a sun with a happy smiling face

That's pretty atomic.  The icon may be a header, however.  Or just
the iconic representation of a fair-weather forecast, a value from
an enumeration type of weather condition summary terms.

>b) A map of all the ATMs in Tokyo

This map would have a title and a legend (a.k.a. key).  The whole map
would be a section and the title of the map would be the header for
that section.  The legend would be a (child) sub-section of the map
section and there would be a header announcing that this was the
legend (or key) for the coding scheme (colors and icons) used in the
map.

>c) An image showing the front covers of the three books you were about
>to buy, with the text "Your current selection"

The collection would be a section and the "Your current selection a
header.  Normally in a shopping site there would be a lot more along
with the cover images, not just the cover images.  The tree structure
would flow from

- collected selections
-- selection 1
--- 'remove' checkbox 1
--- cover image 1
--- prose citation 1
--- item price 1
-- selection 2
...
-- selection 3
...


Personal remark: I think we need to talk about this some more within PF.
We have yet to developed worked examples of WAI-ARIA annotated
SVGs and it's not clear that the combined use of svg:title and aaa:labeledby
with the possible addition of aaa:owns won't handle this handily.


>AG> Section 10
>AG> * Support for users supply their own style sheet for rendering
>AG> content is not addresses.  For example someone with a visual
>AG> impairment or visual processing disability could define their own
>AG> style sheet for rendering content and would want disable author
>AG> styling and use their own style sheet.  How is this important issue
>AG> addressed in the specification?
>
>Its not addressed, no, as it does not add any other conformance
>criteria beyond those of CSS (unlike the three parts of section 10,
>which do add additional requirements).
>
>CSS already provides for user style sheets. CDF does not alter that.
>
>Thanks for your comments, please get back to us where clarification
>was requested and also let us know if our suggested text was ok, or
>if we have not fully responded to your points.
>
>
>
>--
>  Chris Lilley                    mailto:chris@w3.org
>  Interaction Domain Leader
>  Co-Chair, W3C SVG Working Group
>  W3C Graphics Activity Lead
>  Co-Chair, W3C Hypertext CG