W3C home > Mailing lists > Public > w3c-wai-er-ig@w3.org > May 2000

Kynn's Feedback on AERT 26 April 2000 Draft

From: Kynn Bartlett <kynn@idyllmtn.com>
Date: Mon, 22 May 2000 14:20:51 -0700
Message-Id: <a04310109b54f54f86514@[]>
To: w3c-wai-er-ig@w3.org
Feedback on "Techniques for Accessibility Evaluation and Repair Tools"
By Kynn Bartlett <kynn@edapta.com>
Director of Accessibility, Edapta Inc.
22 May 2000

These comments are based on the 26 April 2000 draft of AERT

Specific feedback follows.

To Do list:

  1.  The term "author" is preferable here to "user" -- as with
      the Authoring Tool Accessibility Guidelines, "author"
      should refer to the person creating/preparing content for
      the web, and "user" to the end user, even if the author
      is a "user" of specific software.


  1.  The specific purpose of this document is unclear to me; while
      I understand what it does, I am unable to discern the exact
      scope and goals of AERT.  The use of priorities (inherited
      from WCAG) and of "absolute language" in many guidelines
      make this sound as if it were a normative document, not a
      list of suggestions.

  2.  Is the goal to be a "collection of good things to do", a "list
      of minimal functionality", a "comprehensive list of every
      way to evaluate a web document" or something else?  The
      answer will have a definite effect on the software tools
      developed and how they use this document.  If this strives
      to be a "definitive listing," for example, this could adversely
      affect the ability of companies to produce commercial ERT
      tools that have competitive advantages.

  3.  An explanation of this document relates to the Authoring
      Tools Accessibility Guidelines and techniques would be
      useful -- otherwise the possibility for confusion exists.

Structure of this Document

  1.  The nature of the inherited checkpoint priorities needs to
      be addressed -- is the listing of WCAG priorities meant to
      be merely informative or are ERT tool creators expected to
      follow those?

  2.  When a repair strategy is suggested, it should be made clear
      that the options provided are not the only ones that could
      be made available to an author -- and in all cases the author
      should have the ability to override the tool at any point
      in the process.

Technique 1.1.1:

  1.  NULL "alt" values (alt="") should be allowed.

  2.  The use of the term "suspicious" is, well, suspicious, or at
      the very least could be avoided.  In English, this word has
      a connotation of "deceit" and "guilt" that are not appropriate
      for suggested messages or even for internal use.   A better
      term should be selected, such as "Potential Accessibility
      Problem" or "Requires Manual Check", which are value-neutral.

  3.  The suggested message for missing text equivalent should
      explicitly mention the "alt" attribute, simply because many
      web designers are likely to be familiar with the term.
      Revised suggested message:  Missing text equivalent ("alt"
      attribute) for image.

  4.  Suggested text for "longdesc", however, will always need
      further explanation, as this attribute is not familiar to
      most web authors, and can lead to confusion easily -- for
      example, many people will incorrectly guess that "longdesc"
      is simply a longer text string, a la "alt", rather than
      a URI reference.

  5.  Do not suggest "bullet" for bullets and "horizontal rule"
      for horizontal rules.  Instead, suggest one of the following:

      a.  Convert the bullet/horizontal rule image to list
          markup (UL and LI) or horizontal rule markup (HR),
          with appropriate use of CSS to preserve use of the
          image; or
      b.  Suggest "*", "o", "-", and "+" as acceptable "alt"
          text for bullets.  @@ Needed:  Appropriate "alt" text
          for horizontal rules -- this may be best served by
          NULL "alt" attribute.

Technique 1.1.2:

  1.  Authors who have already provided "alt" text may be confused
      by the use of "description of the image" in the suggested
      message -- "Didn't I already provide that?" will be a common
      response to authors familiar with "alt" but not with "longdesc".
      The suggested message should, at the very least, refer to the
      fact that a separate page is used for this purpose -- most
      authors will not realize this.

Technique 1.1.3:

  1.  See 1.1.1 comments.

Technique 1.1.6:

  1.  It may be helpful to search for link text containing the
      word "transcript"?

Technique 1.1.7:

  1.  An additional repair option would be to allow the user to
      reference an outside page that contains the text
      transcript, rather than embedding the text equivalent;
      this reference would then be embedded as a link within
      the OBJECT element.

Technique 1.1.8:

  1.  How is it determined if "the relationships between the
      frames are apparent"?

