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

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

From: Loretta Guarino Reid <lorettaguarino@google.com>
Date: Sat, 3 Nov 2007 21:18:09 -0700
Message-ID: <824e742c0711032118v16202e08k1c8e9957ca1c044e@mail.gmail.com>
To: "Craig Francis" <krang@krang.org.uk>
Cc: public-comments-WCAG20@w3.org

Dear Craig Francis,

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: Style and layout suggestions for QuickRef
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0163.html
(Issue ID: 1955)
----------------------------
Original Comment:
----------------------------

Just been reading the overview at:

http://www.w3.org/WAI/WCAG20/quickref/20070517/Overview.php

And I have been finding it a little difficult to keep track where I
am in the document... which I think can be improved with a couple of
little tweaks to the style sheet.

I've done a quick bodge job version at:

http://www.krang.org.uk/misc/wcag-2.0/

I've only tested it in FireFox 2, as its just to show some ideas I
have had - please note that I am not a designer, and only have a very
basic understanding of design theory.

In the example, I only changed the main style sheet (qr.css) and
removed the 'style' attribute from the 'submitAsCT' paragraph, as the
padding was not necessary. The rest of the HTML is still technically
the same, but has gone though 'HTML Tidy' to make it easier to read.

Really the only issue I had with the current design is determining
which parts are the headings, and content.

I think this is because the yellow boxes are currently indented,
which gives the impression that they are 'pull-outs'.

To reinforce the 'child' properties of the main content (white
background), I indented it and added a border around each part... I
thought that the indenting alone left the content 'floating'.

The 'advisory' box has then been indented to the same level as the
main content, so that it does not give the impression that its a
child of the last section (usually titled 'common failures').

Additionally I have removed some of the rules concerning the font-
size... mostly because I think the current choice is a little to
small for a default... instead opting to use the browsers default
font size.

I hope this might be of some use, and I know I should be focusing
more on the content... but I get the impression that this Overview
will be one of the most used documents, so I think we should try to
make it easy to understand as possible.

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

We have implemented a number of changes to the presentation and style
of the quick reference since the 17 May draft was released including
many of your suggestions. Please take a look and see if this is
better.

----------------------------------------------------------
Comment 2: Trying to help readability
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0073.html
(Issue ID: 1992)
----------------------------
Original Comment:
----------------------------

Document: QR
Item Number: (none selected)
Part of Item:
Comment Type: editorial
Summary of Issue: Trying to help readability
Comment (Including rationale for any proposed change):
I've been reading though the WCAG 2.0 quick reference, and I am
finding it quite a good read, just a little heavy at times.

While going though I had a few thoughts though (below), just regarding
the wording and trying to make it easier to read for the average web
developer (like myself).

I should point out that I am not that much of a wordsmith, so don't
take my views as one from an expert...  just some ideas that might
help.

#############################

On some of the headings, you have the bracketed text "(for the
technologies you checked above)"

I'm not really sure this is necessary, and I think it gets too
repetitive when going though the whole document.

Considering the user must have consciously limited the guidelines
using the form, I think this text can be safely removed.

Really I'm just trying to reduce the word count, as I think a huge
document can put off some readers... especially when going though the
headings that contain off-topic text.

#############################

The two <h6>'s at the end of the "Sufficient Techniques for 1.1.1"
section, I think should be part of their own section.

I think these two parts could be called:

# Situations for 1.1.1

--- Situation A

--- Situation B

--- Situation C

# Techniques for 1.1.1

--- Short text alternative techniques...

--- Long text alternative techniques...

These two headings still need a bit of work (more on that in a
minute)... but it should help to split the content into the two
distinct parts.

############################

Continuing on the previous point, if we have a boxed section for
"Situations for 1.1.1", then we can loose the "Situation X:" prefixes
to the child headings.

This will reduce the word count, and we can possibly look at using
something like an <ol>, or <ul> to list the situations... so we don't
loose the 'A, B, C' counting.

#############################

As to the headings mentioned in the second point, I am not keen on
referring to the guidelines by number.

So, for example, you could rename the headers...

# Situations for 1.1.1

# Techniques for 1.1.1

... to...

# Situations for non-text content (1.1.1)

# Techniques for non-text content (1.1.1)

