Re: Comments on WCAG2 Draft June 30/05

Dear Greg,

Thank you for your comments on the 30 June 2005 Working Draft of WCAG
2.0. A list of issues related to comments you have made is available at:
<http://trace.wisc.edu/bugzilla_wcag/buglist.cgi?keywords=Greg_Gay>

If you follow the above link, the issues will be displayed in a table
with links to each issue. If you prefer to see the contents of each
issue as a single report, please select the "Long Format" button at the 
end of the list of issues. If you have any questions about the issues 
list interface, please let us know.

Thank you for your patience while the WCAG WG responds to the variety
of comments we received on this last Working Draft.

All the best,

-Ben

--
Ben Caldwell | <caldwell@trace.wisc.edu>
Trace Research and Development Center <http://trace.wisc.edu>

Greg Gay wrote:
> 
> July 28,05 WCAG 2.0 Comments  on Draft June 30/05
> 
> 1. ...should WCAG 2.0 have 2 or 3 levels of conformance?
> 
> There are many reasons why a three level conformance framework should
> be maintained.
> 
> For a transition from WCAG 1.0 to WCAG 2.0  that will be easy to 
> comprehend for content developers, evaluators, and clients who are 
> currently accustomed to the "required, should, could" notions that
> give concrete meaning to priority levels, a three level structure
> should be used using similar or the same associated meanings. There
> are still things that "must" be done or content  will be inaccessible
> to a particular group. There are things that "should" be done, or
> some groups are going to have a difficult time accessing content, but
> where accessing content is otherwise possible. There are things that
> "could" be done to improve usability beyond what might be considered
> technically accessible.
> 
> There are cases in the WCAG 2 draft where current level 3 success 
> criteria are relatively difficult or unnecessary to implement, and as
> a result would prevent many sites from conforming with Level 2
> guidelines should the guidelines be moved from level 3 to level 2.
> For  example, guideline 3.1 Level 3 #1 "A Mechanism is available for
> finding definitions for all words..." is not something most sites
> would implement. A glossary is more likely to be implemented for
> specific keywords, though still relatively rare, but for definitions
> for all words a full dictionary would need to be available. Very few
> site would thus be able to comply with level 2. If a person needs a
> dictionary there are many such sites available on the Internet. There
> is no reason why every site that wishes to comply with Level 2
> guidelines has to have their own dictionary. I don't think requiring
> a dictionary should be a requirement at any level.
> 
> Likewise, if a site is specifically targeting post secondary students
> or a professional audience,  providing a summary, graphic, or spoken
>  version at a lower education level is generally unnecessary (re: 
> guideline 3.1 Level 3 #5). As a result such a level 2 requirement
> would prevent most post secondary sites from attaining Level 2
> conformance. The audience being addressed might be included in the
> baseline, and this guideline adjusted to reflect accommodations for
> that particular audience, rather than an outright requirement that
> all content needs to be readable by all, or have a summary with
> primary level language.
> 
> I'd vote for sticking with the meanings currently associated with 
> priority levels of WCAG 1.0, and go with three levels of success 
> criteria in WCAG 2.0. Grouping all current level 2 and level 3 
> guidelines into one level is going to blur the importance of the
> current level 2 guidelines. It will discourage content developers
> from attempting to go beyond the basic accessibility of level 1, if
> level 2 is generally unattainable for average content developers.
> 
> 2. Should a validity success criterion be addressed at Level 1 or
> Level 2 (refer to "Validity and Accessibility" for a summary of
> recent discussion)?
> 
> While I certainly think validity is a reflection of quality, and in
> all our work validation is a key step in our development process, I
> tend to agree that it should not be the responsibility of the WCAG to
> police the validation of Web documents. Though intended as
> recommendations, as noted, WCAG does end up being the basis for
> policy, and a requirement for valid markup is going to have serious
> legal and financial consequences for those bound by policies based on
> WCAG.
> 
> When we evaluate Web sites virtually all fail the validity check. 
> Sometimes they might fail by simple omission or perhaps a  typo or
> two, such as  the odd broken tag on a few pages within a larger site.
> Other times sites are a mess with broken markup throughout. In the
> latter case there will likely be accessibility problems as a result
> of the invalid markup, but in the former the minor markup errors will
> likely have no affect at all. There is no clear line between validity
> that affects accessibility, and validity that does not. WCAG's
> primary concern should only be with validity issues that do affect
> accessibility, not with validity in general.
> 
> If validity is to be a Level 1 success criteria, a distinction would
>  have to be made between markup errors that are proven to be 
> accessibility barriers (these will differ across user agents, and
> will change over time), and errors that do not affect accessibility.
> How one would go about making the distinction I do not know. Given
> individual errors may not cause accessibility problems, but
> combinations of errors often do, documenting Level 1 and Level 2
> validation errors would likely not be possible without a major
> effort. Then checking for those errors, or combinations thereof, is
> also going to be difficult to accomplish.
> 
> If the validity requirement is made a Level 1  criteria, it will be
> the single most difficult hurdle to conformance, and given that in
> most cases where invalid markup is encountered there is no affect on
>  accessibility, making a general requirement that all markup be valid
>  would be problematic This would be particularly true for dynamic
> sites where information changes regularly or where user contributed 
> information is collected. As a Level 2 requirement, at least these
> sites could claim a consistent level 1 conformance. They may never be
> able to claim conformance if validity is listed as a level 1
> requirement.
> 
> My vote is to leave validation a Level 2 success criteria, though
> within a three level (required, should, could) conformance framework.
> 
> 
> 
> Baseline!!! Great idea! Audience needs to be added to the baseline in
>  addition to technologies. See below re: guideline 3.1 Level 3 #5, 
> particularly important if level 3 guidelines are merged with level 2.
> 
> 
> 1. Technology assumptions and the baseline
> 
> I realize these two examples are informative, but they have the 
> potential to create confusion through multiple interpretations.
> 
> Example 2 "...supported by more than one accessible and affordable
> user agent for more than one release."  The word release is a
> relative term. Release cycles vary greatly for different software.
> Does this include major and/or minor releases (e.g. feature release
> vs a bug fix release). What about where only one accessible user
> agent exists, like Internet Explorer was for the longest time. Use
> words like "readily available user agent" rather than "more than
> one."  The words "readily available" could also remove multiple
> interpretation of the word "release". A definition of the phrase
> "readily available" could be added to the glossary, with a definition
> something like "...with minimal effort  is attainable by searching
> the Internet."
> 
> Example 3 "... to reflect the increased ability of affordable user
> agent (including assistive technology)..." I might ask "are there
> affordable assistive technologies?" thinking about the current cost
> of screen readers. The affordability of assistive technologies is
> relative to a person's income, or the availability of funding to them
> (in Canada funding is available every five years), so this leaves
> room for many different interpretations.  Perhaps replace
> "affordable" with "readily available."
> 
> Conformance Claims Regarding #2 of the information that must be
> included with a conformance claim, "... a list of one or more URIs
> ...". In the case of a Web application, a base URI may not be
> available. For example, our Web applications claim AA conformance,
> but they do not reside at any specific URI, but rather at many URIs
> where users have installed the software, or at open source
> repositories that distribute the software. The applications exist as
> archived bundles of  software, that when unpacked  and installed on a
> user's Web site, will conform with WCAG AA specifications.
> 
> Or, could the URI perhaps be a download location of the primary
> software distribution. Perhaps yes, but this did not seem immediately
> apparent when I read it the first time (thinking to myself aloud).
> The definition of  "delivery unit" might include mention of a
> "software package" or "software archive". A Web application
> distributed by CD may not have an associated URI at all, but may
> otherwise be conformant. The #2 requirement should also include
> something like "...or a software version identifier where a URI is
> not available."
> 
> Also with regard to conformance claims, a date on which the claim was
>  made should also be included.  For Web sites that are continually 
> changing, the accessibility of the site may vary from day to day. For
>  the protection of human evaluators who find a site to be conformant,
>  then are brought to task a month later, for example, when the
> evolving site is found to no longer conform, a "date of conformance"
> is required. The only case where a conformance claim remains valid
> indefinitely, which would be assumed if no date were specified, is
> when the content of a web site does not change (which relatively is
> rare).
> 
> Similarly a claim of conformance could be made on one version of a
> Web application, and be carried over to later versions of the
> software, which are perhaps not conformant if a date of conformance
> or software version identifier is not associated with the claim.
> 
> Principle 1: Level 1 Success Criteria for Guideline 1.1 While I do
> believe all meaningless non-text elements should have a text 
> alternative, success criteria 1.1 #4 is not a critical accessibility
>  issue, and thus does not warrant a level 1 rating. If the image does
> not convey meaning, assistive technologies announcing the filename
> disrupts comprehension of the page being read, but it does not
> prevent a user from accessing the content of the page as would a
> missing text alternative  for non-text content that does contain
> meaningful information. Perhaps include this item as a level 2
> success criteria which is describe as a "should" do item to make it
> less difficult to access the content in question.
> 
> Guideline 1.2 1.a A text transcript should be required at level 1 to
> accommodate those using technology that does not read the captions in
> a particular user agent. 1.b I agree that adding captioning is
> effortful, and may ultimately be seen as "undue hardship" in the eyes
> of the courts, and thus be ignored altogether. If the transcript is
> required at level 1, there will always be a text alternative. Given
> transcripts are fairly easy to create, undue hardship could never be
> a defense for not include a text alternative.
> 
> There could also be reference to "readily available" for the above
> with regard to captioning software, in which case it may be more
> reasonable to leave captioning as a level 1 success criteria.
> 
> 
> 2. Audio descriptions may also fall under the "undue hardship"
> category if maintained as a level 1 success criteria. Also, there is
> a question of subjectivity in what requires an audio description, and
> the capacity to include audio descriptions where the video does not
> have sufficient breaks into which it can be inserted. Including a
> text version of the audio descriptions as part of a transcript as
> mentioned for 1a above as a level 1 criteria,  would assure that an
> alternative exists in some form.
> 
> *While I think of the "undue hardship" clause as a poor defense in
> most cases, if the effort required to add synchronized captioning and
>  descriptive audio (particularly descriptive audio, and extended
> audio descriptions) approaches a significant cost within the overall
> cost of producing the video, courts are likely to favor the undue
> hardship argument. Captioning and descriptive audio as level 2 items,
> and transcripts of audio and video tracks as level 1, would remove
> the undue hardship defense.*
> 
> Guideline 1.3 The association between guideline 1.3 and its examples
> is not immediately apparent. While each example represents some
> implementation of structure, how they represent separation from
> presentation is not clear.  Example #2 re associating table headers
> with data cells might fit better into Guideline 2.4, where structure
> is more thoroughly covered.
> 
> Guideline 1.4 Guideline 1.4 does not seem general enough, specifying
> images or sound, but not colour (though colour is mentioned is the
> level 1 success criteria). (i.e. "Make it easy to distinguish
> foreground information from background images or sounds)." Perhaps
> the words "images or sounds" should be replaced with "information" to
> make the guideline more general.
> 
> Level 1 success criteria for guideline 1.4 seems a little weak,
> though unless the algorithm of level 2 #1, to measure contrast
> between foreground and background colours, comes about before the
> release of WCAG 2, there's probably nothing better than
> "programmatically determined" colours so users agents can make
> adjustments as required. The problem is colours can be
> programmatically determine with relative ease in most cases, but
> there is no mention of contrast between foreground and background
> colours in level 1. Presenting bright yellow on a white background
> for example, would not violate this guideline if the colours were
> explicitly defined as an attribute or style, but the text would be
> inaccessible to most people who are not using an assistive technology
> that reads colour attributes;   essentially disabling otherwise fully
> able users.
> 
> Perhaps it would be more effective here to "...ensure that foreground
>  and background colours can be overridden by the reader," which is 
> perhaps what "programmatically determined" means in this case.
> Perhaps include an example for Guideline 1.4 that describes the
> ability to override presentation styles would add clarity to the
> level 1 criteria, and an example of foreground background readability
> (or non-readability as the case may be).
> 
> Principle 2 Guideline 2.4 Level 2 Success Criteria #1. Similar to the
> timed content 2.2 Level #1 guideline  "...without invalidating the
> activity" could be used here as well, with reference to providing
> alternate paths for navigating content. For example "More than one
> way is available to locate content within a set of delivery units 
> except where non-sequential navigation would change the intended
> outcome of an activity".
> 
> 2.4 Level 2 #2  might also include reference to bypassing large
> blocks of data (i.e. data tables). Similarly, things like an
> alphabetized browse menu for a glossary can use bypass links. These
> might be better referred to in examples.
> 
> 2.4 ... who benefits. It's not clear to me what the following means
> in the Who Benefits section of guideline 2.4: "Individuals with
> cognitive disabilities may find it easier to ask for what they want
> than to deduce its location from categorical choices." particularly
> the word "ask" as it relates to mechanisms to find, orient, and
> navigate Web content. Structures like headings for example, are more
> apt to draw users with cognitive disabilities to categorical
> information that aids in comprehension, like that described for blind
> users above "... jumping from header to header to get an overview or
> to more quickly skim...". Most people, including those with cognitive
> disabilities, can benefit from the summary information structures
> provide, for comprehension and learning.
> 
> Principle 3
> 
> In Who benefits from Guideline 3.2, reference to difficulty
> interpreting visual cues here, and in the Who benefits section for
> 3.1, are only remotely representative of dyslexics. Dyslexia is
> specifically associated with difficulties making letter to sound
> correspondences (i.e. phonemic awareness). With regard to having
> difficulty interpreting visual cues, WCAG should perhaps refer to
> dyspraxia, or better to non-verbal learning disability. Though not
> specifically associated with difficulties interpreting visual cues,
> these latter disabilities are more likely to include them. Dyslexics
> as a group tend to be good at interpreting visual cues, with visual
> difficulties occurring only when multiple disabilities are present.
> 
> For guideline 3.1 a Level 2 success criteria might be added to
> suggest using meaningful link text (i.e. navigation controls), or
> provide context that allows users to infer meaning where the link
> text is otherwise meaningless. In the latter case for example, a link
> to a full article via its title, followed by a link with the link
> text "more" provides context for the otherwise meaningless word
> "more." This is likely HTML specific so it might fit as an example
> for a more general requirement the interface controls be meaningful.
> 
> Principle 4 Guideline 4.2 Level 1 item 1 suggests that alternatives
> are preferable over making the original Web content accessible in the
> first place. Rather than "If content does not meet all level 1
> success criteria..." use "If content can not be authored to meet all
> level 1 success criteria..."
> 
> Guideline 4.2 Who benefits, the first statement and its list items
> seem redundant. The statement might read better as "Authors who
> address accessibility during the design stage of content development,
>  will:"...to distinguish between designing for accessibility and 
> retrofitting for accessibility.
> 
> Guideline 4.2 Use of relative measures should be a level 2 success 
> criteria. There might include an example that mentions relative
> measure for defining layout and font sizing. If fonts must be marked
> up in a way that allows them to be increased in size  for those with
> low vision, the layout elements must also be included in this
> requirement so as the font size increases, the surrounding containers
> also increase in size, so one does not end up with a paragraph
> displayed as a single column of words for  example. Similarly,
> relative sizing could be used to define image sizes (16px = 1 em) so
> images also increase in size relative to the fonts and their
> containers, and the symmetry of the screen is maintained.
> 
>

Received on Monday, 29 August 2005 17:19:46 UTC