Technique 1.2.1:

  1.  If the hotspots on an image map can be determined, the
      TITLE attributes of pages referenced by the hotspots *may*
      provide useful suggestions for "alt" text.

  2.  Bouncing requests off a server should be avoided unless
      requested by the author, because overuse of this technique
      may lead to traffic problems.  (An image that is 468 by
      60 pixels in size could generate up to 28,080 requests if
      this technique is misapplied.)  Spacing of at least 5-10
      pixels apart in a grid pattern may be more useful; if a
      hotspot is missed, this may indicate a different accessibility
      problem related to users without fine motor control.

Technique 1.5.1:

  1.  See 1.2.1 comment #1.

Technique 2.1.1:

  1.  A tool may be able to generate a "monochrome" version of the
      page with all color formatting removed (and possibly images
      converted according to a set of filters) -- this would be
      useful for visual inspection by the author.

Technique 3.1.1:

  1.  The suggested message is problematic -- as a quick example,
      MathML support is poor enough that a web site that provides
      arithmetic tutorials for children would not want to rely
      MathML for rendering of algebra equations.

Technique 3.2.1:

  1.  An XML document may not require a !DOCTYPE statement.

  2.  The suggested message -- "Missing language identifier for
      this document" -- is too vague because it sounds like it
      is referring to the "lang" attribute.

Technique 3.3.1:

  1.  Should the CSS be validated if identified?

Technique 3.6.1:

  1.  DL tags are not followed by LI elements, they are followed
      by DT and DD.  Proper use of these elements can be checked
      for, and irregular use of DT/DD can be flagged.

Technique 3.7.1:

  1.  Suggesting Q will always be disaster.  Why does this
      element even exist?

  2.  The suggested identification #1 is problematic because
      not everything inside quotes should be marked up with

  3.  For suggested identification #2 -- what defines "indented

Technique 3.7.2:

  1.  Not all quotes longer than 10 words should be marked up
      with BLOCKQUOTE; this metric does not make sense.

  2.  Even if it made sense in English -- what are the i18n
      issues connected to the use of quotations?