Personally, I think that the average website developer will not think
about the guidelines by their numerical reference... I would suggest
that a couple of words should be used to summarise each guideline
(like \'non-text content\' for guideline 1.1.1).

Then with the human readable text, we can suffix the heading with the
numerical reference in brackets, as this will help the readers move
around the document.

#############################

In the "situations for non-text content (1.1.1)", I personally find
find it difficult to understand the headings (need to re-read a couple
of times).

To be honest, I'm not really sure why, but taking the heading...

# If non-text content is a CAPTCHA

... I would find it easier to read....

# If the content is a CAPTCHA

Just dropping that one word makes it easier for me to read... I think
it might be because its not required, as a CAPTCHA is being implied to
be non-text (in this context)... perhaps more so when under the boxed
heading of \"Situations for non-text content (1.1.1)\".

The same is true of the other headings...

# If non-text content is a control or accepts user input

# If content is a control or accepts user input

# If non-text content is multimedia

# If content is multimedia

# If the non-text content should be ignored by assistive technology

# If the content should be ignored by assistive technology

#############################

Continuing on from the previous point about not using the numerical
references in the headings, can we rename...

# Common Failures for 1.1.1

... to...

# Common Failures for non-text content (1.1.1)

#############################

Again, with the reference codes, by starting the failures with some
code, it takes a bit of thought to work out where you can start
reading from.

So, could we change the format from...

# F30: Failure of SC 1.1.1 due to

# using text alternatives that are

# not alternatives (e.g. filenames

# or placeholder text)

... to...

# Using text alternatives that are

# not alternatives, e.g. filenames

# or placeholder text (F30)

I have kept the reference code, but moved it to the end, so its still
available to the reader, but becomes more of supplementary
information.

Also, I have dropped the reference to guideline '1.1.1'... this is
because the heading already provides this information (no need to
repeat it).

For another example...

# F20: Failure of SC 1.1.1 and 4.1.2

# due to not updating text alternatives

# when changes to non-text content occur

... to...

# Not updating text alternatives when

# changes to non-text content occur (F20)

#############################

Continuing on from the previous point about not using the numerical
references in the headings, can we rename...

# Advisory Techniques for 1.1.1

... to...

# Advisory Techniques for non-text content (1.1.1)

#############################

For the headings in the \"Advisory\" section, I think that most of
them are fairly short and sweet, which defiantly makes then easy to
read.

But, I'm mot sure why the headings end with "(Advisory)" though, as I
think they should all be advisory points, considering the heading they
are under... so could it be deleted?

And again, I would quite like to remove the 'non-text' word from the
first two "general techniques" headings... as it does seem a little
redundant.

Also, some of the techniques start with reference numbers, could these
be moved to the end, for example...

# H46: Using noembed with embed (HTML)

... to...

# Using noembed with embed (HTML, H46)

#############################

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

#############################

On some of the headings, you have the bracketed text "(for the technologies you
checked above)"

I'm not really sure this is necessary, and I think it gets too repetitive when
going though the whole document.

Considering the user must have consciously limited the guidelines using the
form, I think this text can be safely removed.

Really I'm just trying to reduce the word count, as I think a huge document can
put off some readers... especially when going though the headings that contain
off-topic text.

RESPONSE:

The phrase "for the technologies you checked above" is a reminder that
the Sufficient Techniques listed may not be all of the possible
solutions to meet the Success Criteria.

This reminder is useful in situations where the author:

 -  may not find an appropriate implementation within the listed options but
may be able to introduce another technology with a solution that can be
accommodated.

 - has saved the settings in their first visit and forgotten this during
subsequent visits.

#############################

The two  's at the end of the "Sufficient Techniques for 1.1.1"
section, I think should be part of their own section. I think these
two parts could be called: # Situations for 1.1.1 --- Situation A ---
Situation B --- Situation C # Techniques for 1.1.1 --- Short text
alternative techniques... --- Long text alternative techniques...
These two headings still need a bit of work (more on that in a
minute)... but it should help to split the content into the two
distinct parts. Continuing on the previous point, if we have a boxed
section for "Situations for 1.1.1", then we can loose the "Situation
X:" prefixes to the child headings. This will reduce the word count,
and we can possibly look at using something like an

      , or
            to list the situations... so we don't loose the 'A, B, C' counting.

RESPONSE: The situations include techniques that are applicable only
in that particular situation. A specific heading such as the one
suggested would be misleading in regard to where the techniques are
listed. Note that Success Criteria 1.1.1 is the only Success Criteria
that includes a group of techniques that may be applicable to multiple
situations. Please look at our new format. This should make it
clearer.

