Re: Summary of proposed changes to orientation checkpoints.

thanks for posting these changes, Ian.  See comments below by MN:


>At the 4 August teleconference [1], we completed (for now)
>our discussion and attempted reduction of checkpoints in
>guideline 9 of the 16 July draft [2] related to orientation.
>
>To complete my action items related to orientation, I'd
>like to summarize all related proposals and includes some
>new ones here.
>
>Note: With this proposal, I believe
>the number of checkpoints is reduced by 16 with
>respect to the 16 July draft. Good work Group!
>
>A) Change Guideline 10 to read "Notify the user of document
>   or view changes". Guideline 10 will be about orienting the
>   user after dynamic changes to the browsing context. Guideline
>   9 will be about more static information that helps orient the
>   user.
>
>B) Proposed checkpoint on natural language for Guideline 7:
>
>    Render content according to natural language changes
>    identified by markup. For unsupported natural languages,
>    notify the user of the change when configured to do so.
>
>   {This checkpoint is proposed in [5] (slightly different
>    wording here) and would replace 7.3 and 9.9 in [2]}
>
>
>C) Proposed checkpoints for Guideline 9. Each checkpoint is followed
>   by a comment about its origin.
>
>C.i) View information
>
>9.1 Provide a mechanism for highlighting and identifying
>    (through a standard interface where available)
>    the current view, selection, and focus. [Priority 1].
>        NOTE: Recall that a frame is one type of view.
>    {This was resolved in [4]. This subsumes 9.7 from [2]}
>
>9.2 For dependent user agents. Provide the user with
>    information about the number of viewports. [Priority 2]
>    {Was 9.4 in [2]}
>
>C.ii) Document structure
>
>9.3 For dependent user agents. Allow the user to view a
>    document outline constructed from its structural
>    elements (e.g., from header and list elements). [Priority 2]
>    {Was 9.8 in [2]}
>
>9.4 Allow the user to know whether following a link will involve a fee.
>   [Priority 2].
>      NOTE: This information may be provided through the standard user
>      interface provided the interface is accessible. Thus, any prompt
>      asking the user to confirm payment must be accessible.
>   {Proposed in [6]. Subsumes 9.10 and 9.11.}
>
>C.iii) Document content
>
>9.5 Make available information about a link that will enable the
>    user to decide whether to follow the link.  [Priority 3]
>     NOTE: Useful information includes: whether the link has already
>          been visited, whether it leads to a different document, and
>          what is the expected natural language of the link target.
>   {Proposed in [6], Subsumes 9.10, 9.11, 9.16, and 9.17}
>
>9.6 Make available the dimensions of a chosen table. [Priority 3]
>   {9.20 in [2]}

MN:  wondering if we are going to ask that table dimensions be given, might
we also be interested to know a few other things.  Long ago, we had a lot
of discussion on tables, and one thing that I recall, was whether or not
a table had any TH tags, thus possibly implying a data table, rather
than a table used for markup.  Maybe dimensions implies more than
# rows X # columns.  thoughts ?


>9.7 For dependent user agents. Provide access to header
>    information for a table cell selected by the user. [Priority 1]
>   {9.21 in [2]}
>
>9.8 Provide the user with access to any label explicitly
>    associated with a form control. [Priority 2]
>   {9.24 in [2]}
>
>9.9 Make available information about an element's
>    context within a document (e.g., Nth link of M links,
>    Header 3.4, list item 4.5 of two lists, third table and
>    has dimensions RxC, row R column C for currently
>    selected cell, etc.).
>    {Proposed in [1].
>     Subsumes 9.10, 9.12, 9.13, 9.15, 9.19, 9.20, 9.22, 9.23 in [2].}
>
>C.iv) Consistency
>
>9.10 Maintain consistent user agent behavior and default
>     configurations between software releases. Consistency
>     is less important than accessibility and adoption of
>     system conventions. [Priority 3]
>   {9.25 in [2]}

MN:  don't wish to get into a long discussion regarding whether or not
this checkpoint is required, however, the discussion seems to be
centered around "not changing keyboard keys per action between
software releases", and thus, I'd like to at least propose moving this
checkpoint into Guideline 2, perhaps combine as part of one already there, or
if a technique can be written for this, as is.



>D) Proposed changes for Guideline 10. Each checkpoint is followed
>   by a comment about its origin.
>
>Add the following to current 10.1 - 10.5 (integrating them where
>appropriate in the list):
>
>10.6 Ensure that when the selection or focus changes, it is in
>     the viewport after the change. [Priority 2]
>     {Was 9.5 and 9.6 in [2]. Decision in [1] to merge them
>      since other checkpoints on view, selection, focus also merged
>      to new 9.1.}
>
>10.7 Make available what portion of the document has loaded. [Priority
>3]
>     {Was 9.14 in [2].}
>
>10.8 Make available what portion of the document has been viewed
>     [Priority 3]
>     NOTE: What has been viewed may be considered based on focus
>position,
>      selection position, or viewport position depending on how the
>      user has been browsing.
>    {Proposed in [1].}

MN:  Can we combine the new 10.8 and 10.7, something like:

10.X  While loading, make available what portion of the document
has loaded, and when the document is being navigated,
make available what portion of the document has been viewed.
[Priority 3]
     NOTE: What has been viewed may be considered based on focus
position, selection position, or viewport position depending on how the
user has been browsing.

mark

>
>NOTE: There are likely to be further reductions after we consider
>      Gregory's (upcoming) proposal for an all-encompassing
>      checkpoint about configuration (refer to action item in [1]).

Received on Friday, 6 August 1999 10:13:57 UTC