Technique 4.2.1:

  1.  Your understanding of abbreviation ("any word greater
      than 2 characters that is all capital letters") and of
      acronym ("starts with a capital letter, contains lower
      case characters and ends with a period") do not mesh
      with mine -- in fact, I consider your definitions to be
      reversed.  However, much discussion on this topic has
      yielded the consensus that there is no consensus on the
      proper use of ABBR/ACRONYM!  Thus, identification rules
      such as these should be avoided.

  2.  The first suggested repair seems to imply that a definition
      should be given on every use of the of the abbreviated form;
      this is not my understanding.

  3.  It is possible to identify abbreviated forms through the
      use of Inline Natural Language Abbreviation Definitions
      (INLAD), and this should be accounted for in this technique.
      Abbreviated forms within parentheses should probably be

Technique 5.4.1:

  1.  An additional repair function would be to allow repositioning
      and reordering of tables.

Technique 6.1.1:

  1.  Generate and/or display a version of the page without

Technique 6.2.1:

  1.  Relying upon a set of file extensions is a poor choice for
      this.  There is no requirement that a file must have a particular
      name to be a valid markup file.

Technique 6.5.1:

  1.  The suggested message/question is poorly phrased -- it won't
      make sense to most web designers, most of whom are unfamiliar
      with the idea of "frames not loading".  The question almost
      sounds like you are asking "If the page doesn't load, can you
      still use the page?"

  2.  It may be possible to check the NOFRAMES element a little better
      by comparing the number of links and their destination to the
      content of the various frames.  All links accessible through
      the framed page should be accessible through the NOFRAMES
      section -- except that separate pages/URIs for framed/non-framed
      pages might prevent this.  The numbers can be counted, however;
      a NOFRAMES section with only 3 links compared to a framed version
      with 30 links is a good sign that navigation links are not
      present.  (Also, the text of the links, not just the destination,
      may be considered.)

Technique 7.2.1:

  1.  An equivalent for BLINK is defined in CSS Level 2 -- as a
      substitute for BLINK, the following may be used as well as
      those listed in the repair suggestion:

      <SPAN STYLE="text-decoration: blink;">

      As this is part of an official W3C specification, it should
      not be ignored.

Technique 7.3.1:

  1.  An alternative is to provide a scripted solution -- this has
      the advantage (as does the BLINK suggestion above) that it does
      not restrict the author's creative decisions.  If they're
      using MARQUEE, it's not by accident -- it's because they want
      (or wanted) a scrolling text bar.

Technique 7.3.2:

  1.  Why is this presented as a Priority 1 checkpoint?  WCAG 7.3 is
      Priority 2.

Technique 7.5.1:

  1.  The use of HTTP headers -- via web server configuration and/
      or server-side scripting -- should be presented to the author as
      an option.

Technique 8.1.1:

  1.  The suggested message is not helpful.  It is far too cryptic
      and cryptic messages should not be suggested.  Many authors
      will have copied/imported/borrowed/"stolen" applets for use
      on their pages and have no way to evaluate whether or not there
      is "an accessible interface" to the object.

Technique 9.3.1:

  1.  Adding handlers should be suggested; replacing handlers should
      not, due to browser support issues.  Changes should never be
      suggested that will break the user experience for the majority
      of site users!

Technique 9.4.1:

  1.  This check should likely be invoked only if there are more than
      a few links.  There is little point in TABINDEX for pages with
      only a few tab-able elements.

Technique 9.5.1:

  1.  Likewise, there is not a need for ACCESSKEY on *every* page,
      just *most* pages.

  2.  If ACCESSKEY is used, the specific access keys need to be
      identified and instructions given on how to use them.  This
      should be included as part of the evaluation -- "have you told
      your users how to access the ACCESSKEYs on this page?"

Technique 10.1.1:

  1.  We must not "completely avoid new windows" -- instead we must
      tell the author how to make them accessible.

  2.  Why is this Priority 1?  WCAG 10.1 is Priority 2.

Technique 10.1.2:

  1.  Why is this Priority 1?  WCAG 10.1 is Priority 2.

Technique 10.2.1:

  1.  With the use of the LABEL element, is there a need for labels to
      be placed beside the associated form control?  That is not
      obvious to me from reading WCAG/WCAGTECH.  Is this addressing
      those LABEL elements?

  2.  I don't recall seeing the "rules" associated with locating
      labels (as described in the repair suggestion) in WCAG/WCAGTECH
      -- if these are useful, then they should be folded back into
      WCAG and should not be accessibility guidelines spontaneously
      generated by this document.

Technique 10.4.1:

  1.  Why do "checkbox" or "radio" boxes require at least one word
      of text in "value" attributes?  There is no need for such a

  2.  "Radio" boxes should have at least one value that is CHECKED.

Technique 10.5.1:

  1.  Does markup count as "non-whitespace"?  Images, for example,
      may be used as separators.  Can they have NULL "alt" text,
      which may render them as "whitespace" on some browsers?  What
      about the following?

      <A HREF="a.html">Apples</A>
      <SPAN TITLE="or"/>
      <A HREF="b.html">Bananas</A>
      <SPAN TITLE="or"/>
      <A HREF="c.html">Carrots</A>

      This may be a question I should be referring to WCAG.  (See my
      comments about AERT 10.2.1.)

Technique 11.1.1:

  1.  It may be irresponsible to simply present W3C technologies and
      imply that this will increase accessibility when in fact the end
      result will be denying access to 99.99% of the audience.

Technique 11.2.1:

  1.  Why would we want to suggest that IMG should be replaced with
      OBJECT?  That falls under the category of "grossly irresponsible
      suggestions which work on paper but fail in practice."

Technique 11.3.1:

  1.  Some of these suggestions may decrease accessibility if used

Checkpoint 12.3:

  1.  A possible technique would be to check to see if the size is
      over a certain limit -- say, 50K of text -- and then ask if the
      page should be split along lines inferred from H1..H6

Technique 12.4.1:

  1.  Also there should be a check to ensure that the "id" value
      is unique.  (This is part of having a valid "id" attribute,
      so perhaps it is assumed.)

Technique 13.2.1:

  1.  Why are "more" and "follow this" considered suspicious?

  2.  Article names -- especially academic articles -- may easily
      have anchor text that exceeds 60 characters.  The phrasing
      "should be shortened" is too absolute in the suggested

Document Rating:

  1.  Effective, worthwhile tools will not rely merely upon the
      WCAG conformance levels and should ideally provide several
      other optional methods of rating accessibility.

Appendix B:

  1.  Images can have any suffix -- what matters is the mime type
      returned by the server, not the "file name" part of the
      URI.  For example, http://www.kynn.com/+guilt is an image.
      Also, many image formats are not listed here.

Appendix D:

  1.  See Appendix B comments.
Kynn Bartlett <kynn@idyllmtn.com>
Received on Monday, 22 May 2000 18:24:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:30 UTC