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:31:57 -0700
Message-ID: <824e742c0711032131u58f2612fof1339f6d23ae158e@mail.gmail.com>
To: "Greg Gay" <g.gay@utoronto.ca>
Cc: public-comments-WCAG20@w3.org

Dear Greg Gay,

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

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.


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: LC-469: Resizing with no horizontal scrolling
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0068.html
(Issue ID: 1986)
Original Comment:

> Source: http://www.w3.org/mid/20060515151645.E147A6636B@dolph.w3.org
> (Issue ID: LC-469)
> Comment (Including rationale for any proposed change):
> There is currently no item number relevant to this comment. Technique
> G96 seems to be the only place within the WCAG 2.0 documents that
> mentions anything about "relative positioning", or more specifically
> use of relative measures. Using relative measures is particularly
> important for low vision users who use a browser function to blow up
> the text size. It is also important for those using small screens like
> PDAs.
> Proposed Change:
> This requirement seems to fit best under WCAG principle 4, regarding
> robust. Perhaps a new guideline 4.1.3, at level 2. something like
> "Ensure that content can be resized without losing its symmetry" Then
> in the techniques describing the use of relative measures for sizing
> block level items, text, images, etc.
> ----------------------------
> 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.
Response from Greg Gay:
The Level AA criteria should be good. Though it should apply to content
in general. Not just text.

At Level AAA, I don't think eliminating horizonatal scrolling addresses
the issue. When increasing the size of a presentation, it is often
necessary to push the content off the side of the screen in order to
maintain the layout. At 200% it may not be a big problem, but for those
who need text (and images etc.) presented larger than 200%, say 400% for
sake of argument, the text can end up in a one or two words wide column,
and potentially  disrupt the layout of the page enough that it makes it
difficult to comprehend the overall structure of a page, which can often
carry significant meaning.  Having the  entire presentation  increase in
size at the same rate, while it does require the users to scroll
horizontally, maintains the symmetry of the overall presentation, making
it easier to understand. The presentation or layout of content should
look the same at 200% , or 400%, as it does at 100%, rather than having,
for example, 400% text squeezed into a 100% container. The container
should also be enlarged to 400%, much like magnification software
presents content, with text, images, and their containers all magnified
at the same rate. This same effect can be reproduce in a web browser
window through strict use of relative measures.

As an example, IE 7 functions this way by default, ignoring absolute
measures, acting like a screen magnifier does (I'm not a big IE fan, but
I do like this particular new feature). Presentation at 400% in IE, is
much easier to comprehend, even having to scroll horizontally, than the
same presentation in other browsers that do enforce absolute measures,
and attempt to squeeze everything magnified into the  same amount of
space unmagnified.

This issue applies to other types of content besides text. Content in
general should resize, including images (which often contain text), as
well as the layout (i.e. containers for text and images). Authors
generally don't have to do anything to make text resizable. Making
everything on a page resizeable is more of a challenge, though if
relative measures are used throughout, it's relatively straight forward
to accomplish.

Perhaps word the guideline:
Level AAA: Visually rendered <content> 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. Beyond 200 percent, content should resize
maintaining the layout and relative visual presentation/locations of the
content as it would be presented between 100 precent and 200 precent

I might also question whether 200% magnification is sufficient for the
majority with low vision users. For purposes of defining when scrolling
should not be required, it's probably okay, but my general sense is that
the majority of users that require large text, would probably opt for
something larger than 200%. Is there research to suggest 200% is the
optimal size for a diverse population of users with low vision? I'm just
curious where the numbers came from. Similarly, 50% may not be enough
either, given PDA or perhaps cell phone screens are smaller than 50% of
you standard 17 in monitor resolution.  The numbers here are probably
fine, but it might save argument later if there is some reasoning
provided why these values were choosen. (Maybe there is. I just haven't
found it yet)

Response from Working Group:

We agree that text cannot be significantly enlarged without adapting
the layout. The type of layout adaptation discussed in the comment is
called "zoom" - in which the layout regions expand with the text,
frequently beyond the range of the viewport - and is discussed in
Understanding SC 1.4.4 and Understanding SC 1.4.7. The Working Group
expects large scale (greater than 2x or 4 times the area) zoom
functionality generally to be provided by assistive technology, and
does not provide content authoring requirements to support this
because at a minimum zoom tools can enlarge the image written to the
screen. In many situations tools can provide better support by
redrawing text at larger sizes, rather than simply enlarging the
pixels, but the features necessary to support this are believed to be
covered by other Success Criteria.

