Update index with minimise errors #97
Conversation
|
@lseeman Can you confirm what the related issue is here? |
|
I am a bit confused here. I think this is the pull request for issue 13 #13 |
| <section class="sc"> | ||
| <h4>Minimize user errors</h4> | ||
| <p class="conformance-level">A</p> | ||
| <p>Input error are automatic corrected where the correction can be reliably made.</p> |
There was a problem hiding this comment.
"automatic corrected" > "automatically corrected"
There was a problem hiding this comment.
Change "error" to "errors" and "correction" to "corrections" to match the verb "are"
There was a problem hiding this comment.
Also, given the glossary definition being added, is this supposed to be "Common input errors..." instead of just "Input errors..."?
| @@ -1242,6 +1256,8 @@ | |||
| <p>A touchscreen PDA has a keyboard interface built into its operating system as well as a connector for external keyboards. Applications on the PDA can use the interface to obtain keyboard input either from an external keyboard or from other applications that provide simulated keyboard output, such as handwriting interpreters or speech-to-text applications with "keyboard emulation" functionality.</p> | |||
| <p>Operation of the application (or parts of the application) through a keyboard-operated mouse emulator, such as MouseKeys, does not qualify as operation through a keyboard interface because operation of the program is through its pointing device interface, not through its keyboard interface.</p> | |||
| </dd> | |||
| <dt><dfn> known to be reliable and achievable</dfn></dt> | |||
| <dd>Identified in the WCAG techniques as possible to reliably correct an errors, or found in user testing to constantly</dd> | |||
There was a problem hiding this comment.
"as possible to reliably correct an errors" perhaps better "as possible to reliably error-correct"
"or found in user testing to constantly" dangling sentence
| @@ -1103,6 +1115,8 @@ | |||
| <p>A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, or a tab control do not necessarily change the context, unless they also change one of the above (e.g., focus).</p> | |||
| <p>Opening a new window, moving focus to a different component, going to a new page (including anything that would look to a user as if they had moved to a new page) or significantly re-arranging the content of a page are examples of changes of context.</p> | |||
| </dd> | |||
| <dt><dfn>common input error</dfn></dt> | |||
| <dd>errors that have been have been documented in the understanding of the Success Criteria section or have supportive techniques or that have been reported or documented more then one time and there is a know way to identify them</dd> | |||
There was a problem hiding this comment.
- Fix double "have been"
- Change "know" to "known"
- Reword as a clearer comma-separated list (too many uses of "or" without punctuation)
|
The glossary definition of "common input error" effectively creates a dynamic WCAG normative document by referring directly to the Understanding & Techniques documents. I think this directly conflicts with the definition of these documents as informative and thus not required for conformance. If this is allowed, there would be a precedent set that conformance in 2018 does not mean conformance in 2020. I would recommend narrowing the scope by reworking this definition. Also, the technique of basing a temperature input on locale mentioned in issue #13 could present issues with consistency with other form inputs/outputs, collaboration across locales, and scientific purpose (e.g. when an absolute scale of Kelvin or Rankine is appropriate). I would recommend removing that from this SC. I also think it would be more at home in another SC because automatic locale changes should not be restricted to just input.. |
with some stange stuff