W3C

List of comments on “Techniques for WCAG 2.0” (dated 27 April 2006)

Quick access to

There are 94 comments (sorted by their types, and the section they are about).

1-20 21-40 41-60 61-80 81-94

question comments

Comment LC-776
Commenter: Joe Clark 3 <joeclark@joeclark.org> (archived message)
Context: F10: Failure of SC 2.1.1 due to combining multiple content formats in a waythat traps users inside one format type
Not assigned
Resolution status:

Comment (including rationale for any proposed change):

From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0121

Procedure

1. Using a keyboard, navigate through the content.
2. Check to see that the keyboard focus is not ""trapped"" and it is possible to move keyboard focus out of the plug-in content without closing the user agent or restarting the system.

What if this depends on the user agent, as it so often does? What if nothing the author can do will ever permit the user to escape from the trapping content? (This was a real example with accessible Flash.)

Proposed Change:
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

typo comments

Comment LC-477: > H63 Reference Typo
Commenter: Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived message)
Context: Document as a whole (Applicability)
assigned to Ben Caldwell
Resolution status:

Item Number: H63: Using the scope attribute to associate header cells and data cells in data tables...
Part of Item: Applicability
Comment Type: ED
Comment (Including rationale for any proposed change):

Technique H63 says it is referenced from SC 1.3.4.

It is actually referenced from SC 1.3.1

Proposed Change:

Change reference to SC 1.3.1.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-522: > G95 Test Typo
Commenter: Chris Ridpath <chris.ridpath@utoronto.ca> (archived message)
Context: Document as a whole (Tests)
assigned to Ben Caldwell
Resolution status:

Part of Item: Tests
Comment Type: QU
Comment (Including rationale for any proposed change):

Typo: "#1 and #2 are true"
There is only 1 check.

Proposed Change:

#1 is true
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-524: > H34 is referenced from SC 1.3.1 but it is not.
Commenter: Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived message)
Context: Document as a whole (applicability)
assigned to Ben Caldwell
Resolution status:

Item Number: H34: Using a Unicode right-to-left mark (RLM) or left-to-right mark (LRM) to mix text dire...
Part of Item: Applicability
Comment Type: ED
Comment (Including rationale for any proposed change):
Says H34 is referenced from SC 1.3.1 but it is not. It is referenced from SC 1.3.3

Proposed Change:
H34 could fall under both 1.3.1 and 1.3.3.

Add link to H34 on 1.3.1 or remove from \"applicability\". Add 1.3.3 to applicability or remove link to H34 from 1.3.3.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-553: > G18 expected results numbering typo
Commenter: Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived message)
Context: Document as a whole (Tests)
assigned to Ben Caldwell
Resolution status:

Item Number: G18: Ensuring that luminosity contrast of at least 5:1 exists between text ...
Part of Item: Tests
Comment Type: ED
Comment (Including rationale for any proposed change):
Procedure step #4 does not exist.

Proposed Change:
Renumber the steps or change the step number.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-554: > G17 Procedure Numbering
Commenter: Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived message)
Context: Document as a whole (Tests)
assigned to Ben Caldwell
Resolution status:

Item Number: G17: Ensuring that luminosity contrast of at least 10:1 exists between text...
Part of Item: Tests
Comment Type: ED
Comment (Including rationale for any proposed change):
Expected results - there is no point #4

Proposed Change:
Add other points or change number.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-765
Commenter: Joe Clark 3 <joeclark@joeclark.org> (archived message)
Context: Document as a whole
Not assigned
Resolution status:

Comment (including rationale for any proposed change):

From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0121

Incorrect CSS or usage

The Techniques document gives incorrect CSS in places, or simply gives unrealistic examples that don't match the practices of standards-compliant developers.

/* Rules for bidi */
HEBREW, HE-QUO {direction: rtl; unicode-bidi: embed}
ENGLISH {direction: ltr; unicode-bidi: embed}
/* Rules for presentation */
HEBREW, ENGLISH, PAR {display: block}
EMPH {font-weight: bold}

Each of those class names must begin with a dot (e.g., .HEBREW), and all-lower-case is preferred, as XML documents have [3]case-sensitive CSS parsing.

