ACTION: JR Consider how to set a minimum criteria for A.3.1

Jan's email

PROPOSAL: Adjust defined term to "sequential keyboard access" (and adjust the definition):

A.3.1.3 Efficient Keyboard Access: The authoring tool user interface includes mechanisms to make keyboard access more efficient than sequential keyboard access. (Level AA)

sequential keyboard access
Using a keyboard interface to navigate the focus one-by-one through all of the items in an ordered set (e.g. menu items, form fields, etc.) until the desired item is reached and activated. This is in contrast to direct keyboard access methods such as keyboard shortcuts and the use of bypass links.

Summary

Details

A.3.5.1 ACTION: JR in A.3.5.1, use "web content being edited" to be more clear that this refers to editing views. AND ACTION: JR work in "Focus is moved and the match is made visible to the author" to A.3.5.1

Jan's email

PROPOSAL: To split the search requirement into an AA minimum (within current editing view) at an AAA enhanced (all editing views). The reason is that browser search functions are confined to text that is currently rendered (including within textboxes) and we want these functions to be leveraged by web-based tools.

Success Criterion A.3.5.1 Text Search (Minimum): Editing-views enable text search, such that all of the following are true: (Level AA)
(a) All Editable Text: Any text content that is editable by the editing-view is searchable (including alternative content); and
(b) Match: Matching results can be made visible to the author and given focus; and
(c) No Match: Authors are informed when no matching results are found; and
(d) Two-way: The search can be made forwards or backwards; and (e) Case Sensitive: The search can be in both case sensitive and case insensitive modes.

Success Criterion A.3.5.X Text Search (Enhanced): The authoring tool enables text search of all editable text in the web content being edited. (Level AAA)

Note: Authoring tools that support multiple editing-views should display search results in editing-views in which the results are editable.

Summary

Details

ACTION: JR to update answer to IBM24 to better address mobile

Jan's email

AUWG: This requirement has been changed to clarify that mechanisms such as skip-over links qualify: FOLLOWED BY SC WORDING THAT MAY CHANGE DUE TO A.3.1.3 PROPOSAL ABOVE

Summary

Details

PROPOSAL: A.3.6.1 Independence of Display:

Jan's email

PROPOSAL: A.3.6.1 Independence of Display: If the authoring tool includes display settings, then authors can adjust these settings for editing-views without affecting the web content to be published. (Level A)

Summary

Details

PROPOSAL: A.3.6.2 Save Settings

Jan's email

PROPOSAL: A.3.6.2 Save Settings: If the authoring tool includes display and/or control settings, then these settings can be saved between authoring sessions. (Level AA)

Summary

Details

PROPOSAL: A.3.6.3 Apply Platform Settings

Jan's email

PROPOSAL: A.3.6.3 Apply Platform Settings: The authoring tool respects changes in platform display and control settings made by authors. (Level AA)

Summary

Details

A.3.6.4 Multiple Sets

Jan's email

PROPOSAL: A.3.6.4 Multiple Sets: If the authoring tool includes display and/or control settings, then authors can save and reload multiple sets of these settings. (Level AAA)

Summary

Details

A.3.6.5 Assistance with Preferences

Jan's email

PROPOSAL: A.3.6.5 Assistance with Preferences: If the authoring tool includes display and/or control settings, then the authoring tool includes a mechanism to help authors configure these settings. (Level AAA)

Summary

Details

Jan's email

PROPOSAL: A.4.2.2 Document Author-Level Features: The authoring tool includes documentation for its author-level user interface features. (Level AA)

Summary

Details

Jan's email

PROPOSAL: A.3.2.1 Auto-Save (Minimum): If the authoring tool includes authoring session time limits, then the authoring tool can be set to automatically save web content edits made using the authoring tool before session time limits are reached. (Level A)

Summary

Details

Jan's email

PROPOSAL: A.3.2.4 Auto-Save (Extended): The authoring tool can be set to automatically save web content edits made using the authoring tool. (Level AAA)

Summary

Details

Jan's email

