W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2006

more Draft comments on Compound Document by Reference Framework 1.0 - Last Call

From: Jim Allan <jimallan@tsbvi.edu>
Date: Tue, 24 Jan 2006 13:23:41 -0600
To: w3c-wai-ua@w3.org
Message-id: <HDEAKIPKOHBCMDILOOPNCEFNEMAB.jimallan@tsbvi.edu>

Please add comments as necessary.

Commenting on http://www.w3.org/TR/2005/WD-WICD-20051219/

1.1	Scope - http://www.w3.org/TR/2005/WD-WICD-20051219/#scope
In the description of the profiles the following items are listed:
1 Content author/provider has exact control of the presentation, including
fonts, layout, color, etc.
2 Layout adaptation: layout can be based upon device characteristics -
screen size, color depth, resolution, orientation.
3 Presentation can be customized to reflect a brand or user's personality.
<uawg> first bullet: this can be overridden by the user through system
settings, browser controls, and user css overrides. Correct?
Second bullet: this includes user system settings. Correct?
Third bullet: would like to add “and needs” after “personality”
</uawg>

3. Scalable Child Elements
http://www.w3.org/TR/2005/WD-WICD-20051219/#scalable-child-formats
 <uawg>
We agree with the requirements for functions user agents must support.
On reading this section, we hoped to find something about the user being
able to scale the destination box.
For example: a user has default font size set to 18 points. An svg element
with fixed size (100x100) is referenced in a document. The default font size
causes the information to expand behind the bounding edge of the svg
element. The user must now focus on the svg and scroll within the svg.
</uawg>

6.1 Focusable Child Elements
http://www.w3.org/TR/2005/WD-WICD-20051219/#focus-management
<uawg> We agree with the requirements user agents.

“Child-specific functionality should be restricted to preserve the author's
intent. Should element specific functionality be desired, the element must
advertise itself as being focusable or implicitly made focusable by a user
agent.”

There seems to be a conflict here. First you say child-specific
functionality should be restricted. Then, you say “should functionality be
desired, the element must advertise itself as being focusable or implicitly
made focusable by a user agent.” By default the user agent should make all
child elements focusable, so when the user desires specific functionality it
is available. From an accessibility perspective, while the user agent should
respect the author’s intent, the user should be able to override that
intent.
</uawg>
6.3.2 One Dimensional Focus Navigation (Linear, Focus Ring, Tab)
http://www.w3.org/TR/2005/WD-WICD-20051219/#focus-nav-one-dim-linear

<snip>
XHTML and SVG have methods for linear one dimensional focus traversal. XHTML
provides a default traversal order, and allows it to be changed with the use
of tabindex attribute within one XHTML document. SVG's provides the
focusNext and focusPrev elements which may be used to provide similar
functionality within an SVG document. However, neither of these methods can
be used when XHTML and SVG are combined. Therefore in the case of a WICD
document by reference, combining XHTML with SVG, some alternate form of
navigation is required.

<uawg> This is indeed a problem. Perhaps, in a “WICD document by reference,
combining XHTML with SVG”, the user agent should default to one-dimensional
focus transversal based on source code order.

Tabindex and focusNext/focusPrev each have inherent accessibility problems,
mostly confusing the user as to the next/previous element that will receive
focus. Tabindex may take the user on an author defined path through
focusable content and then through the remainder of the focusable content
that was not part of the author defined path. The user can traverse this in
reverse order also, so in this respect it is consistent.
focusNext/focusPrev allows the author to define 2 distinct paths, separate
from the source code order. For example, the content has 6 focusable
elements. Each can have a unique focusNext and a unique focusPrev. In the
list below the first element is the focusable element in source code order,
the second item preceded with an “n” designates the focusNext order, the
third item preceded with a “p” designates the focusPrev order

1 – n2 p6
2	– n4 p3
3	– n1 p5
4	– n3 p2
5	– n6 p1
6	– n5 p4

so following the source path the user would proceed  1-2-3-4-5-6
if the author set focusNext, starting at element 1, the path would be
1-2-4-3-1 and loop from there.
If author set focusPrev, starting at element 1, the path would be
1-6-4-2-3-5-1.

Jim Allan, Webmaster & Statewide Technical Support Specialist
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
---> Share to Win!! <---
Received on Tuesday, 24 January 2006 19:21:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:51:32 GMT