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

Dear Loretta, Gregg, Michael Cooper,

Thank you for your sending resoltions regarding my comments on WCAG 2.0 WD.
And I'm sorry to be late for the reply dead line.

My comments on your resoltions are as follows.
I left my "Original Comment" and "Response from Working Group"
 and added my commend after each of your "Response from Working Group".

I was in a hurry and my comment this time will not be easy to understand.
I apologize in advance for my English.
 

>----------------------------------------------------------
>Comment 1: Grounds for "200%"
>Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0283.html
>(Issue ID: 2112)
>----------------------------
>Original Comment:
>----------------------------
>
>We have two questions on 1.4.4 and 1.4.7:
>
> Q1. Why "200%" and "50%"?
>
> Q2. Why do the authors have to be responsible for "200%"?
>
>
>We couldn't understand the reason why the authors should ensure that
>the "visually rendered text can be resized without assistive
>technology up to 200 percent and down to 50 percent". In the section
>of "Intent of this Success Criterion", it reads "The working group
>feels that 200% is a reasonable accommodation that can support a wide
>range of designs and layouts, ...". However there should be more
>concrete reason why the working group feels "200%" and "50%" are
>reasonable. Also we'd like to know this percentage can be applied to
>the characters in any other languages such as CJK languages.
>
>
>Additionally, all the authors have to do is to use relative
>measurements in order to make text resizable. Do these SC mean that
>the authors should provide the mechanism with users to resize text up
>to 200 percent and down to 50 percent? If so, it should be done by the
>user agents.
>
>Proposed Change:
>- Add the concrete reason why "200%"/"50%" and the sufficient grounds
>for any other languages than English. Or change these SCs to simply
>saying "Visually rendered text can be resized by the user agents
>without assistive technology."
>
>- Add the concrete reason why "authors" should be responsible for
>"200%" and "50%".
>
>---------------------------------------------
>Response from Working Group:
>---------------------------------------------
>
>The working group spent a lot of time discussing such options; in
>fact, some of our initial proposals looked very much like your
>suggestion, "Visually rendered text can be resized by the user agents
>without assistive technology." However, we discovered several
>problems.
>
>As text is scaled larger and larger, it becomes impossible to prevent
>loss of content or functionality. When horizontal text is enlarged
>beyond a certain level, text wrapping algorithms turn the text into a
>vertical column of words, possibly clipped if the word itself is too
>large to fit into the available horizontal space on screen. For
>vertical text, similar problems occur.
>
>Arbitrary resizing also introduces problems with testing. How does an
>author know when he has satisfied the success criterion, particularly
>for more sophisticated web pages that may change their layout  based
>on the text size to produce more readable results. An example would be
>a page that switches between single and multiple column text so that
>line widths stay within the ~16 word range recommended for some
>cognitive, learning, and language disabilities.
>
>So we felt that some choice of explicit values was necessary to make
>these success criteria testable. 200% was chosen after experimenting
>with various web pages that the working group felt were well designed,
>to see when scaling started to introduce problems. We also looked at
>the scaling supported directly by popular browsers. (IE's largest text
>scaling factor is only about 180%). And we looked at the support
>provided by screen magnifiers. For older screen magnifiers, 200% was
>the smallest scale factor that could be chosen. 50% was chosen to
>provide symmetry in the ranges. The ability to scale in both
>directions is desirable.
>
>We believe that there is a range of visual disabilities that can best
>be addressed directly and a range where the most effective solutions
>rely on assistive technology such as screen magnifiers. Other success
>criteria ensure that assistive technology can access the content
>successfully. These new success criteria identify the author's
>responsibility when supporting users where direct access is more
>effective.
>
>Note, by the way, that the success criteria don't require just scaling
>to 200% and 50%, but to all the values between. Our expectation is
>that solutions that work across that range will continue to work "as
>well as possible" beyond those limits.
>
>This is explained in the Intent Section of Understanding SC 1.4.4. The
>Working Group welcomes suggestions for ways to make this information
>clearer.