PROPOSAL: to pull the text together into a single parenthetical to match the other level indicators:
(Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Summary

Details

Jan's email

accessible templates (WCAG):
Templates that can be filled in to create web content that meets the WCAG 2.0 success criteria (Level A, AA or AAA), when both of the following are true:
(a) The author correctly follows any instructions provided (e.g., correctly responding to prompts, correctly replacing highlighted placeholders); and
(b) No further authoring occurs.

Note: Under these conditions, some templates will result in completely empty documents, which are considered accessible by default.

Summary

Details

Jan's email

PROPOSAL: B.2.4.1 Accessible Template Options (WCAG): If the *authoring tool* provides *templates*, then there are *accessible template (WCAG)* *options* for a *range* of template uses. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

Note: The accessible options are not necessarily identified.

Summary

Details

Jan's email

PROPOSAL: B.2.4.2 Identify Template Accessibility (Minimum): If the *authoring tool* includes a *template selection mechanism* and provides any non-*accessible template (WCAG)* *options*, then the templates are provided such that the template selection mechanism can display distinctions between the accessible and non-accessible options. (Level AA)

Note: The distinction can involve providing information for the accessible templates, the non-accessible templates or both.

Summary

Details

Jan's email

PROPOSAL: B.2.4.x Identify Template Accessibility (Enhanced): If the *authoring tool* provides any non-*accessible template (WCAG)* *options* and does not include a *template selection mechanism*, then the non-accessible templates include accessibility warnings within the templates. (Level AAA)

Summary

Details

Jan's email

PROPOSED RESPONSE: AUWG: The status requirement ("B.3.1.4 Status Report: Authors can receive an accessibility status report based on the results of the accessibility checks. (Level AA) Note: The format of the accessibility status is not specified. For example, the status might be a listing of problems detected or a WCAG 2.0 conformance level, etc. ") is simply that the author receive information about the state of things from the accessibility checker. The note clarifies that the format of the report is not specified.

If the checker hasn't run, there will be nothing to report. Your comment raises email, wikis and dynamic content as issues, which we will address separately:
- in the case of email, an accessibility checker, like a spell checker is something a sender may or may not choose to run. For example, sending a quick personal note to a known recipient requires less vigilance than posting to a publicly-archived forum.
- wikis have the challenge that the wiki system doesn't usually have access to the content until the user submits it (though DHTML implementations change this). However, this need not be a problem since the user can re-edit content if/when content issues are identified by the system (whether they are issues of wiki syntax, spelling or accessibility)
- by "dynamic content" you may be referring to DHTML-type content. This certainly presents challenges to automated checkers, however some progress has been made on checker design in this area and in these cases communication of results back to the author seems to be a reasonable use case.

Summary

Details

Jan's email

B.3.1.5 Programmatic association of results: Authoring tools can programmatically associate accessibility checking results with the web content that was checked. (Level AA)

Summary

Details

Jan's email

Current version: (http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20110613/#gl_b42)

Challenges in setting a testable criterion:

- online documentation can be modified or added-to by developers at any time
- documentation sets may be vast (thousands of pages) or very limited (even one page)
- while the accessibility of documentation can be (to some extent) checked automatically, checking whether documentation correctly models accessible practice must be done manually.
- theoretically, this situation lends itself to a statistical approach (e.g., testing a random set of documents from the documentation), but this is not very practical and inevitably would lead to questions about how the "random" set was selected.

Proposal: Link the term "range" to the new definition, but add context in the "Intent"

B.4.2.1 Model Practice (WCAG): A *range* of examples in the documentation (e.g. markup, screen shots of WYSIWYG editing-views) demonstrate accessible authoring practices that meet the WCAG 2.0 success criteria. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)

DEFINITION:

"Range": More than one item within a multi-item set. (Informative) Note: ATAG 2.0 uses the term "range" in several success criteria in which absolute measurements may not always be practical (e.g. the set of all help documentation examples, the set of all templates, etc.). While the strict testable requirement is the definition "More than one item within a multi-item set", implementers are strongly encouraged to implement the success criteria more broadly.

Intent of Success Criterion B.4.2.1:

The intent of this success criterion is to have accessible authoring practices introduced to authors as naturally integrated common practice. The success criterion is also intended to reduce the chance that authors will copy inaccessible authoring practices from examples in the documentation. Essentially, modelling inaccessible authoring practices in the documentation should be viewed in the same way as modelling invalid markup or spelling/grammar errors.

WCAG 2.0 is referenced because it provides testable success criteria to measure web content accessibility.

Examples of Success Criterion B.4.2.1:

- Reference examples are accessible: An HTML authoring tool includes an on-line HTML markup reference guide. Markup examples within the reference guide are all valid code and they all meet the WCAG 2.0 Level A success criteria.

- Screen shots show accessibility features in use: A content management system has a help system that includes screen shots of various aspects of the system's user interface. When screen shots show examples of the user interfaces as content is being produced, the user interface is always shown such that the content produced would meet the WCAG 2.0 Level A success criteria (e.g. prompts filled in, optional accessibility features turned on, etc.).

Summary

Details