SC 1.4.4 and 1.4.7 are not intended to address large scale zoom
functionality. Users needing zoom greater than 2x are expected to use
assistive technology. But the Working Group recognizes that text size
presents a problem for many users who have difficulty reading small
text, but whose difficulty is not so extreme that they would use
assistive technology. Thus, these success criteria are about the
ability for text to be scaled within mainstream browsers using the
features built into the browsers. At Level AA, SC 1.4.4 simply
requires that the text can be scaled by 200% and down to 50% but
doesn't forbid text from going offscreen. Zoom features in the
browsers are usually used for this function. At Level AAA, SC 1.4.7
requires that text scaling be possible where the text would reflow so
that horizontal scrolling is not required. This makes it very much
easier to read blocks of text that would otherwise always be half on
and half off screen.

The range of up to 200% is provided because a limit to the requirement
had to be set. This limit is based on the scaling supported by today's
browsers and what the Working Group considered a reasonable degree of
scaling within a well-designed layout. Users needing scaling beyond
this limit should not have expectations about the usefulness of the
scaling in mainstream browsers and should use assistive technologies.

Comment 2: LC-535, LC-536: Audio descriptions and full text alternatives
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0068.html
(Issue ID: 1987)
Original Comment:

> Source: http://www.w3.org/mid/20060511195339.A362647BA5@mojo.w3.org
> (Issue ID: LC-535)
> Item Number: Success Criterion 1.2.2
> Part of Item:
> Comment Type: TE
> Comment (Including rationale for any proposed change):
> Guideline 1.2
> Guidelines 1.2.2 and 1.2.3 are not mutually exclusive.  Perhaps it
> should be,  if an audio description is provided, compliance is at
> level 2. If a transcript is provided instead, compliance is at level
> 1.
> 1.2.2  "Audio descriptions of video, or... are provided for
> prerecorded multimedia."
> 1.2.3  "Audio descriptions of video are provided for prerecorded
> multimedia.
> Proposed Change:
> Drop "Audio descriptions of video" from  1.2.2. Audio description are
> relatively difficult to implement, while text transcripts are quite
> easy. Leave the transcript at level 1, which is attainable by
> everyone, and keep audio descriptions to level 2.
> ----------------------------
> Response from Working Group:
> ----------------------------
> SC 1.2.2 and 1.2.3 are indeed not mutually exclusive. If they were, we
> couldn't have them both as success criteria. However, making the
> change you suggest would remove options for authors at level A.  In
> some cases it is easier and/or more effective to provide the full text
> alternative.  In other cases it is easier and/or more effective to
> provide the audio equivalents. The current wording allows the author
> to chose at level A, but does require them to use audio description at
> level AA.  Audio description would of course satisfy both level A and
> AA if it were provided. Therefore removing Audio Description from
> level A would make it harder for authors, not easier since it removes
> an option.

Response from Greg Gay:
See my response to Comment 9 below

> ----------------------------------------------------------
> Comment 9:
> Source: http://www.w3.org/mid/20060511195927.48A1833205@kearny.w3.org
> (Issue ID: LC-536)
> Item Number: Success Criterion 1.2.7
> Part of Item:
> Comment Type: TE
> Comment (Including rationale for any proposed change):
> Guidelines 1.2.2 and 1.2.7 are not mutually exclusive.
> 1.2.2 "... a full multimedia text alternative including any
> interaction, are provided for prerecorded multimedia."
> 1.2.7 "For prerecorded multimedia, a full multimedia text alternative
> including any interaction is provided
> Proposed Change:
> Drop 1.2.7 in favour 1.2.1 at level 1, with Audio descriptions removed
> in favor of keeping them with 1.2.3 at level 2.
> ----------------------------
> Response from Working Group:
> ----------------------------
> Correct. SC 1.2.2 and 1.2.7 are not mutually exclusive. If they were
> we could not require both.   The option is provided at Level A.  At
> level AA Audio descriptions are required (which would also satisfy
> level A). At level AAA the text description is required, which would
> be in addition to the audio description required in level AA.  The
> working group did not want to require SC 1.2.7 at level A but did want
> to have it as an option there and as a level AAA success criterion if
> it was not provided at level A.
Response from Greg Gay:
I'm still not sure about this one.  If I provide a full text alternative
(but no audio descriptions) does the content comform at level 1 or level
3? Assuming all level 2 items are required for level 3 items to conform,
it makes sense that it would conform at level 1 only. If however I
provide an audio description, but not a full text alternative, does the
content conform with level 1 or level 2?  It would make sense that it
conforms at level 2, but it's not clear that is the case when audio
descriptions are also included at level 1. The logic behind 1.2.2, 1.2.4
and 1.2.7 together is incorrect.

