W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > November 2007

Your comments on WCAG 2.0 Public Working Draft of May, 2007 Resend

From: Gregg Vanderheiden <gv@trace.wisc.edu>
Date: Sun, 04 Nov 2007 00:37:58 -0500
To: 'Sofia Celic' <Sofia.Celic@visionaustralia.org>
Cc: public-comments-WCAG20@w3.org
Message-id: <000001c81ea4$dc1cbd80$0f6fa8c0@NC84301>

Dear Sofia Celic,

Thank you for your comments on the 17 May 2007 Public Working
Draft of the Web Content Accessibility Guidelines 2.0 (WCAG
2.0 http://www.w3.org/TR/2007/WD-WCAG20-20070517/). The WCAG
Working Group has reviewed all comments received on the May
draft, and will be publishing an updated Public Working Draft
shortly. Before we do that, we would like to know whether we
have understood your comments correctly, and also whether you
are satisfied with our resolutions.

Please review our resolutions for the following comments, and
reply to us by 19 November 2007 at
public-comments-wcag20@w3.org to say whether you are
satisfied. Note that this list is publicly archived. Note
also that we are not asking for new issues, nor for an
updated review of the entire document at this time.

Please see below for the text of comments that you submitted
and our resolutions to your comments. Each comment includes a
link to the archived copy of your original comment on
http://lists.w3.org/Archives/Public/public-comments-wcag20/,
and may also include links to the relevant changes in the
WCAG 2.0 Editor's Draft of May-October 2007 at
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20071102/

Thank you for your time reviewing and sending comments.
Though we cannot always do exactly what each commenter
requests, all of the comments are valuable to the development
of WCAG 2.0.

Regards,

Loretta Guarino Reid, WCAG WG Co-Chair
Gregg Vanderheiden, WCAG WG Co-Chair
Michael Cooper, WCAG WG Staff Contact

On behalf of the WCAG Working Group

----------------------------------------------------------
Comment 1: Prohibiting images of important text
Source:
http://lists.w3.org/Archives/Public/public-comments-wcag20/200
7Jun/0299.html
(Issue ID: 2128)
----------------------------
Original Comment:
----------------------------

Currently WCAG 2.0 allows the use of images of text. Some
user groups with low vision may miss important content where
text within images contains important information. This may
be because the user requires a particular visual presentation
of the content, such as a particular font size or combination
of foreground and background colours to be able to perceive the text.

WCAG 2.0 currently has an advisory technique for Success Criterion
1.4.4 of "Avoiding the use of text in raster images". We do
not feel this is sufficient at an advisory technique status.

If images of important text are allowed these user groups
would need to "turn images off" to be able to apply their
presentation needs to the text alternative. Here are some
problems with that:

- This is something most users would not know of, let alone
how to do it.

- In Internet Explorer (still the most common use browser)
the user would be required to make changes in the 'Advanced'
tab (in Internet
Options) to stop image downloads. Not many people are
comfortable making changes in the "Advanced" area of any
program. Also, the setting to display all of the text
alternative of an image would be required (again an
'Advanced' setting in IE).

- Image text alternatives do not necessarily render at the
same size as the surrounding text

- Viewing a page with image text alternatives potentially
results in content being shifted so as to confuse the visual
reading order; overlapping image text alternative with other
text in the page; and cropped image alt text; generally
making the content harder or impossible to read.

- users may not be able to change browser settings in some
circumstances (such as at their place of employment where
access to settings is prohibited or limited)

Another important area is that of accessing image maps. How
would a user accessing pages with images off necessarily know
of the presence of an image map, let alone be able to access
the map regions? Most browsers do not render the text
alternative for and outlines of map regions. This issue goes
beyond images of text so we are also submitting a separate
comment regarding image maps.

Proposed Change:
Add a success criterion at Level A or AA that prohibits use
of images containing important text.

We acknowledge that the success criterion may need to include
some exceptions, such as where the important text is already
provided as text, or where logos are concerned.

---------------------------------------------
Response from Working Group:
---------------------------------------------

We now have two SC dealing with this:

at Level AA we have
"1.4.5 Images of Text (Limited): When an accessibility
supported technology exists to achieve the visual
 presentation, text is used to convey information
 rather than images of text unless the image of
the text can be visually customized to the user's
requirements."

We have also at Level AAA:
"1.4.9 Images of Text (Essential): Images of text
are only used for pure decoration or where a
particular presentation of text is essential to
the information being conveyed."

----------------------------------------------------------
Comment 2: resizing of form controls
Source:
http://lists.w3.org/Archives/Public/public-comments-wcag20/200
7Jun/0396.html
(Issue ID: 2262)
----------------------------
Original Comment:
----------------------------

The current draft appears not to deal with ensuring form
controls can be resized along with changes in text size.

Forms are used on many sites but often the form controls do
not resize even when the text around them does. This can
result in a user with low vision being able to read the text
information for a form and the text labels, but not be able
to read the text in a drop-down box, check their own input in
a text field or to locate radio buttons and checkboxes.

Success criterion 1.4.4 (Visually rendered text can be
resized without assistive technology up to 200 percent and
down to 50 percent without loss of content or functionality.)
deals with the scaling of text size. It doesn't specify
whether this applies to text-based form controls. If so, this
needs to be clarified with additional text in the
Understanding document and the addition of applicable
sufficient techniques.

However, there are also non-text-based form controls - radio
buttons and checkboxes - that are required to resize along
with changes in text size. This may mean another success
criterion is required to cover all types of form controls.

In the event that form controls are considered technology
specific, a more generic success criterion would be required.

Proposed Change:
Add a success criterion that covers the resizing of form controls.

---------------------------------------------
Response from Working Group:
---------------------------------------------

We think this should be a User Agent guideline, and just an
advisory/repair  technique in WCAG. If text is big enough to
be useful, it will be so big that designers won't want to use
it. If some elements scale and others don't, the layout is
likely to get messed up.  Whether that's a barrier or not
depends on whether content or functionality is lost, but it's
much eaiser to get this right when everything scales such as
a user agent zoom, commercial AT, or operating system
magnification. However we have added a sufficient technique
for 1.4.4: "Specifying the size of objects in terms of the font size"

By the time WCAG reaches recommendation, we expect Zoom
features in browsers will become more and more used among
people who need moderate amounts of zoom. We realize that
this is not perfect, but we think it is the best compromise
given the alternatives.

----------------------------------------------------------
Comment 3: viewing size of non-text content without alternatives
Source:
http://lists.w3.org/Archives/Public/public-comments-wcag20/200
7Jun/0404.html
(Issue ID: 2269)
----------------------------
Original Comment:
----------------------------

Multimedia objects that are embedded into a web page
generally can not be resized, meaning some user groups may
not be able to access the information it contains.

A text alternative should be provided for these objects but
it may not be appropriate (such as exception point 2 - media,
test, sensory - in success criterion 1.1.1) or it may not
provide an equivalent experience.

With some multimedia, being able to resize the object would
be sufficient to access the information (without needing to
resort to an alternative - where an alternative is
available). For example, a Flash movie showing how something
is done may only require a slightly bigger rendering to be
fully accessible for some users.

Some options to satisfy this may be:

- allowing the user to load the multimedia object into a
stand-alone player where it can be resized.

- providing the user with options for the size at which to
view the multimedia object.

Similarly, other non-text content that can not have an
equivalent text alternative provided (such as exception 3 -
CAPTCHA - in success criterion 1.1.1) could also become
accessible for some users if it is provided at a different
size. For example, a CAPTCHA image may be difficult to "read"
for some users with low vision purely because of the size at
which it is provided. In this case the user would be able to
"read" the CAPTCHA if it was provided at a larger size.

Proposed Change:
Add a success criterion requiring non-text content be
provided at different viewing sizes in situations where the
non-text content can not have an equivalent accessible
alternative provided.

---------------------------------------------
Response from Working Group:
---------------------------------------------

You have identified a problem that is an accessibility issue,
but we do not have enough information about realistic
sufficient techniques for all such situations to include this
as a success criterion at this time. We are adding your
suggestion as advisory techniques for 1.1.1 and 1.4.4, and we
think this should be considered for possible future versions of WCAG.
Received on Sunday, 4 November 2007 05:38:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:09 UTC