Your comments on WCAG 2.0 Last Call Draft of April 2006

Dear Henny Swan ,

Thank you for your comments on the 2006 Last Call Working Draft of the
Web Content Accessibility Guidelines 2.0 (WCAG 2.0
http://www.w3.org/TR/2006/WD-WCAG20-20060427/). We appreciate the
interest that you have taken in these guidelines.

We apologize for the delay in getting back to you. We received many
constructive comments, and sometimes addressing one issue would cause
us to revise wording covered by an earlier issue. We therefore waited
until all comments had been addressed before responding to commenters.

This message contains the comments you submitted and the 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 updated WCAG 2.0
Public Working Draft at http://www.w3.org/TR/2007/WD-WCAG20-20070517/.

PLEASE REVIEW the decisions  for the following comments and reply to
us by 7 June at public-comments-WCAG20@w3.org to say whether you are
satisfied with the decision taken. Note that this list is publicly
archived.

We also welcome your comments on the rest of the updated WCAG 2.0
Public Working Draft by 29 June 2007. We have revised the guidelines
and the accompanying documents substantially. A detailed summary of
issues, revisions, and rationales for changes is at
http://www.w3.org/WAI/GL/2007/05/change-summary.html . Please see
http://www.w3.org/WAI/ for more information about the current review.

Thank you,

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:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1241)

Comment: Where it states "The broader term was chosen because it
covers Web applications and other types of content to which the word
"page" may not apply" it gives no example of a "web unit" that is not
a "web page".

Proposed Change:

Provide an example of a "web unit" that is not a web page.

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

We have replaced the term "Web unit" with "Web page" and have modified
this section to describe our use of the term in greater detail. We
have also added an example of content that may not immediately be
recognized as a "Web page."

The definition, found at
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#webpagedef , now reads:

Web page

   a resource that is referenced by a URI and is not embedded in
another resource, plus any other resources that are used in the
rendering or intended to be rendered together with it

   Note: Although any "other resources" would be rendered together
with the primary resource, they would not necessarily be rendered
simultaneously with each other.

   Example 1: When you enter http://shopping.example.com/ in your
browser you enter a movie-like interactive shopping environment where
you visually move about a store dragging products off of the shelves
around you into a visual shopping cart in front of you. Clicking on a
product causes it to be demonstrated with a specification sheet
floating alongside.

   Example 2: A Web resource including all embedded images and media.

   Example 3: A Web mail program built using Asynchronous JavaScript
and XML (AJAX). The program lives entirely at http://mail.example.com,
but includes an inbox, a contacts area and a calendar. Links or
buttons are provided that cause the the inbox, contacts, or calendar
to display, but do not change the URL of the page as a whole.

   Example 4: A customizable portal site, where users can choose
content to display from a set of different content modules.


----------------------------------------------------------
Comment 2:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1242)

Comment: The text "The WCAG Working Group believes that all success
criteria of WCAG 2.0 are essential for some people. Thus, the system
of checkpoints and priorities used in WCAG 1.0 has been replaced by
success criteria under Levels 1, 2, and 3 as described above" is not
very clear, it is still difficult to understand the rationale behind
the move from WCAG 1 and Priorities to WCAG 2 and "Levels".

Proposed Change:

Expand and explain the rationale

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

The description of conformance levels in WCAG 2, at
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-levels , has
been rewritten to clarify the differences:

The word "levels" does not mean that some success criteria are more
important than others. Each success criterion in WCAG 2.0 is essential
to some users, and the levels build upon each other. However, even
content that conforms at AAA (triple-A) may not be fully accessible to
every person with a disability.

*In general, Level A success criteria achieve accessibility by
supporting assistive technology while putting the fewest possible
limits on presentation. Thus people with a wide range of disabilities
using a wide range of assistive technologies, from voice input and
eye-tracking devices to screen readers and screen magnifiers, are able
to access content in different ways. In other words, Level A success
criteria support the ability of both mainstream and specialized user
agents to adapt content to formats that meet their users' needs.

*The success criteria in Level AA provide additional support for
assistive technology. At the same time, they also support direct
access to content by the many people who use conventional user agents
without assistive technology. In general, Level AA success criteria
place more limits on visual presentation and other aspects of content
than the success criteria in Level A.

*Level AAA success criteria increase both direct access and access
through assistive technology. They place tighter limits on both
presentation and content.

----------------------------------------------------------
Comment 3:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1243)

Comment: The text "Note that even conformance to all three levels will
not make Web content accessible to all people." is a bit misleading as
people may think "why bother".

Proposed Change:

Provide explanation.

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

The statements you refer to are meant to reflect the reality that not
all Web content can be made accessible to all people. One of the
lessons learned with WCAG 1.0 was that, for some individuals, even
content that meets WCAG 1.0 AAA did not overcome the accessibility
barriers faced by those with certain combinations of disabilities or
with certain types of severe disabilities.

We have revised this sentence to read, "However, even content that
conforms at AAA (triple-A) may not be fully accessible to every person
with a disability or combination of disabilities especially certain
types of severe disabilities."

----------------------------------------------------------
Comment 4:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1244)

Comment: The description of the differences between levels and
priorities, WCAG 1 and 2 could be confusing for a reader who has not
read WCAG 1 or is new to WCAG. It has the potential to confuse and
hinder understanding as two concepts/rationale are being introduced
simultaneously.

Proposed Change:

One way around this may be to write the document (including all
supporting informative documents) with no reference to WCAG 1 then
have a separate document that explains ALL differences between WCAG 1
and 2. This could be an appendix and referenced at the start of the
WCAG 2.0 normative document. Alternatively an explanation can be given
and then in a separate paragraph or Note an explanation between the
differences of WCAG 1 and 2 given.

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

The introduction and conformance sections of WCAG 2 have been
completely rewritten. The only reference to WCAG 1.0 now reads:

Other documents under development include:

   * Transitioning from WCAG 1.0 to 2.0 - Information to facilitate
transitioning from use of WCAG 1.0 to WCAG 2.0.

----------------------------------------------------------
Comment 5:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1245)

Comment: The ext is verbose and confusing: "...If the test(s) for a
"sufficient" technique or combination of techniques is passed, then
the Working Group would consider that success criterion met. However,
passing all tests for all techniques is not necessary. Nor is it
necessary to meet a success criterion using one of the sufficient
techniques. There may be other techniques which are not documented by
the working group that would also meet the success criterion."

I had to re-read this a few times to understand it. In addition to
this the reference to "the Working Group consider" also makes the
explanation a bit more wordy.

Proposed Change:

It may read better if cut down and simplified to: "If the test(s) for
a "sufficient" technique or combination of techniques is passed, then
that success criterion has been met. Passing all tests for all
techniques is not necessary. Alternatively a success criterion could
be met using a technique that is not referenced in this document."

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

We want to keep the emphasis on the last idea though so we have
adapted your wording in the discussion of success criteria at
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-sc as follows:

   For each success criterion, there is a list of techniques deemed
by the Working Group to be sufficient to meet the requirement. For
each sufficient technique, there is a test to determine whether the
technique has been successfully implemented. If the test(s) for a
"sufficient" technique (or combination of techniques) are passed, then
that success criterion has been satisfied.

   Passing all tests for all sufficient techniques is not necessary.
Most success criteria have multiple "sufficient techniques" listed.
Any of the listed "sufficient techniques" can be used to meet the
success criterion.

   Note that it is not necessary to meet a success criterion using
one of the sufficient techniques that have been documented by the WCAG
working group. There may be other techniques which are not documented
by the working group that would also meet the success criterion. The
working group went through the effort to document these "sufficient
techniques" in order to make it easy for authors to identify
techniques that meet each success criterion and to have confidence
(and evidence) that the techniques meet the success criterion. When
using other externally-provided techniques to meet WCAG 2.0
requirements, it is important that they be created by individuals or
organizations who are knowledgeable about the requirements of WCAG 2.0
and the needs of people with disabilities. The working group will
continue to add new "sufficient techniques" as they are identified,
developed, or made effective by advances in user agents including
assistive technologies.

----------------------------------------------------------
Comment 6:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1246)

Comment: "In choosing Web technologies (HTML, scripting, etc.) that
will be used when building content, authors need to know what
technologies they can assume will be supported by, and active in, the
user agents (including assistive technologies) that people with
disabilities will be using. If authors rely on technologies that are
not supported, then their content may not be accessible."

- "assume" seems like a weak word and one that could provide a
loophole, get out clause excuse for not making certain technologies
accessible. For example a developer could "assume" that all their
users have the latest Flash plug-in, screen reader version etc which
may support certain technologies better than earlier versions. While I
can understand what the concept of baseline is trying to do - give
flexibility where it makes sense - it leaves a back door open. Would
it not be an idea for WCAG 2 to recommend a minimum baseline (as the
Mobile Web Initiative does in their Best Practises document). This can
then be updated by WCAG as and when technologies move on.
Alternatively some more substantial advice or guidance should be given
to help people set sensible baselines and prevent people abusing the
baseline.