It reads like this (assuming lower levels must be satified first)
level 1 = audio description || full text description
level 2 = audio description && (full text description || audio description)
level 3 =  full text description && (audio description && (full text
description || audio description))

level 1 = level 2  if only audio descriptions are provided (but not text)
level 1 + level 2 = level 3 + level 2  if both audio and text are provided

level 1 full text
level 2 audio and full text
level 3 eliminate 1.2.7

I'm still not sure I have the logic right myself. But either way, I
could find no way to make the three agree with each other without
creating confounds. I believe they need to be reduced to two guidelines
audio or text at level 1 and audio and text at level 2, or text at level
2 and audio and text at level 3 (depending on the importance, or weight,
assigned to audio  equivalents and to text equivalents) Some more
thought needs to go into these three guidelines I think.

Response from Working Group:

It is true that SC 1.2.2, 1.2.4, and 1.2.7 are somewhat redundant with
each other. This is to give the author some choice at the minimum
conformance level, and to provide additional requirements at higher
levels. At Level A in SC 1.2.2, authors do have the choice of
providing either an audio description or a full text alternative. If
they wish to conform at Level AA, under SC 1.2.4 authors must provide
an audio description - a requirement already met if they chose that
alternative for 1.2.2, otherwise an additional requirement. At Level
AAA under SC 1.2.7 they must provide an extended text description.
This is an additional requirement if both 1.2.2 and 1.2.4 were met by
providing an audio description only. If 1.2.2 was met, however, by
providing a text description, and the 1.2.4 requirement for an audio
description was met, then 1.2.7 does not add new requirements.

In order to clarify this, explanation has been added to the
Understanding documents for the three Success Criteria.

Comment 3: LC-537, LC-538: Move Luminosity Contrast Ratio to techniques
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0068.html
(Issue ID: 1988)
Original Comment:

> Source: http://www.w3.org/mid/20060511200217.4083633205@kearny.w3.org
> (Issue ID: LC-537)
> Item Number: Success Criterion 1.4.1
> Part of Item:
> Comment Type: GE
> Comment (Including rationale for any proposed change):
> Guideline 1.4
> Luminosity Contrast Ratio in its current form appears to be a less
> than perfect measure of contrast. For example black text on a white
> background is more readable than white text on a black background, yet
> both have the same ratio.  In the future as the algorithms for
> measuring contrast become better, the suggested 5:1 ratio in 1.4.1,
> may no longer be valid.
> Proposed Change:
> A general statement should be made in the guideline, something like
> ...use foreground and background colours that provide sufficient
> contrast...", and move LCR and the suggested ratio to the techniques
> document, where it can be adjusted as measure of contrast become
> better defined.
> ----------------------------
> Response from Working Group:
> ----------------------------
> The change you propose would make the success criteria untestable.
> All success criteria need to be testable to qualify. So we need to
> provide specific description of what 'sufficient contrast' is.
Response from Greg Gay:
I don't see a difference in testability between including LCR in the
guidelines or in the techniques. In the techniques it would allow the
option to alter the threshold levels should these measures  need
adjustment after WCAG 2 becomes stable.

The rewritten 1.4 guidelines have changed. I'll give them some more
attention for the final review of this draft.

> ----------------------------------------------------------
> Comment 11:
> Source: http://www.w3.org/mid/0060511200418.D1BC733205@kearny.w3.org
> (Issue ID: LC-538)
> Item Number: Success Criterion 1.4.3
> Part of Item:
> Comment Type: TE
> Comment (Including rationale for any proposed change):
> As suggested for 1.4.1, Luminosity Contrast Ratio in its current form
> appears to be a less than perfect measure of contrast. For example
> black text on a white background is more readable than white text on a
> black background, yet both have the same ratio.  In the future as the
> algorithms for measuring contrast become better, the suggested 10:1
> ratio in 1.4.1, may no longer be valid.
> Proposed Change:
> A general statement should be made in the guideline, something like
> ...use foreground and background colours that provide *high*
> contrast...", and move LCR and the suggested ratio to the techniques
> document, where it can be adjusted as measure of contrast become
> better defined.
> ----------------------------
> Response from Working Group:
> ----------------------------
> The change you propose would make the success criteria untestable.
> All success criteria need to be testable to qualify. So we need to
> provide specific description of what 'sufficient contrast' is.
> It is not always true that black text on a white background is more
> readable.  For older people and people with impaired vision white on
> black is generally more readable because there is less light scatter
> (for media opacities) and fewer problems with adaptation levels.
Response from Greg Gay:
This would seem to strengthen the argument that LCR values should be
separated from the text of the guidelines. Sufficient contrast should be
explicitly defined, since it would seem to be relative to the
individual. Taking colour blindness, or age, or visual acuity into
consideration, levels of contrast seem to be a subjective measure.