>---------------------------------------------
>My Comment:
>---------------------------------------------
I wonder if you have checked that this percentage can be applied to the characters in any other languages such as CJK languages as I mentioned in my original comment.

Thinking about Japanese, I can't imagine in what case loss of content or functionality happens.
I mean if we make text resizable.
 
For example, sentences in Japanese don't have "space" in between words and wrapping algorithms merely make the text into a vertical column of words.
Please check this in our company's web site.

-Hitachi(Japan site)
http://www.hitachi.co.jp/


Also the percentage "50%" is too small for at least Japanese language and if we make the text in 50% we can't recognize what is written because the text(character) sometimes very complicated and can be crashed.


So I again propose that 
>- Add the concrete reason why "200%"/"50%" and the sufficient grounds
>for any other languages than English. Or change these SCs to simply
>saying "Visually rendered text can be resized by the user agents
>without assistive technology."
>
>- Add the concrete reason why "authors" should be responsible for
>"200%" and "50%".


>----------------------------------------------------------
>Comment 2: How to measure dB(A) SPL and Tools
>Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0284.html
>(Issue ID: 2113)
>----------------------------
>Original Comment:
>----------------------------
>
>We'd like know how to measure the volume in dB(A) SPL. Are there any
>tools which alows the authors to measure the volume easily?
>
>Proposed Change:
>- Add how to measure the volume in dB(A) SPL
>
>- Introduce the tools for the authors to measure the volume in dB(A) SPL
>
>---------------------------------------------
>Response from Working Group:
>---------------------------------------------
>
>Technique G56 will answer questions for people who have a beginning
>knowledge of making audio. It introduces different way of determining
>audio contrast.
>
>There are three basic ways described in G56:
>1) Use an audio creation tool to measure the contrast as its being created.
>2) Listen to the examples (sufficient and failure) provided in G56 and
>test it that way.
>3) Measure the final wave form in an inexpensive (less than $100)
>audio program such as Cool Edit Pro.
>
>A separate tutorial is available which we will link to from the
>Additional Resources section of Technique G56. It provides a more in
>depth description of how to create and measure audio content on the
>web, as well as a discussion of popular tools used in the creation of
>audio for the Web and how to measure volume in dB(A) SPL. It is here:
>www.eramp.com/david/audio_contrast_general_techs.htm
>

>---------------------------------------------
>My Comment:
>---------------------------------------------
I understand your resolutions.
I haven't checked if there are any tools which can be used in Japanese, though.
I hope I can find any of them soon.


>----------------------------------------------------------
>Comment 3: Time Limit for Security/Access Control
>Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0285.html
>(Issue ID: 2114)
>----------------------------
>Original Comment:
>----------------------------
>
>There can be the time limit for:
>
>- the security reasons
>
>- the access control(system/network performance management)
>
>
>
>If the users are not allowed to turn off, adjust, and/or extend the
>time limit in such cases, what should the authors do? These cases also
>should be the exception.
>
>Proposed Change:
>Add the followings to GL 2.2.1
>
> - Security Exception: the time limit is  required for the security
>reason, and no alternative to the time limit is possible; or
>
> - Access Control Exception: the time limit is  required for the
>system/network performance management, and no alternative to the time
>limit is possible.
>
>---------------------------------------------
>Response from Working Group:
>---------------------------------------------
>
>Those situations were kept in mind when the current language was
>crafted. Use of time limits for security concerns relates to not
>leaving a terminal open. By asking if the user needs more time, you
>know that they are still present. So the extend provision would allow
>security concerns to be met.
>
>RE Access Control Exception:   There is a limit on the number of times
>a person can extend.  So access is eventually returned.  If the
>exception were allowed, then people who need 5 or 10 times more time
>to complete would never be able to.  The number of people who would be
>sitting on their terminals requesting more time at each time out is
>small enough that that it should not cause any problem in overall use
>of system resources.
>

>---------------------------------------------
>My Comment:
>---------------------------------------------
I understand you standing point.
But there still is a issue to be solved.

I wonder how we can check if a person in front of the terminal is the one who logged-in.
To extend the time limit, a person is asked to enter a password or something which identifies himself/herself?