Proposed Change:
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-468: > Missing code markup
Commenter: Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived message)
Context: Document as a whole
assigned to Ben Caldwell
Resolution status:

Item Number: H51: Using table markup to present tabular information...
Part of Item: Description
Comment Type: ED
Comment (Including rationale for any proposed change):
Using the HTML table element... - "table" not marked as "code".

...the HTML pre element... - "pre" not marked as "code".

Proposed Change:
Mark the two words as "code".
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1519
Commenter: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be> on behalf of DocArch, Katholieke Universiteit Leuven (archived message)
Context: G134: Validating Web units (Examples)
Not assigned
Resolution status:

Part of Item: Examples
Comment Type: editorial
Comment (including rationale for proposed change):

In example 3, the double backslash in the dir attribute (and the explanation above it) should be a single forward slash.

Proposed Change:

Replace dev\\\\web (double backslash) with dev/web (single forward slash).
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

substantive comments

Comment LC-523: > H1 could fall under both 1.3.1 and 1.3.3
Commenter: Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived message)
Context: Document as a whole (applicability)
Not assigned
Resolution status:

Item Number: H1: Adding the dir attribute to a block level element to change its directionality...
Part of Item: Applicability
Comment Type: ED
Comment (Including rationale for any proposed change):

Says H1 is referenced from 1.3.1 but it's not. It is referenced from 1.3.3.

Proposed Change:

H1 could fall under both 1.3.1 and 1.3.3. Fix applicability so it falls under the appropriate SC.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1391
Commenter: Richard Ishida <ishida@w3.org> on behalf of I18N WG (archived message)
Context: Document as a whole (Tests)
Not assigned
Resolution status:

Comment from the i18n review of:
http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/

Comment 10
At http://www.w3.org/International/reviews/0606-wcag2-techniques/
Editorial/substantive: S
Owner: RI

Location in reviewed document:
H57, Tests

Comment:
Step 3 should say 'conforms to RFC 3066 or its successor', since RFC 3066 is now, already out of date, and RFC 3066bis should be used. Note that hopefully it will be possible to point to its successor very soon - we are awaiting the assignment of an RFC number.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-521: CONTRAST
Commenter: Liz Danaherliz <danaher@dwpdevelopment.net> (archived message)
Context: Document as a whole (Related Techniques)
Resolution status:

Name: Liz Danaher
Email: liz.danaher@dwpdevelopment.net
Affiliation:
Document: TD
Item Number: (none selected)
Part of Item: Related Techniques
Comment Type: TE
Comment (Including rationale for any proposed change):
Hi,

I hope you can help clarify something for me. I work on a UK government website and we\'ve recently been checking the site to ensure our colours comply with W3C checkpoint 2.2. We found your suggested algorithms here:
http://www.w3.org/TR/AERT#color-contrast
and subsequently found that some of our colours fail the algorithms for brightness and contrast. However, on checking your own site I also found that the w3.org homepage fails in some areas too.

eg. white text on biege background, brightness = 90 (fail), contrast = 306 (fail)

white text on blue background, brightness = 128 (ok), contrast = 362 (fail)

So I was just wondering, were you thinking of adding any caveats to the checkpoint 2.2, to reassure developers that if their font is above a certain size and/or weight then the algorithms may change. I do realise that you say it's only a "suggested algorithm" anyway, but I'm afraid our bosses are saying we must comply with it, and although our text is also bold and large like yours, we're facing having to redesign the whole colour scheme of our site.

I'd be very grateful if you could provide me with any more advice that you have on this subject so I can work out whether my colours are actually passable or not.

Thanks very much in advance!
Yours,
Liz Danaher

Proposed Change:
(EMPTY)
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1050: FONT
Commenter: Marco Bertoni <mbertoni@webaccessibile.org> (archived message)
Context: Document as a whole (clarifications about the terms "relative", "absolute" and "relative positioning")
Not assigned
Resolution status:

I think that we need some clarifications about the terms "relative", "absolute" and "relative positioning", expecially when they are used regarding both font sizing units and CSS positioning rules.

In the "Comparison of WCAG 1.0 checkpoints to WCAG 2.0" [1] appendix we can read:

