Comments from Charles McCathieNevile

Sent to the main MWBP list. I've already replied to some of the comments.



------- Mensaje Remitido -------
De: "Charles McCathieNevile" <chaals@opera.com>
A: "MWI MWBP Member List" <member-bpwg@w3.org>
Asunto: Comments on AccessibilityTF draft 0b
Fecha: Wed, 17 Oct 2007 20:02:27 +0200


On Wed, 17 Oct 2007 13:35:32 +0200, Alan Chuter <achuter@technosite.es>
wrote:

> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/drafts/ED-mwbp-wcag-20071017#use_case_tool

Hi, I think the tables should be seperate sections from the list of
checkpoints - it looked like I was in some kind of table notes when I was
actually b eginning the major substance of teh specification itself.

The following are comments on what the draft says about some specific best
practices: Each line of my comments is prefixed with "CMN:"

[THEMATIC_CONSISTENCY] Ensure that content provided by accessing a URI
yields a thematically coherent experience when accessed from different
devices

Refer to [THEMATIC_CONSISTENCY] to understand the Best Practice described
in this section.

How does it help especially users with disabilities?: no_added_benefit.

CMN: The browser sniffing applied by some sites and used to vary the
content can also impact the experience of users with disabilities.
Ensuring that while the specific detail may vary, the actual content
served will be consistent will minimise such impact.

[DEFICIENCIES] Take reasonable steps to work around deficient
implementations

Refer to [DEFICIENCIES] to understand the Best Practice described in this
section.

How does it help especially users with disabilities?: no_added_benefit.

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any
WCAG 1.0 provision.

[NAVBAR] Provide only minimal navigation at the top of the page

How does it help especially users with disabilities?: Implementing this BP
benefits users of screen magnifiers and others who have a restricted field
of vision as it ensures that they are more easily able to locate the main
content of the page. Users with a motor disability or who use the keyboard
for navigation will be able to view the main content of the page without
difficult scrolling.

Does it give me WCAG 1.0 compliance?: This BP deals with an aspect not
considered in WCAG 1.0, although it is related to 13.5, “Provide
navigation bars to highlight and give access to the navigation mechanism”.