I know it causes the problem to people who need to extend the time limit.
Because this action itself needs time and it consumes the time given to them from the system...

This kind of discussion happens quite often at the meeting with the clients from financial field.
When we are asked to make their web site meet level A, this SC will be a problem to us.


>----------------------------------------------------------
>Comment 4: Layout using CSS
>Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0289.html
>(Issue ID: 2118)
>----------------------------
>Original Comment:
>----------------------------
>
>In the last sentence within the "Description" section, it reads "When
>the source order does not match the visual order, the tab order
>through the content must reflect the logical relationships in the
>content that are displayed visually."
>
>What if the author positions the groups of the content in the
>different order than the source order by using CSS? For example, a web
>page contains the navigation bar and the main content. In the visually
>rendered order, the navigation bar is placed first in the content, the
>main content is placed second. However, in the source order, the main
>content is placed first and the navigation bar is placed second. In
>this case, the visually displayed order does not much the source
>order, but the tab order through the logical relationships and
>sequences make sense. Is this applied to G59 technique?
>
>---------------------------------------------
>Response from Working Group:
>---------------------------------------------
>
>Positioning different sections of the content via CSS would satisfy SC
>2.4.3, since focus would follow logical order within each section of
>the page, and there is no logical requirement that the sections be in
>any relative order. We have added such an example to Understanding SC
>2.4.3.
>
>We have also added a new success criterion at Level A that the focus
>order be consistent with the information and relationships conveyed
>through presentation. While there are sometimes several orders that
>would be consistent with the information and relationships conveyed
>through presentation, we do not feel that your proposed example would
>meet this new success criterion.
>

>---------------------------------------------
>My Comment:
>---------------------------------------------
I understand your resolutions.

>----------------------------------------------------------
>Comment 5: 3.2.3 should be Level A
>Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0292.html
>(Issue ID: 2121)
>----------------------------
>Original Comment:
>----------------------------
>
>3.2.3 Consistent Navigation: Navigational mechanisms that are repeated
>on multiple Web pages within a set of Web pages  occur in the same
>relative order each time they are repeated, unless a change is
>initiated by the user. (Level AA)
>
>
>
>It's safe to say that these SCs are the common practices in the web
>design and "support the ability of both mainstream and specialized
>user agents to adapt content to formats that meet their users' needs".
>
>Proposed Change:
>Move 3.2.3 to Level A.
>
>---------------------------------------------
>Response from Working Group:
>---------------------------------------------
>
>This is too broad a requirement to have at level A. There are reasons
>where it may be desirable, more usable and more understandable to
>change the order of the navigation elements from one page to another.
>This was level AA in WCAG 1.0 as well.
>

>---------------------------------------------
>My Comment:
>---------------------------------------------
I understand your resolutions.

>----------------------------------------------------------
>Comment 6: 3.2.4 to level A
>Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0296.html
>(Issue ID: 2125)
>----------------------------
>Original Comment:
>----------------------------
>
>3.2.4 Consistent Identification: Components that have the same
>functionality within a set of Web pages are identified consistently.
>(Level AA)
>
>It's safe to say that these SCs are the common practices in the web
>design and "support the ability of both mainstream and specialized
>user agents to adapt content to formats that meet their users' needs".
>
>Proposed Change:
>Move 3.2.4 to Level A.
>
>---------------------------------------------
>Response from Working Group:
>---------------------------------------------
>
>We consider it good news that this success criterion describes common
>practice in Web design, since it is very important to people with some
>types of cognitive, learning, and language disabilities.
>
>The success criterion's purpose is to support consistency in direct
>access to content by people who use conventional user agents, rather
>than providing additional support for alternate renderings via
>assistive technology.  And it does place more limits on visual
>presentation. For these reasons, we believe Level AA is the
>appropriate level.

>---------------------------------------------
>My Comment:
>---------------------------------------------
I understand your resolutions.

That's all.

Best regards,

Yukie Motomiya

Received on Tuesday, 20 November 2007 18:24:01 UTC