- the baseline section explains what it is (although in a slightly
difficult to read way) but it gives very scant guidance on setting a
baseline. This needs to be substantially developed.

- The text "authors need to know what technologies they can assume
will be supported by, and active in, the user agents" infers that this
information is available from the software vendor where in reality it
is not readily available. How then is a developer best able to
"assume" a baseline without thoroughly investigating all access
technologies and their ability to support CSS, HTML, Flash, JavaScript
et al. Who is responsible for providing this support? Software
developers, Government, advocacy groups?

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

The conformance section of WCAG2 has been completely rewritten. The
term "baseline" has been replaced by "accessibility-supported Web
technologies". The issue of what it means to be an
accessibility-supported Web technology is addressed in the section
"Accessibility Support of Web Technologies" at
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#accessibility-support .

If individual author must evaluate whether technologies are
accessibility supported, this will be a tremendous burden on them.
Knowledgeable organizations are encouraged to become centers of
expertise on these topics, and to publicize the state of user agent
and assistive technology support for different technologies, so that
authors can make well-informed choices.

----------------------------------------------------------
Comment 7:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1247)

Comment: The paragraphs describing baselines, what's included not
included and what you have to confirm to depending on this, is very
difficult to read.

Proposed Change:

Perhaps a couple of examples can be given explaining in each one what
is included, not included and what is expected, some use scenarios
i.e. "Is you include X, Y and Z in you baseline then...if  U and V are
not included then you must....".

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

We have completely rewritten the Conformance section, and hope that
baselines (now accessibility-supported Web technologies) is now a
clearer concept. We hope to publish some examples of the user agent
and assistive technology support available for several technologies,
as an example.

----------------------------------------------------------
Comment 8:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1248)

Comment: In reference to the number of baselines given there needs to
be more of a focus on non-government/intranet example baselines.
Government and Intranet baselines are the less contentious ones to set
(at RNIB we have always done this for Intranets for example making
adherence to JS less of a priority dependant on the user agents etc
used in the organisations). Business websites, corporates, SME's etc
are the ones who are going to need more of a steer as they have
business needs that may overshadow fair baselines.

Proposed Change:

Perhaps another 2 examples of potential baselines for business could
be given along with rationale.

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

The concept of baselines has been completely re-written.  WCAG now
discusses accessibility-supported Web technologies (i.e. technologies
that are used to create content that work with users' assistive
technologies and access features in browsers):
"In choosing Web technologies (HTML, scripting, etc.) that will be
used when creating content that will meet the WCAG 2.0 success
criteria, authors must use technologies that are supported by users'
assistive technologies as well as the accessibility features in
browsers and other user agents. Such technologies are referred to as
"accessibility supported.""

So the question becomes "What technologies are considered
accessibility supported for public web pages?", that is, web pages for
which the author has no special knowledge about what user agents and
assistive technologies are available to users.

To answer this, one would need need:
1. Accessibility support analyses for candidate technologies,
documenting the user agent (browser and assistive technology) support
for that technology.
2. Analysis of browser and assistive technology available to users.

Ideally, this information would be gathered in a publicly available
location that could be consulted by anyone creating a public website.
Until such a database is available, it may be necessary for authors to
consult with knowledgeable sources for advice.


----------------------------------------------------------
Comment 9:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1249)

Comment:  The sentence "While scoping can include and exclude parts of
a site, processes (such as shopping) and authored units must be
considered in their entirety." is a bit confusing. Isn't shopping
considered to be "part" of a site as well as a "process"?

Proposed Change:

Provide some explanation.

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

The "Scope out" language has now been removed from the Conformance
section. Conformance is based on Web page(s): that is a primary
resource referenced by a URI and any other resources that are rendered
simultaneously with it with the understanding that different sub
elements or resources may be rendered simultaneously with the primary
resource at different points in time. The conformance claim process
requires the claimant to state which URIs the claim applies to.

We have also added a conformance requirement regarding pages that are
part of a process (see
http://www.w3.org/TR/2007/WD-WCAG20-20070517/#cc9 ):

Complete processes: If a Web page that is part of a process does not
conform at some level, then no conformance claim is made at that level
for any Web pages in that process.


----------------------------------------------------------
Comment 10:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1250)