CMN It also goes some of the way to providing the functionality required
by 13.6 Group related links, identify the group (for user agents), and,
until user agents do so, provide a way to bypass the group. (Having the
group at the bottom makes it easy to bypass by not going there.

[BALANCE] Take into account the trade-off between having too many links on
a page and asking the user to follow too many links to reach what they are
looking for

How does it help especially users with disabilities?: Users with motor
disability may special difficulty in using the keyboard or other device to
navigate between links. Users with cognitive disability may have
difficulty using| understanding| concentrating on large numbers of links.
Users with the disabilities described may benefit from this BP.

CMN: This also addresses a problem 13.6 was designed to solve of requiring
blind users to wade through a large number of links in order to find the
one they want. Given that people's mental models generally only hold 7±2
distinct objects [Magic number paper] then having to recall more than that
many links to choose the right one leads to serious inefficiency for blind
users.

[ACCESS_KEYS] Assign access keys to links in navigational menus and
frequently accessed functionality

How does it help especially users with disabilities?: Mobile devices are
not usually equipped with a mouse, and so users are in a situation similar
to that experienced by those who are unable to use one.

CMN: Should there be some more clarity here about who relies on keyboards
and why? I think this should state that the benefit is higher for users
when their browser lets them discover what access keys are assigned (some
do, some don't).

Does it give me WCAG 1.0 compliance?: Providing access keys are also
defined as necessary for form controls (not made explicit in the BP)

CMN: Why are "important ... form controls and groups of form controls" not
considered equivalent to frequently accessed functionality?

, this BP also ensures compliance with WCAG 1.0 checkpoint 9.5, “Provide
keyboard shortcuts to important links (including those in client-side
image maps), form controls, and groups of form controls”. If it is not
apparent from the content or shown by the device, provide a summary of
access keys used in content on a separate page.

CMN: This is a bit difficult, since access keys can (and in some cases
should) be reassigned by the device in ways the author cannot predict.

[LINK_TARGET_ID] Clearly identify the target of each link

How does it help especially users with disabilities?: Refer to WCAG 1.0
HTML Techniques: Link text.

Does it give me WCAG 1.0 compliance?: This BP goes some way to ensuring
compliance with WCAG 1.0 checkpoint 13.1, “Clearly identify the target of
each link”. However, to ensure accessibility it is important to understand
that the user may read (or hear) the links in a page as part of a list of
links without surrounding contextual information. For this reason it is
important that the link text not lose its meaning when read out of
context. Refer to WCAG 1.0 HTML Techniques: Link text gives more
information.

CMN: Given that the text of the requirements is exactly the same, surely
fulfilling this correctly is exactly the same. (I thought it was...)

[AUTO_REFRESH] Do not create periodically auto-refreshing pages, unless
you have informed the user and provided a means of stopping it

How does it help especially users with disabilities?: Auto-refresh is
especially confusing to users of screen readers. As the page is refreshed
a screen reader may begin reading the updated content again from the
beginning, causing confusion and preventing the user from ever reading the
whole page.

Does it give me WCAG 1.0 compliance?: As long as auto-refresh is not used,
this BP ensures compliance with WCAG 1.0 checkpoint 7.4, “Until user
agents provide the ability to stop the refresh, do not create periodically
auto-refreshing pages”. At the time of writing user agents do not allow
the user to disable auto-refresh (do they?).

CMN: Opera does. Do others? It can be done easily enough in a script
extension, so I would be surprised if they were not available for browsers
that don't do this natively.

[REDIRECTION] Do not use markup to redirect pages automatically. Instead,
configure the server to perform redirects by means of HTTP 3xx codes

How does it help especially users with disabilities?: Like auto-refresh,
using markup for redirection can confuse users, especially:
Users who have difficulty concentrating attention, who may become confused
when the content changes.
Screen readers may begin reading the page from the beginning, only to be
interrupted by redirect or auto-refresh.

CMN: People who read slowly may not have understood what is happening
before they have finished reading.

[PAGE_SIZE_USABLE] Divide pages into usable but limited size portions

Comment: Is the following true? Otherwise (no_added_benefit)

CMN: No, the working group did consider mobile content although didn't
talk about it a lot. But I think it is true that the requirements are very
closely related.

Does it give me WCAG 1.0 compliance?: This BP goes some way toward
complying with WCAG 1.0 checkpoint 12.3, “Divide large blocks of
information into more manageable groups where natural and appropriate”,
although in a way not contemplated in the guidelines (The working group in
1999 did not consider the mobile context). However the WCAG checkpoint is
much broader in scope, covering all usage contexts.

[CENTRAL_MEANING] Ensure that material that is central to the meaning of
the page precedes material that is not.

How does it help especially users with disabilities?: Putting the main
content first helps keyboard-only users whether in a mobile context or
not. I may also help users weith cognitive disabilities who have
difficulty locating the central information in a page full of navigation
links.

Comment: The following is debatable. Otherwise no_added_benefit.

Does it give me WCAG 1.0 compliance?: This BP corresponds to the spirit of
WCAG 1.0 checkpoint 12.3, “Divide large blocks of information into more
manageable groups where natural and appropriate”, although, like
[PAGE_SIZE_USABLE], in a way not contemplated in the guidelines. The WCAG
checkpoint is much broader in scope than the BP.

CMN: Also relates to WCAG 13.8

[GRAPHICS_FOR_SPACING] Do not use graphics for spacing

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any
WCAG 1.0 provision.

CMN: slightly related to WCAG 3.1

[COLOR_CONTRAST] Ensure that foreground and background color combinations
provide sufficient contrast

Does it give me WCAG 1.0 compliance?: This BP may ensure (using additional
criteria) compliance with WCAG 1.0 checkpoint 2.2 Ensure that foreground
and background color combinations provide sufficient contrast when viewed
by someone having color deficits or when viewed on a black and white
screen. However, the BP is concerned exclusively with unfavourable ambient
light, while WCAG is primarily concerned with colour blindness, which may
lead to different results.

CMN: It is also concerned with the ability of devices to display
contrasting colour in the first place.

[BACKGROUND_IMAGE_READABILITY] When using background images make sure that
content remains readable on the device

Does it give me WCAG 1.0 compliance?: This BP is related to WCAG 1.0
checkpoint 6.1, “Organize documents so they may be read without style
sheets”. If the content is not readable without a background image, this
checkpoint is not met.

CMN: Also relates to WCAG 2.2

[STRUCTURE] Use features of the markup language to indicate logical
document structure

Does it give me WCAG 1.0 compliance?: This BP ensures compliance with WCAG
1.0 checkpoint 3.5, “Use header elements to convey document structure and
use them according to specification” with no further effort.

CMN: Also WCAG 2.1, 3.6, 3.7, 5.1, 5.2, 6.1

[TABLES_LAYOUT] Do not use tables for layout

Does it give me WCAG 1.0 compliance?: If tables are not used for layout,
then WCAG 1.0 checkpoints 5.3, “Do not use tables for layout unless the
table makes sense when linearized” and 5.4, “If a table is used for
layout, do not use any structural markup for the purpose of visual
formatting”, do not apply.

CMN: 5.3 is actually met, not n/a, if there is no table for layout.

[OBJECTS_OR_SCRIPT] Do not rely on embedded objects or script

Refer to [OBJECTS_OR_SCRIPT] to understand the Best Practice described in
this section.

Does it give me WCAG 1.0 compliance?: This BP ensures compliance with WCAG
1.0 checkpoint 6.3 “Ensure that pages are usable when scripts, applets, or
other programmatic objects are turned off or not supported...”, but be
sure to follow the further guidance given in WCAG 1.0 and accompanying
techniques. Using onclick for script rather than onkey and onmouse event
handlers helps ensure compliance with WCAG 1.0 checkpoint 6.4, “For
scripts and applets, ensure that event handlers are input
device-independent”.

CMN: Also related to meeting 6.2

[MINIMIZE_KEYSTROKES] Keep the number of keystrokes to a minimum

How does it help especially users with disabilities?: While mobile devices
have input devices such as numeric keypads that are awkward to use for
text input. This BP is especially beneficial to users with limited
dexterity who find text input even more difficult. It is not related to
any specific WCAG 1.0 checkpoint.

Does it give me WCAG 1.0 compliance?: This BP does not correspond to any
WCAG 1.0 provision.

CMN: related to th functionality required by 9.5

[CONTROL_POSITION] Position labels so they lay out properly in relation to
the form controls they refer to

Refer to [CONTROL_POSITION] to understand the Best Practice described in
this section.

How does it help especially users with disabilities?: If controls are not
explicitly associated with their labels (as described in the
[CONTROL_LABELLING] best practice) screen readers use the position in
markup of the control and the label to determine the relationship.
However, for recent screen readers this is now unnecessary if there is
explicit association.

Does it give me WCAG 1.0 compliance?: This BP corresponds to WCAG 1.0
checkpoint 10.2 “Until user agents support explicit associations between
labels and form controls, for all form controls with implicitly associated
labels, ensure that the label is properly positioned”. While the BP is
concerned with reflowing and adapting content, WCAG is concerned to enable
screen readers to determine the association in the absence of an explicit
association in markup.

CMN: I think that is only one aspect of the concern in WCAG, and that the
overall concerns match mor closely than this explanation suggests.

Tip: Avoid nesting the control inside the label element as it is not
supported by user agents.

CMN: This is not accurate. There are *some* user agents which do not
support <label><input type="date"> The date</label>, but require that the
for/id pair is used <label for="date"><input type="text" id="date"> The
Date</label>.

cheers

Chaals



-- 
Alan Chuter
Accessibility Consultant
Technosite (Fundación ONCE)
achuter@technosite.es
www.technosite.es
Tel. +34 91 121 03 35
Skype: achuter1

If you are unable to reply to this message because of spam filter, try my  
alternative address achuter.technosite@yahoo.com.

Si no puede contestar a este mensaje por culpa del filtro de spam, intente  
con mi dirección alternativa achuter.technosite@yahoo.com.

Received on Thursday, 18 October 2007 12:42:49 UTC