#############################
As to the headings mentioned in the second point, I am not keen on
referring to the guidelines by number. So, for example, you could
rename the headers... # Situations for 1.1.1 # Techniques for 1.1.1
... to... # Situations for non-text content (1.1.1) # Techniques for
non-text content (1.1.1) Personally, I think that the average website
developer will not think about the guidelines by their numerical
reference... I would suggest that a couple of words should be used to
summarise each guideline (like \'non-text content\' for guideline
1.1.1). Then with the human readable text, we can suffix the heading
with the numerical reference in brackets, as this will help the
readers move around the document.

RESPONSE: Your idea to put the "short name" in each technique or
failure title is a good idea. We are implementing it with the short
name in parentheses, however, since it stands out from the sentence
better. E.g. # Sufficient Techniques for 1.1.1 (non-text content)

#############################
In the "situations for non-text content (1.1.1)", I personally find
find it difficult to understand the headings (need to re-read a couple
of times). To be honest, I'm not really sure why, but taking the
heading... # If non-text content is a CAPTCHA ... I would find it
easier to read.... # If the content is a CAPTCHA Just dropping that
one word makes it easier for me to read... I think it might be because
its not required, as a CAPTCHA is being implied to be non-text (in
this context)... perhaps more so when under the boxed heading of
\"Situations for non-text content (1.1.1)\". The same is true of the
other headings... # If non-text content is a control or accepts user
input # If content is a control or accepts user input # If non-text
content is multimedia # If content is multimedia # If the non-text
content should be ignored by assistive technology # If the content
should be ignored by assistive technology

RESPONSE: That is an interesting point. We have decided to go one step
further and change 'non-text content' in all the sub-clauses to 'it'.
That way, we both preserve a clear reference to "non-text" content and
we shorten them further.

#############################
Continuing on from the previous point about not using the numerical
references in the headings, can we rename... # Common Failures for
1.1.1 ... to... # Common Failures for non-text content (1.1.1)

Again, with the reference codes, by starting the failures with some
code, it takes a bit of thought to work out where you can start
reading from. So, could we change the format from... # F30: Failure of
SC 1.1.1 due to # using text alternatives that are # not alternatives
(e.g. filenames # or placeholder text) ... to... # Using text
alternatives that are # not alternatives, e.g. filenames # or
placeholder text (F30) I have kept the reference code, but moved it to
the end, so its still available to the reader, but becomes more of
supplementary information. Also, I have dropped the reference to
guideline '1.1.1'... this is because the heading already provides this
information (no need to repeat it). For another example... # F20:
Failure of SC 1.1.1 and 4.1.2 # due to not updating text alternatives
# when changes to non-text content occur ... to... # Not updating text
alternatives when # changes to non-text content occur (F20) \

RESPONSE: With regard to technique and failure naming, the techniques
and failures are all titled in a way that they are understandable when
taken out of context. We envision the information to be used in many
ways, including pulling out only the information or techniques of
relevance. Important information may be lost when part of the content
is taken out of context if all of the important information is not
contained within the headings. Thus they need to be understandable
without looking at the title of the section they are in. This is
particularly true for advisory techniques or failures which must not
be confused with sufficient techniques. We start all failures with the
words "failure of SC XXXX" because the failures could otherwise be
mistaken for techniques. Putting NOT in front of them makes them
negative techniques but techniques just the same. And techniques are
optional, but failures must always be avoided.

#############################
Continuing on from the previous point about not using the numerical
references in the headings, can we rename... # Advisory Techniques for
1.1.1 ... to... # Advisory Techniques for non-text content (1.1.1) For
the headings in the \"Advisory\" section, I think that most of them
are fairly short and sweet, which defiantly makes then easy to read.
But, I'm mot sure why the headings end with "(Advisory)" though, as I
think they should all be advisory points, considering the heading they
are under... so could it be deleted? And again, I would quite like to
remove the 'non-text' word from the first two "general techniques"
headings... as it does seem a little redundant. Also, some of the
techniques start with reference numbers, could these be moved to the
end, for example... # H46: Using noembed with embed (HTML) ... to... #
Using noembed with embed (HTML, H46)

RESPONSE: With regard to putting numbers at the end. Sometimes a
number of techniques have similar beginnings. To make it easy to see
when they are the same or different we put the technique numbers
first. It also fits with our overall policy of providing a short way
to refer to things right at the front.
Received on Sunday, 4 November 2007 04:18:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 17 July 2011 06:13:22 GMT