The fact that the guidelines have moved contrast into level 2 and 3,
makes it less critical that it was when it was in level 1, though given
the nature/relative newness of the measure, including explicit measure
in the guidelines could be troublesome in the future.

Response from Working Group:

All the success criteria need to have sufficient specificity that
using only the success criteria (and their definitions which are also
normative) you can get most people to all agree. Without a specific
definition of contrast including the metrics - this would not be true.
You can't make the success criteria more restrictive in the techniques
then they were in the success criteria. Only the success criteria are
normative. The techniques are just informative. Hence we need to
provide testable specifics in the success criteria (including their

Accessibility is ALWAYS relative to the individual. However, standards
need to be relative to populations. The calculations for contrast are
based on population measures of color blindness, age and acuity. (see
Understanding SC 1.4.3). Standards that people can design to are then
established. The current guidelines are based on established industry
standards and research on color blindness and visual acuity. They will
also undergo implementation testing before the guidelines are finally
released. Does this answer your questions?

Comment 4: Use Headings as well as make them meaningful
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0207.html
(Issue ID: 2024)
Original Comment:

In addition to headings being descriptive, it should state that
headings must be used to structure content (and be descriptive). It
reads now  as ".. if you use heading they must be descriptive".
Headings are generally meaningful by default. What\'s more important
is that heading markup be used (properly) instead of using other
means to visually present heading.

Proposed Change:
\"Headings and labels are used and are descriptive\"

Response from Working Group:

We believe these issues are already covered.

SC 1.3.1 requires that if headings are used, then are marked up
properly. See technique "H42: Using h1-h6 to identify headings" and
failures "F2: Failure of SC 1.3.1 due to using CSS to create
variations in presentation of text that conveys information without
also using the appropriate markup or text" and "F64: Failure of SC
1.3.1 due to using changes in text presentation to convey information
without using the appropriate markup or text".

SC 2.4.6 requires that headings that are used are sufficiently
descriptive so they can help orient the user within the content. It is
true that most headings are descriptive, but they may rely on the
existing logical structure too much to help orient the user.

SC 2.4.9 requires the use of headings where appropriate in the content.

Comment 5: Limits on pronunciations
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0209.html
(Issue ID: 2025)
Original Comment:

I might question how relevant this is to accessibility. This is really
only applicable when words appear without a context from which to
derive meaning. I'm having trouble understanding how such ambiguity
would be tested, and if it can be tested, how to test whether a
pronunciation has been provided.

Response from Working Group:

In some languages, there are many words that have alternate meanings
and pronunciations. Although people who visually read and have good
cognition may be able to determine the meaning, it is still sometimes
ambiguous. To handle such languages, there are ways to mark up the
text so that its proper pronunciation (and therefore meaning) can be
determined. This is helpful to all but particularly to people with
cognitive disabilities who may have more trouble than most with this
type of content - and with those using screen readers where
mispronunciation is worse than ambiguous pronunciation (which is what
visual presentation gives.) Although the Success Criterion only
requires it when it is strictly ambiguous, advisory techniques on this
Success Criterion recommend it when it is not as obvious or even when
ambiguous without context.

Comment 6: Limits on user controlled timed events
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0203.html
(Issue ID: 2049)
Original Comment:

Refers to the Users' ability to control timed events. An exception
could be when timed tests are being presented. In such a case one
might not want a student to have control over the time limits, but
rather allow a third party (e.g. the teacher) to grant extra time as
appropriate given the test takers limitations. In most academic
institutions a suitable extended time is determined through evaluation
of a student's ability (e.g. psycological, physical, occupational
assessments) and granted, for instance:  time and a half, double time
etc, on tests.

Proposed Change:
Perhaps as an additional line with Essential Exceptions - "In cases
where users control over timed events would invalidate the outcome, a
third party can control timed events  for the user (for example,
granting double time on a test)"

Response from Working Group:

Since it's possible to extend the time limit in such cases, then the
time limits would not be essential. We have removed "(for example,
time-based testing)" from 2.2.1 to avoid confusion, and added
explanation to Understanding 2.2.1 about timed tests.

Comment 7: Level A SC for link text
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0204.html
(Issue ID: 2050)
Original Comment:

I would agree that if context gives meaning to otherwise
non-meaningful link text, the link text should not need its purpose to
be programmatically determined, unless programmatically determined
includes a test that checks for contextually rendered meaning (i'm
guessing this might require human testing). An example might include
news items in which the title, in addition to some non-meaningful link
text (e.g. "more"), are provided in sequence when moving through the
links on a page. In this case the meaning of "more" can be determined
by a human tester through a linked title that appears immediately
before the more link.