Comment: It feels as if this is a get out clause for a site owner to
make all but the most complex area of a site accessible. For example a
supermarket can make everything but the online shopping accessible and
stop there. It potentially allows to the site owner to get complacent
once all but the most complex parts of the site have been made
accessible. You can argue that laws enforcing accessibility in a
country will bridge this gap of possible apathy but not all countries
a) have laws, b) have the will to enforce them. Take for example China
in 2008. They could build a site using technologies amount to allowing
content based on Ajax i.e. to update timetables etc and leave those
sections out of the conformance claims. A basic baseline has to be
recommended in WCAG 2, it can't be left to legal, market and other
forces from country to country. It can't claim to be a standard if
there is not a minimum foundation.

Proposed Change:

This needs to be more water tight. If that section CAN be made
accessible (i.e. the techniques exist to make it accessible) then it
must be. If it is problematic to make accessible then a clear
indication that it is being worked on placed in the conformance claim.

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

This comment seems to be confusing the question of baseline (that is,
what technologies can be used to satisfy the success criteria) and the
scope of a conformance claim (that is, which Web pages does it cover.)

WCAG conformance claims are descriptive, that is, they state which Web
pages conform. To address issues such as supermarkets making
everything but the on-line shopping accessible, WCAG does require that
conformance claims cover complete processes: "If a Web page that is
part of a process does not conform at some level, then no conformance
claim is made at that level for any Web pages in that process.".
However, in general, whether an entire web site conforms is a policy
issue. Once we move beyond individual Web pages, it is difficult to
define the boundaries of what must or must not conform.

----------------------------------------------------------
Comment 11:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1251)

Comment: "For framesets, noframes is no longer required", unsure why
this is no longer present.

Proposed Change:

Explanation needed as to why it is not included.

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

If "frames" is an accessibility-supported feature of the technology
for the users of your page then you can use frames and noframes is not
required. If 'frames' is not accessibility supported, then you can
still use them but in this case, you would have to use noframes.  Even
if 'frames' is not accessibility supported, it is good to include
NOFRAMES.  We have an advisory technique (to be drafted) that
recommends its use.

Note:  We're no longer considering frames as non-text content and
assistive technology support for frames has improved considerably.

----------------------------------------------------------
Comment 12:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1252)

Comment: Success criteria don't mention having instructions in a page
to help users interact (for example fill in forms). Also makes no
mention of placement of help text (for example at the top of forms
rather than at the foot after the submit button. Unsure if SC 2.5.4
covers this.

Proposed Change:

Add the above in as Success Criteria or clarify the are part of 2.5.4
in the techniques.

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

Thank you for your suggestion. We have added a sufficient technique to
How To Meet 3.3.5 (formerly 2.5.4) about providing instructions at the
top of a form.

----------------------------------------------------------
Comment 13:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1253)

Comment:  No mention is made of presentation of text i.e. left aligned
vs. justified/right aligned text, long lines, multiple columns,
overuse of different styles etc.

Proposed Change:

Add in.

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

Since these are all design decisions related to visual presentation,
the working group believes that this issue is covered under "Principle
1: Content must be perceivable: Guideline 1.3 Create content that can
be presented in different ways (for example spoken aloud, simpler
layout, etc.) without losing information or structure." Satisfying
these success criteria should let the user control the style of
presentation of text, possibly via assistive technology.

We have added the following advisory techniques to Guideline 3.1:
- Avoiding centrally aligned text
- Avoiding text that is fully justified (to both left and right
margins) in a way that causes poor spacing between words or characters
- Avoiding chunks of italic text
- Avoiding overuse of different styles on individual pages and in sites

----------------------------------------------------------
Comment 14:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1254)

Comment:  Moving focus automatically in form fields can cause problems
for screen reader and screen magnification users.

Proposed Change:

Remove or add in a clause that says that the fact focus moves on is
flagged in the instructions for the form.

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

We have updated the wording of 3.2.2. It now reads, "Changing the
setting of any user interface component does not automatically cause a
change of context  unless the user has been advised of the behavior
before using the component."

----------------------------------------------------------
Comment 15:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1255)

Comment: WCAG1 14.1 is not represented in this guideline or any other.
This is quite a major omission and one that is important for not only
users with cognitive and reading problems but also browsing in a
second language; a strange omission given W3C's Internationalisation
WG.

Proposed Change:

Add in

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

The working group was unable to come up with a testable equivalent of
WCAG1 14.1. However, we have added an advisory technique to guideline
3.1 and SC 3.1.5 that reads, "Using the clearest and simplest language
appropriate for the content."

We have added language to the Introduction to highlight the fact that
WCAG 2 only addresses some of the needs of people with cognitive,
learning, and language disabilities, and calls out the need for more
research in this area. WAI is exploring ways in which to support and
encourage work in this important area.

----------------------------------------------------------
Comment 16:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1256)

