W3C home > Mailing lists > Public > public-cdf@w3.org > February 2007

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

From: Chris Lilley <chris@w3.org>
Date: Thu, 1 Feb 2007 15:22:55 +0100
Message-ID: <1537578393.20070201152255@w3.org>
To: Al Gilman <Alfred.S.Gilman@IEEE.org>
Cc: public-cdf@w3.org, wai-liaison@w3.org

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?

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.
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.

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).

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)?

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.

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
  
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)

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.

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."

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.

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.

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."

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?

a) An icon of a sun with a happy smiling face
b) A map of all the ATMs in Tokyo
c) An image showing the front covers of the three books you were about
to buy, with the text "Your current selection"

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
Received on Thursday, 1 February 2007 14:23:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:10:41 GMT