Proposed Change:
At level A the guideline might read: "The purpose of each link can be
determined from the link text or through the link's immediate context"

Response from Working Group:

The Success Criterion is now:
2.4.4 Link Purpose (In Context):  The purpose of each link can be
determined from the link text alone, or from the link text together
with its programmatically determined link context, except where the
purpose of the link would be ambiguous to users in general.

We believe that "programmatically determinable link context" is
clearer than "immediate context".

Support by assistive technology for showing the user the context of
the link is weaker than we would like, as is recorded in the User
Agent Notes for the different techniques. We hope that this will
change as more content satisfies this success criterion.

Comment 8: Headings (2.4.9) as Level AA
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0208.html
(Issue ID: 2052)
Original Comment:

This should probably be a level AA guideline. Structuring content with
properly used heading markup can greatly improve the usability of
content, allowing AT user to quickly generate a summary of the
content, and allowing them to easily navigate to sections within a
page. Without them, particularly for longer pages, discovering if the
content on the page contains the information one is looking for, can
take much longer than it needs to if a user has to read an entire page
to discover information later in the page, or perhaps to discover the
information is not found on the page.

Proposed Change:
This guideline could possibly be combined with 2.4.6 as an AA guideline.

Response from Working Group:

In order to be a AA or A requirement, it must possible for all types
of content to meet the requirement.  In addition, all success criteria
must be reliably testable.  After a great deal of effort, the working
group was unable to craft a criterion that met both requirements.  By
defining a section in a way that allowed reliable agreement between
parties on what is and is not a section, some types of longer-form
text content (e.g. novels) cannot pass.  Because of this limitation,
the Success Criterion must remain level AAA.

Below is the text of the SC and the definition of section

2.4.10 Section Headings: Section headings are used to organize the content.
Note: "Heading" is used in its general sense and includes titles and
other ways to add a heading to different types of content.

Note: This success criterion covers sections within writing, not user
interface components. User Interface components are covered under
Success Criterion 4.1.2.
Section Headings: Where content is organized into sections, the
sections are indicated with headings.

Note: "Heading" is used in its general sense and includes titles and
other ways to add a heading to different types of content.

section: A self-contained portion of written content that deals with
one or more related topics or thoughts.

NOTE: A section may consist of one or more paragraphs and include
graphics, tables, lists and sub-sections.

Comment 9: Use alternative versions only when necessary C
Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0210.html
(Issue ID: 2053)
Original Comment:

4.)  An accessible link from the nonconformant version to a conformant
version (and back again) seems straight forward (am I perhaps missing
something here?). The idea though that alternate versions only be used
when the original version can not be made accessible, seems to have
been dropped. This is important because it is fairly well known that
secondary versions tend not to be updated at the same frequency as the
primary version (I don\'t have a referecne). Instead of saying
"...does not meet all of the success criteria..." say ".., can not be
made to meet all success criteria..

Fallback #2 seems insufficient. Users should be able to find an
accessible version directly from the less accessible version.  #2
suggests something similar to using a transcript instead of captioning
for a video. A transcript, while useful when captions can not be
provided, or used in place of a video where a video player is not
available, is  not all that useful when watching a video and trying to
match the lines of the transcript with the apparent dialogue and
actions it contains. Similarly a list of accessible alternate pages
has limited utility, forcing the user to perhaps  leave a sequence of
page, or loose the consistency provided by the primary version, and
its environment.

Fallback #1, I'm not sure about. What constitutes "...WCAG conformant
links?"  and is it relevant that future technologies many not conform
to them. Should it not be a requirement that future technologies
conform if they are to be judge accessibility supported? Any "link"
that is readable by assistive technologies (contains readable text)
and is device independent (keyboard accessible) should conform. Both
of these are already requirements (1.1, 2.1)

Response from Working Group:

Fallback #1 won't work because it assumes that the non-conforming page
conforms. The one option that talks about a link from the
non-conforming page is stated as having to conform because one has to
assume that part of the page doesn't conform (since it is
non-conforming) and this option states that at least the link to the
conforming version would conform.  Other options are also now provided
for times when the non-conforming page cannot contain a conforming

Regarding: Saying that Alternate Pages should only be used when
original versions cannot  - we have added "Note that providing an
alternate version is a fallback option for conformance to WCAG and the
preferred method of conformance is to make all content directly
Received on Sunday, 4 November 2007 04:32:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:45 UTC