WCAG1, 3.4 (use relative fonts) not in WCAG 2. Unsure why this is.

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

Although resizing is primarily a user agent function, we have added
new success criteria to address the author's responsibility for
supporting text resizing:

Level AA: Visually rendered text can be resized without assistive
technology up to 200 percent and down to 50 percent without loss of
content or functionality.

Level AAA: Visually rendered text can be resized without assistive
technology up to 200 percent and down to 50 percent without loss of
content or functionality and in a way that does not require the user
to scroll horizontally.

----------------------------------------------------------
Comment 17:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1257)

Comment: WCAG1, 1.5 (redundant text links for client-side image maps)
not in WCAG2. Says this is due to user agents now being able to render
text alternatives for client-side images. True however this does not
take into account screen magnification users who can get easily lost
in a complex image map.

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

The AT support described in the mapping document also applies to
screen magnification software, which could use the text alternatives
to present the user with a list of links should they get lost in a
complex image map.

WCAG 1.0 Checkpoint 1.5 is really subsumed by Success Criteria 1.1.1.
Even with high levels of magnification, image maps are readily
keyboard accessible using only the tab key. The consensus of the
working group was that redundant text links were not necessary, even
though some people might prefer them.

Note: The mapping has been removed from the WCAG document itself. The
working group will work in coordination with the EOWG WCAG 2.0
Materials Support Task Force in the creation of transition materials
and will consider these comments when the mapping is updated.


----------------------------------------------------------
Comment 18:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1258)

Comment:  WCAG1, checkpoint is not reflected in WCAG 2. The WCAG 2
checklist states that this is because it is reflected in the
techniques rather than the Success Criteria which are normative. Can
be argued that 14.2 is as important to people with cognitive problems
as 1.1 and alt text are to VI users. In WCAG one the former was a P3
that later a P1. It may be that because it is not testable that 14.2
hasn't carried over into WCAG 2 but it shouldn't be excluded because
it is not testable as it is still a fundamental guideline for this
user group. In the Introduction it states that WCAG2 is for people
with cognitive and learning problems so therefore this checkpoint
should be in WCAG 2.

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

The working group was unable to come up with a testable version of
WCAG1 14.2, so that authors could determine when the supplements were
needed and how to ensure that the supplements actually addressed the
needs of people with cognitive disabilities. Graphic or auditory
supplements are listed as sufficient techniques for SC 3.1.5

We have added language to the Introduction, the Conformance section,
and the Quick Reference to highlight the fact that WCAG 2 only
addresses some of the needs of people with cognitive, learning, and
language disabilities, and to call out the need for more research in
this area. WAI is exploring ways in which to support and encourage
work in this important area.

We have added some best practices for cognitive, learning, and
language disabilities as advisory techniques, and we have proposed 3
new success criteria in this area.

----------------------------------------------------------
Comment 19:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1259)

Comment:  References to secondary school in this are at best difficult
and confusing for a developer to understand. This type of
understanding, i.e. as defined by UNESCO, can be argued to be out of
scope of the remit of the web designer to understand and as a result
of it being to difficult the checkpoint perceived as woolly and
therefore ignored.

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

The Working Group based SC 3.1.5 on an existing standard for
evaluating the difficulty of text in order to bring the goals of WCAG
1.0's checkpoints 14.1 and 14.2 into a form where authors could
determine when they had satisfied the success criterion.

----------------------------------------------------------
Comment 20:

Source: http://www.w3.org/mid/7DCC97516CAEE343BD17A00F900754E1065D702C@jstmsx01.ads.rnib.org.uk
(Issue ID: LC-1260)

Comment:  The paragraph "This requirement does not apply to individual
words or to phrases that have become part of the primary language of
the content. For example, "rendezvous" is a French word that has been
adopted in English, appears in English dictionaries, and is properly
pronounced by English screen readers." does not give enough guidance
to developers as to what individual words or phrases qualify as a
change in language.

For example, some words are *just* entering the English language or
are names used in products. For example is does Bordeaux wine have to
have Bordeaux marked up?

Proposed Change:

Give further examples of how to clarify if a word should be marked up
or not. One example may be is the word is in the dictionary for the
natural language of the page (i.e. in the UK the word is in the Oxford
English Dictionary).

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

We have added the following to the Intent section of SC 3.1.2 to
clarify that such uses generally do not need to be marked up:

Frequently, when the natural language of text appears to be changing
for a single word, that word has become part of the language of the
surrounding text. Because this is so common in some languages, single
words are not included in this success criterion.

Received on Wednesday, 23 May 2007 04:02:12 UTC