In General (Priority 2):
3.4: Use relative rather than absolute units in markup language attribute values and style sheet property values.

that is is related to:

WCAG 2.0 Success Criteria:
This maps to an advisory technique (Using readable fonts) for Guideline 1.4.

Guideline 1.4 refer to visual and audio contrast [2] and I've not yet found, even in the "Techniques for WCAG 2.0", the advisory technique mentioned (Using readable fonts).

Even in the "CSS Techniques for WCAG 2.0" draft [2] - in which is correctly introduced the idea of "Using em or percent for properties that need to change" instead of "Use relative rather than absolute units..." - the corresponding guideline mentioned is "1.3" ...that refer to the separation of structure and presentation.

However, as Gregg Vanderheiden told: "Most advisory techniques have not been written yet".

Having said that, I must point up that using terms like "relative units", "absolute units" or "relative positioning" maybe somehow confusing.

I'll start from the following assumptions:

1) The general accessibility principle in question is that users (expecially partially sighted people) must be able to enlarge fonts using their visual UA tools.

2) Microsoft Internet Explorer 6 for Windows - and all the previous versions - is not able to enlarge text if it is sized in pixels. But pixels are "relative" lenght units (they are relative to the viewing device resolution) [4].

3) On the other hand there are some CSS absolute-size values that IE/WIN can perfectly enlarge: the absolute-size keywords (x-small, small, medium etc.) [5].

So, it is really confusing to advise CSS designers that they should use relative length units to size fonts.

CSS Techniques correctly tell us to "Use "em" or % for properties that need to change". But we should make another stride to avoid to mention a specific unit identifier: e.g. here in Italy, in our recent accessibility law [6], we have introduced a requirement (Requirement 12) that says: "The presentation and textual content of a page must be able to be adapted to the dimensions of the browser window used by the user, without superimposing objects present or loss of information such as to render the content incomprehensible, including in the case of resizing, enlargement or reduction of the display area or characters in relation to the predefined values of these parameters.". In other words, with this approach we say that the designer must size characters with a unit of his choice that guarantees the enlargement of text in every UA. This is expecially useful to ensure forward and backward compatibility. We cannot forget that, at the time of this writing, IE 6 cover almost all the market.

Cynthia Shelly suggested the term "scalable" to describe this text resizing function.

Summarizing, there are relative and absolute CSS units that are scalable (also in IE6/WIN):

1) for fonts: em, percentages and absolute-keywords (e.g. medium, small, x-small etc.)
2) for containers: percentages and em.

But we have to think about the near future when IE/WIN will be able to make pixels scalable. So we definitively should talk about *functions* rather than units, and I agree with Cynthia that "scalable" is the right term to use.

Therefore I suggest to tell designers something like "Use scalable units for CSS properties that need to change: font-size and line-height" rather than "Use these units...".

Directly following that we must also clarify the use of the phrase "relative positioning": when a CSS designer hear that words he think about a CSS rule like this: #box { position: relative; } [7]. But, in itself, a positioning scheme isn't related to accessibility.

When you talk about relative positioning I think that you mean a concept like "use liquid design" rather than a specific CSS positioning scheme. It is wrong to advise designers to use a specific positioning scheme. Instead, i.e., we should tell them that a liquid design is more accessible than a fixed design, no matter which technique they use to obtain that. Obviously we must first justify this suggestion!.

These terminological problems are really serious: I've hardly discussed, here in Italy, with tricky designers that keep on using their beloved pixels for text sizing because these are relative units as checkpoint 3.4 of WCAG 1.0 suggest (no matter if partially sighted people using IE/WIN cannot resize them).

Marco Bertoni
--
Referente Regionale IWA Liguria
International Webmasters Association ITALIA
Fax Verde: 800 12.64.96 - Web Site: http://www.iwa-italy.org

