Re: Your comments on WCAG 2.0 Last Call Working Draft of December, 2007

sorry for being late in my reply.

we agree to all your replies with one exception:

Comment 4: 200% seems too ambitious (Issue ID: 2443)
http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0065.html

the answer was not sufficient for us because it did not take our 
argument about the missing base level of text size fully into account:

> It also seems inconsistent to require text to be scalable to a certain extent
> without taking into account the base level (original size of text). Otherwise
> it would be of advantage for websites with very small text-sizes.

for example: you are using a browser which does not scale the full page 
(ie6 or firefox 2). its easier to build a multi column page-layout with 
10px font-size scalable up to 200% than with 16px default font-size. 
this might force webdesigners to develop web sites with very small 
font-size to conform with wcag-scalability. therefore this might have a 
counterproductive effect regarding accessibility and usability.

therefore we think that it needs a base or reference level for text size 
either for the unscaled text or for the scaled text.

if you have any further questions regarding this subject don't hesitate 
to contact me.

best regards, michael stenitzer

Loretta Guarino Reid wrote:
> Dear Michael Stenitzer,
> 
> Thank you for your comments on the 11 Dec 2007 Last Call Working Draft
> of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0
> http://www.w3.org/TR/2007/WD-WCAG20-20071211). The WCAG Working Group
> has reviewed all comments received on the December draft. Before we
> proceed to implementation, we would like to know whether we have
> understood your comments correctly and whether you are satisfied with
> our resolutions.
> 
> Please review our resolutions for the following comments, and reply to
> us by 31 March 2008 at public-comments-wcag20@w3.org to say whether
> you accept them or to discuss additional concerns you have with our
> response. Note that this list is publicly archived.
> 
> 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 10 March 2008 at
> http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20080310/.
> 
> Note that if you still strongly disagree with our resolution on an issue,
> you have the opportunity to file a formal objection (according to
> 3.3.2 of the W3C Process, at
> http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews)
> to public-comments-wcag20@w3.org. Formal objections will be reviewed
> during the candidate recommendation transition meeting with the W3C
> Director, unless we can come to agreement with you on a resolution in
> advance of the meeting.
> 
> Thank you for your time reviewing and sending comments. Though we
> cannot always do exactly what each commenter requests, all of the
> comments are valuable to the development of WCAG 2.0.
> 
> 
> Regards,
> 
> Loretta Guarino Reid, WCAG WG Co-Chair
> Gregg Vanderheiden, WCAG WG Co-Chair
> Michael Cooper, WCAG WG Staff Contact
> 
> On behalf of the WCAG Working Group
> 
> ----------------------------------------------------------
> Comment 1: GL 2.2: Refering to "users" vs. "users with disabilities"
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0062.html
> (Issue ID: 2440)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
> 
> It seems to me, that the guidelines are generally referring to "users"
> and in a few other cases to "users with disabilities".
> 
> Proposed Change:
> I would propose to change this to "users".
> 
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
> 
> We have have changed "users with disabilities" to "users" in 2.2 and 2.4.
> 
> ----------------------------------------------------------
> Comment 2: GL 2.4: Refering to "users" vs. "users with disabilities"
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0063.html
> (Issue ID: 2441)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
> 
> It seems to me, that the guidelines are generally referring to "users"
> and in a few other cases to "users with disabilities".
> 
> Proposed Change:
> I would propose to change this to "users".
> 
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
> 
> We have have changed "users with disabilities" to "users" in 2.2 and 2.4.
> 
> 
> 
> ----------------------------------------------------------
> Comment 3: Cross reference for SC of different conformance level
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0064.html
> (Issue ID: 2442)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
> 
> Please provide referrers (eg. in the form of cross references) for
> different conformance levels of the same topic.
> 
> eg: Audio Description in SC 1.2.2. (Level A), SC 1.2.4 (Level AA) and
> SC 1.2.6 (Level AAA).
> 
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
> 
> We are adding cross references between related success criteria in the
> Understanding WCAG 2.0 Document.
> 
> In the guidelines themselves they are only a short distance apart and
> have the very similar or the same short name (differing only by the
> parenthetical in most cases).  We decided to not add "see xxx" notes
> to requirements that are close to each other in the guidelines because
> it adds to the complexity of the document, and seemed less important
> when things are right next to each other.
> 
> ----------------------------------------------------------
> Comment 4: 200% seems too ambitious
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0065.html
> (Issue ID: 2443)
> Status: VERIFIED / NOT ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
> 
> 200% seems too ambitious for Level AA.
> 
> Note: a quick check of accessible Austrian and German websites showed
> that only a small share would pass this SC.
> 
> It also seems inconsistent to require text to be scalable to a certain
> extent without taking into account the base level (original size of
> text). Otherwise it would be of advantage for websites with very small
> text-sizes.
> 
> This note also applies to SC 1.4.8. (last bullet)
> 
> Proposed Change:
> We would propose to differentiate between Level AA (150%) and Level AAA (200%).
> 
> It could be possible to refer to the standard text size of the user
> agent (reference level: 100% of the default text size of the user
> agent). (This has to be discussed further).
> 
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
> 
> Success Criterion 1.4.4 requires that the web technology is being used
> in a way that permits some text resizing without the use of assistive
> technology. 200% was chosen as the lowest magnification provided by
> older screen magnifiers; hence users who need magnification up to that
> point would need to rely on the user agent.
> 
> SC 1.4.4. can be satisfied by zoom functionality, which magnifies
> everything on that page, or by text resize functionality, which
> increases the size of the text and may cause the page to be laid out
> differently. Using a small or large default font size should not make
> this success criterion any more or less difficult to satisfy.
> 
> We are surprised by your statement that only a small share of Austrian
> and German websites would pass this SC, since any HTML website that
> uses relative measures should pass.
> 
> SC 1.4.8 can be more difficult to meet, since it requires that the
> resizing be supported without requiring horizontal scrolling. In this
> case, the default text size may affect how difficult it is to meet
> this success criterion. There are some types of content for which it
> may not be possible to meet this SC. This is the reason it is included
> at level AAA.
> 
> ----------------------------------------------------------
> Comment 5: paragraph spacing is larger than line spacing
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0066.html
> (Issue ID: 2444)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
> 
> If line spacing is 1.5 and paragraph spacing is 1.51 this SC is met,
> but this setting certainly does not improve the readability or visual
> presentation.
> 
> Proposed Change:
> So either you require a considerable larger paragraph spacing (eg.
> half the text size larger than the line spacing, ie. 2.0 times the
> text size) or you write "at least the line spacing" to be clear.
> 
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
> 
> The Success Criterion already requires that the paragraph spacing be
> more than the line spacing. So, we changed it slightly to say:
> 
> "line spacing (leading) is at least space-and-a-half within
> paragraphs, and paragraph spacing is at least 1.5 times larger than
> the line spacing."
> 
> ----------------------------------------------------------
> Comment 6: When is a change of content a change of context
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0067.html
> (Issue ID: 2445)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
> 
> Provide additional examples for a "change of context". This is a very
> abstract concept and it might not be clear when a change of content
> within a web page is a change of context.
> 
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
> 
> We have updated the list to the following:
> 
> Example: Opening a new window, moving focus to a different component,
> going to a new page (including anything that would look to a user as
> if they had moved to a new page) or significantly re-arranging the
> content of a page are examples of changes of context.
> 
> ----------------------------------------------------------
> Comment 7: scaling of line-height and containers-heights
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0068.html
> (Issue ID: 2446)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
> 
> Additional failures:
> 
> If text is resized and line-height or container-heights do not scale
> in the same way, text may be covered or truncated.
> 
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
> 
> That situation is covered by the phrase "without loss of content or
> functionality."
> 
> We also have a failure of 1.4.4 that specifically covers this:
> 
> F69: Failure of Success Criterion 1.4.4 when resizing visually
> rendered text up to 200 percent causes the text, image or controls to
> be clipped, truncated or obscured
> 
> ----------------------------------------------------------
> Comment 8: Making links visually distinct
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0069.html
> (Issue ID: 2447)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
> 
> "Making links visually distinct": this does not seem to be required
> anywhere else. Making links visually distinct "foremost in blocks of
> text" is an important precondition for making hyperlinks usable.
> 
> Proposed Change:
> Make this a sufficient technique: links visually distinct in blocks of text.
> 
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
> 
> That is true.  We have covered most of the key aspects of this
> elsewhere but wanted to add this advisory technique to remind people
> to do all that they could, even beyond the other guidelines.
> 
> Of course, if the links are invisible to everyone for some reason,
> then it is not required that they be visible to people with
> disabilities.
> 
> However if the links ARE visible to others, the color provision
> (1.4.1) and the contrast provisions (1.4.3 and 1.4.6) require that
> they be visible to those with disabilities.
> 
> ----------------------------------------------------------
> Comment 9: Example "A help dialog ..."
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0070.html
> (Issue ID: 2448)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
> 
> "A help dialog ...": the description of this example is not clear.
> 
> Proposed Change:
> Improve the description of the problem.
> 
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
> 
> This was meant to say that moving to a control caused a dialog window
> to open that grabbed focus away from the window with the control. This
> was not clear so we have changed this to read
> 
> Example of a Failure: A help dialog
> 
> When a field receives focus, a help dialog window describing the field
> and providing options opens. As a keyboard user tabs through the Web
> page, the dialog opens moving the keyboard focus away from the control
> every time the user attempts to tab past the field.
> 
> ----------------------------------------------------------
> Comment 10: lists for accessibility supported technologies
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0071.html
> (Issue ID: 2449)
> Status: VERIFIED / ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
> 
> What will be the expected process after publishing WCAG 2.0 as a
> (candidate) recommendation? Do we have to wait for the availability of
> lists for accessibility supported technologies? What is the
> recommended approach for web developers until there are such lists of
> trustworthy and/or official institutions available? Are there any
> known organisations that are already preparing such lists?
> 
> I see the risk that many institutions will ignore the requirement #5
> of a conformance claim, until such lists will be published together
> with the guidelines or by a governmental body.
> 
> Proposed Change:
> Please elaborate the expected process in the WCAG 2.0 FAQs (or somewhere else).
> 
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
> 
> The working group recognizes that the need for information on which
> technologies are 'accessibility-supported' is important to use of the
> guidelines.
> 
> Such data can only come from testing different versions of user
> agents and assistive technology and recording whether the features of
> the technology are supported. We expect that this information may
> need to be compiled from multiple sources. WAI will be working with
> others to establish an approach for collecting information on the
> accessibility support of various technologies by different user
> agents and assistive technologies.
> 
> WCAG 2.0 is still in development. We expect that during Candidate
> Recommendation period we will have some initial information on
> accessibility supported technologies, to demonstrate how this
> approach will work once WCAG 2.0 becomes a W3C Recommendation.
> 
> The Candidate Recommendation process itself requires that there be
> examples that demonstrate conformance. So there will certainly be some
> information about accessibility supported technologies in order to get
> out of the candidate recommendation stage for WCAG 2.0.
> 
> ----------------------------------------------------------
> Comment 11: HTML Version of Understanding WCAG with semantic classes and IDs
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0073.html
> (Issue ID: 2451)
> Status: VERIFIED / NOT ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
> 
> Please provide semantic classes and IDs as in the quick reference to
> allow automatic formatting selection mechanisms to work with
> Understanding WCAG 2.0 like in the quick-reference.
> 
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
> 
> This is an interesting idea and we fully expect a variety of materials
> and ideas to emerge to help educate people about WCAG 2.0 and make the
> supporting documents easier to use. However, it is beyond the scope of
> the working group to develop some of these resources at this time.
> 
> Once the Guidelines are completed, we will be turning our attention
> toward developing techniques and will be collaborating with Education
> and Outreach to develop additional instructional materials. We would
> be happy to hear more about your ideas for customizing the
> Understanding document for consideration in a future version.
> 
> ----------------------------------------------------------
> Comment 12: Information on current location conformance level change
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Jan/0074.html
> (Issue ID: 2452)
> Status: VERIFIED / NOT ACCEPTED
> ----------------------------
> Original Comment:
> ----------------------------
> 
> We think the conformance level of this Success Criterioin is  too low,
> because it is a almost standard to have location information on
> websites, for example bread crumbs, and for users with screen readers
> it would be a lot easier to know the current location.
> 
> Proposed Change:
> Change Level from "AAA" to "AA"
> 
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
> 
> There is a wide variety of content on the Web. Some are navigation
> pages and breadcrumbs are common there.  Other content is copies of
> documents - and breadcrumbs cannot be added to these. In fact, many
> documents cannot be altered to include position information.   Also,
> there are many paths that may be taken to any point. If the person
> lands on a page via search, it is not clear how one would say where
> they were in the site if there were many paths to this page.
> 
> Since this cannot be applied to all pages, it is at level AAA.
> 
> ----------------------------------------------------------
> Comment 13: Process for accessibility-supported technologies
> Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2008Feb/0132.html
> (Issue ID: 2579)
> Status: VERIFIED / PARTIAL/OTHER
> ----------------------------
> Original Comment:
> ----------------------------
> 
>> dear editors,
>>
>> The Austrian association "accessible media" has the following question
>> about the ongoing process for a WCAG 2.0 recommendation.
>>
>> What will be the expected process after publishing WCAG 2.0 as a
>> (candidate) recommendation? Do we have to wait for the availability of
>> lists for accessibility supported technologies? What approach will you
>> recommended for web developers until there are such lists of trustworthy
>> and/or official institutions available? Are there any known
>> organisations that are already preparing such lists?
>>
>> We see the risk that many institutions will ignore the requirement #5 of
>> a conformance claim, until such lists will be published together with
>> the guidelines or by a governmental body.
>>
>> Please elaborate the expected process in the WCAG 2.0 FAQs (or somewhere
>> else).
>>
>> best regards
>> michael stenitzer
> 
> ---------------------------------------------
> Response from Working Group:
> ---------------------------------------------
> 
> The working group recognizes that the need for information on which
> technologies are 'accessibility-supported' is important to use of the
> guidelines.
> 
> Such data can only come from testing different versions of user
> agents and assistive technology and recording whether the features of
> the technology are supported. We expect that this information may
> need to be compiled from multiple sources. WAI will be working with
> others to establish an approach for collecting information on the
> accessibility support of various technologies by different user
> agents and assistive technologies.
> 
> WCAG 2.0 is still in development. We expect that during Candidate
> Recommendation period we will have some initial information on
> accessibility supported technologies, to demonstrate how this
> approach will work once WCAG 2.0 becomes a W3C Recommendation.
> 
> The Candidate Recommendation process itself requires that there be
> examples that demonstrate conformance. So there will certainly be some
> information about accessibility supported technologies in order to get
> out of the candidate recommendation stage for WCAG 2.0.
> 
> In the interim, testing the technologies and techniques used on a site
> with AT could be used.  Although this is always a good idea it is
> burdensome so most people will want to use lists when they become
> available.  If you are doing work in this area, particularly around
> media, please contribute any information that you have about
> accessibility support for media technologies. Organizations can create
> their own lists of accessibility supported content technologies if
> public lists are not available. This should be done in good faith with
> appropriate testing.


-- 
Michael Stenitzer | WIENFLUSS information.design.solutions
www.wienfluss.net | proschkogasse 1/5 | vienna AT
fon ++43 650 9358770 | fax ++43 1 23680199

Received on Wednesday, 2 April 2008 16:33:15 UTC