Comments on 13 Sep 2002 HLink specification

Steven, Masayasu,

In preparation for the TAG's face-to-face meeting next week, I
read the 13 Sep 2002 HLink spec [1]. I have some comments about
functionalities, derived from UAAG 1.0 [2], that I think should
be part of HLink. I am cc'ing the public wai-xtech list as well.

Thank you for considering these comments,

  - Ian

[1] http://www.w3.org/TR/2002/WD-hlink-20020913/
[2] http://www.w3.org/TR/2002/WD-UAAG10-20020821/

==============================================================

1) effect attribute, value 'new'

  UAAG 1.0, checkpoint 5.3 states:

    1.  Allow configuration so that viewports only open on
    explicit user request.

  HLink should require a conforming HLink user agent
  to satisfy this checkpoint for the 'new' value.

2) effect attribute, value 'submit'

  UAAG 1.0, checkpoint 5.5 states:

    1.  Allow configuration to prompt the user to confirm (or
    cancel) any form submission.

  HLink should require a conforming HLink user agent
  to satisfy this checkpoint for the 'embed' value.

3) actuate attribute, value 'onRequest'

  HLink states:

    "Actuation is done by the user using the primary actuation
    method or by a method (such as scripting) imitating this
    behavior."

  Some of the requirements of UAAG 1.0 involve configuration to
  turn automatic behavior (that may disorient or be unusable by
  some users with disabilities) into manual behavior. Markup
  should make it easier for the user agent to distinguish what is
  really an explicit user request and what is an imitation.

  Therefore, I think that there should be two attributes, to
  distinguish the case of "real user input" from "imitations". The
  same comment goes for onRequestSecondary.

4) actuate attribute, value 'onRequestSecondary'

  If one can only imagine markup language semantics where at most
  two elements are competing for input events, this might be
  sufficient. But is it an unnecessary constraint?

  Instead, I think that the author should be able to provide a
  text title and description of each behavior (by default
  "Activate"). When there is ambiguity about which element should
  get an input event, the user agent should offer to the user the
  choice of actions.

5) Missing attributes for accessibility.

  It seems like a few attributes that benefit accessibility
  are missing: title, accesskey, and tabindex.

  Is there any intention of associating a navigation model
  with HLink elements? UAAG 1.0's navigation assumptions
  are based on enabled elements. I mentioned some navigation
  stop ideas in a recent mail about XAG 1.0 [3], in particular
  the ability of the author to:

   - Identify groups of related links (so UAs can allow users
     to skip over them). This may be related to the 'map' attribute,
     in HLink, but I don't yet understand that attribute's semantics
     enough.
   - Identify stops in the sequential navigation order, and
     links to skip over.
   - Identify elements with navigable substructures.
   - Define a default input binding for activation (like accesskey).
   - Define a sequential navigation order (like tabindex).

  [3] http://lists.w3.org/Archives/Public/wai-xtech/2002Sep/0028

5) mediaType attribute (not accessibility-related)

  Should this attribute be advisory only. Doesn't the definitive
  word about media type come from the protocol?



-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

Received on Friday, 20 September 2002 15:29:34 UTC