[1] http://www.w3.org/TR/WCAG20/appendixD.html
[2] http://www.w3.org/TR/WCAG20/guidelines.html#visual-audio-contrast
[3] http://www.w3.org/TR/WCAG20-CSS-TECHS/#syntax-data-types
[4] http://www.w3.org/TR/CSS21/syndata.html#length-units
[5] http://www.w3.org/TR/CSS21/fonts.html#font-size-props
[6] http://www.pubbliaccesso.it/normative/DM080705-A-en.htm
[7] http://www.w3.org/TR/CSS21/visuren.html#relative-positioning
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-656
Commenter: Johannes Koch <koch@w3development.de> on behalf of Evaluation tool developer (archived message)
Context: (none selected) in (Applicability)
Not assigned
Resolution status:

Part of Item: Applicability
Comment Type: GE
Comment (including rationale for proposed change):

I think it could be helpful for a web developer and evaluator to have the HTML techniques/failures sorted by what the techniques/failures are about, e.g. specific elements like img, area, etc. or concepts like lists, data tables, etc.

Proposed Change:

Add a list of HTML techniques/failures sorted by e.g. specific elements or concepts.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1404
Commenter: Richard Ishida <ishida@w3.org> on behalf of I18N WG (archived message)
Context: Document as a whole (Tests)
Not assigned
Resolution status:

Comment from the i18n review of:
http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/

Comment 23
At http://www.w3.org/International/reviews/0606-wcag2-techniques/
Editorial/substantive: S
Owner: RI

Location in reviewed document:
H62, Tests

Comment:
"the rp element is used to provide pronunciation information for user agents that do not support Ruby annotations"

This is misleading. It should say something like

"the rp element is used for user agents that do not support Ruby annotations to indicate that text in rt elements provides pronunciation information"
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-1383
Commenter: Richard Ishida <ishida@w3.org> on behalf of I18N WG (archived message)
Context: Document as a whole (H55 and H56)
Not assigned
Resolution status:

Comment from the i18n review of:
http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/

Comment 1
At http://www.w3.org/International/reviews/0606-wcag2-techniques/
Editorial/substantive: S
Owner: RI

Location in reviewed document:
H55, H56

Comment:
It is not clear to us why correct support of the 'direction of the text' is an accessibility issue. We recommend that you remove all mention of text direction from this document.


This would include F5, H1, H34, H56, H55


(If you disagree with this recommendation, we will come back to you with a substantial number of additional comments based on the content of this document related to text direction, and probably recommend that i18n WG needs to be involved in drafting that text. For now we will hold all such comments until this one is addressed.)
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-665
Commenter: Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived message)
Context: (none selected) in (Applicability)
assigned to Becky Gibson
Resolution status:

Part of Item: Applicability
Comment Type: GE
Comment (including rationale for proposed change):

There needs to be a technique the describes how to include words within an image in the alternate text.

Proposed Change:

All text within the image that is relative to the document should be included in the alternate text. Relates to technique H36 and others.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-775
Commenter: Joe Clark 3 <joeclark@joeclark.org> (archived message)
Context: Document as a whole
Not assigned
Resolution status:

Comment (including rationale for any proposed change):

From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0121

Procedure

1. View the material with captioning turned on.
2. Check that all dialog is accompanied by a caption.
3. Check that all important sounds are captioned.

And how does a deaf person do this?

Proposed Change:
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-666: TEST-TASK-FORCE
Commenter: Chris Ridpath <chris.ridpath@utoronto.ca> on behalf of ATRC University of Toronto (archived message)
Context: Document as a whole (Applicability)
Not assigned
Resolution status:

Part of Item: Applicability
Comment Type: GE
Comment (including rationale for proposed change):

None of the tests are expressed as testable statements. None of the tests have examples.
Tests already exist at:
http://www.w3.org/WAI/GL/WCAG20/tests/

Proposed Change:

Express the tests as testable statements. Include example files.
Use the existing tests.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-764: Text-Alternatives
Commenter: Joe Clark 3 <joeclark@joeclark.org> (archived message)
Context: F38, F39, H67 in (F38, F39, H67)
Not assigned
Resolution status:

Comment (including rationale for any proposed change):

From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0121

Text equivalents

alt="" "" is officially permitted alongside the actually correct alt="""".

Proposed Change:
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

1-20 21-40 41-60 61-80 81-94

Add a comment.


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: Overview.php,v 1.46 2013-10-04 08:11:33 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org