Re: Review of Principle 2

Re 2.2.3's Intent, I can understand why Kelly thinks it could give the wrong impression. How about a minor rewording:

    "*When content authors have not explicitly defined a logical navigation order in their documents*, this success criterion ensures that the order will at least be consistent between user agents."


Re 2.2.3's SC, I agree with Jim that I don't think it's particularly confusing, and I'm reluctant to introduce the term "content author" into the normative content where so far we use the term "author" exclusively; if we change it here, we should change it everywhere. So how about a compromise, which keeps Jim's "document navigation order" but not "content author":

    "2.2.3 If the author has not specified a document navigation order, the default sequential navigation order is the document order." [This could also say "specified a *document's* navigation order", or "specified navigation order for a document".]


Re 2.1.2 Intent, I don't have any problem saying things are required by "Guideline 1.3" and "Success Criteria 4.1.6", but if you want to say "success criteria in Guideline 1.3" I think that would be better than "success criteria in 1.3".

Re 2.1.3's last sentence, fine either way.

Re 2.1.4's Intent, Kelly's change seems fine.

     Thanks,
     Greg

-------- Original Message --------
Subject: Re: Review of Principle 2
From: Jim Allan <jimallan@tsbvi.edu>
To: Kelly Ford <Kelly.Ford@microsoft.com>
Cc: "'UAWG list' (w3c-wai-ua@w3.org)" <w3c-wai-ua@w3.org>
Date: 9/12/2013 6:16 AM
> kelly wrote:
>
> 2.2.3 default navigation order:
>
> The SC needs to be more explicit that this is limited to web content based what it says.
>
> Original text:
>
> If the author has not specified a navigation order, the default sequential navigation  order is the document order. (Level A)
>
>  No proposal as of now.
>
> <jim> are you saying someone reading the document would confuse web author with a user agent author? the SC mentions the author and document, it says nothing about user interface or anything else.
>
> would the following make it clearer?
>
> Proposal
>
> 2.2.3 if the content author has not specified a document navigation order, the default sequential navigation order is the document order.
>
> </jim>
>
> Kelly wrote:
>
> 2.2.3 Intent:
>
> This sentence is misleading.
>
> Original text:
>
> Content authors are expected to define a logical navigation order in their documents, but if they have not, this success criterion ensures that the order will at least be consistent between user agents.
>
>  This implies that authors must do this work. That is not accurate.  In general we expect authors not to have to define the navigation order unless they are doing something special.
>
> <jim> the original makes perfect sense. the author has to do the work with the content order so the tab flow makes sense. In training we emphasize that the source code determines the navigation and reading order. if the author has to resort to using tabindex to put things in the proper order (at least for tabbing and form navigation) ... they have done something wrong (or in rare instances they are doing something special). This is the authors issue, the HTML has to make sense in the order written.
>
> </jim>
>
>
>
> On Wed, Sep 11, 2013 at 3:24 PM, Kelly Ford <Kelly.Ford@microsoft.com <mailto:Kelly.Ford@microsoft.com>> wrote:
>
>     Here are notes on review of principel 2.
>
>     2.1 Intent
>
>     A should be as in this line and what is the check point referenced?
>
>     Original text:
>
>     1.Direct (e.g. keyboard shortcuts such a***as*** "F1" to open the help menu; see checkpoint 11.4***this should be?*** for single-key access requirements)
>
>     In general this IER is too long with too many examples and text that at times sound too much like an SC and too many examples, some of which are not really complete.
>
>     2.1 Resources
>
>     Still has @@saying find references
>
>     2.1.2 Intent:
>
>     Text uses guideline and success criteria to refer to the same item type.  This should be consistent.
>
>     Original text:
>
>     Both the user and some types of assistive technology need to know what will be affected by any keyboard input, so it's important that they be able to tell
>
>     which window, viewport, and controls have the keyboard focus at any time. This applies whether window and viewport are active (active keyboard focus) or
>
>     inactive (inactive keyboard focus). Even when a window is inactive, it can be affected by simulated keyboard input sent by assistive technology tools.
>
>     Active keyboard focus is indicated to the user by focus cursors and text cursors, as required by Guidelines 1.3***success criteria under 1.3***, and made available to assistive technology,
>
>     as required by
>
>     Success Criterion 4.1.6.
>
>     2.1.3 Intent
>
>     Last sentence shouldn’t end with the word is.
>
>     Original text:
>
>     If  users can put focus on an element, they can remove focus and move on to the next element. This is often not possible with embedded objects. The user
>
>     agent needs to provide a way to always return to the previous or next element in the content, or a known location such as the address bar. The user agent
>
>     also needs to take control back from the embedded object, no matter what it is.
>
>     Proposed for last sentence:
>
>     The user agent also needs to be able to take control back from all embedded objects.
>
>     2.1.3 examples
>
>     In should be is.
>
>     Original text:
>
>     He presses Tab until the focus i***is***n on the media player,
>
>     2.1.4 Intent
>
>     Soften claim that this is more likely for assistive technology users and this implies that all assistive tech means you don’t see the screen.
>
>     Original text:
>
>     People do not expect side effects when moving the keyboard focus regardless of whether the side effect is caused by the user agent or author content. If
>
>     users fail to notice side effects, they could end up doing something disastrous. This is especially likely for users of assistive technology who cannot
>
>     see changes happening elsewhere on the screen.***This may be more likely for users who are not able to easily detect changes outside the location with focus.*** Users may also find it confusing or disorienting if the effect causes unexpected focus movement or changes
>
>     in context. If the user agent does implement side effects to keyboard navigation, it is recommended that it provide a user preference setting to disable
>
>     them. However, in some cases it may be more appropriate to provide a separate navigation mechanism that avoids side effects, such as allowing the user
>
>     to hold down the Ctrl key while navigating to avoid changing selection or choice.             Note: It may not be possible for the user agent to detect
>
>     or prevent side effects implemented by scripts in the content, but the user agent is required to prevent side effects that are under its control.
>
>     2.2.3 default navigation order:
>
>     The SC needs to be more explicit that this is limited to web content based what it says.
>
>     Original text:
>
>     If the author has not specified a navigation order, the default sequential navigation  order is the document order. (Level A)
>
>     No proposal as of now.
>
>     2.2.3 Intent:
>
>     This sentence is misleading.
>
>     Origianl text:
>
>     Content authors are expected to define a logical navigation order in their documents, but if they have not, this success criterion
>
>     ensures that the order will at least be consistent between user agents.
>
>     This implies that authors must do this work.  That is not accurate.  In general we expect authors not to have to define the navigation order unless they are doing something special.
>
>     2.3.5 example
>
>     An extra the in this line.
>
>     Original text:
>
>     The user agent    provides a list of user interface features and default
>
>     keyboard   assignments with options for the***delete** George to assign new key combinations.
>
>     2.4.1 exmaple
>
>     Need should be needs.
>
>     Original text:
>
>     Betty, who has low vision, is attempting to create a user   stylesheet for a site. She need***needs*** to know the 'class' attribute value for   navigation headers.
>
>     2.7 summary:
>
>     Setting should be settings
>
>     Original text:
>
>     and adjust preference setting***settings*** outside the user interface so the  current user interface
>
>     does not prevent access (2.7.4, Level AA),
>
>     2.7.2 example:
>
>     Typo in repetitive
>
>     Original text:
>
>     [mobile] Kathy has repetive*repetitive*** stress injuries which makes it painful to experiment with settings. She accidently turns on a zoom feature on her smartphone
>
>     2.7.5 intent:
>
>     Setting should be settings
>     original text:
>
>     Users who have spent time customizing accessibility            preferences to meet their requirements need to  migrate preference
>
>                Setting***settings***
>
>     2.8.1 example
>
>     Duplicate so she
>
>     Original text:
>
>     When Jennifer picks up Linda's mobile phone, she turns
>
>     on the built-in voice application so she so she***delete duplicate*** can quickly find her way around Linda's phone.
>
>
>
>
> -- 
> Jim Allan, Accessibility Coordinator & Webmaster
> Texas School for the Blind and Visually Impaired
> 1100 W. 45th St., Austin, Texas 78756
> voice 512.206.9315    fax: 512.206.9264 http://www.tsbvi.edu/
> "We shape our tools and thereafter our tools shape us." McLuhan, 1964