WAI: Strategies, guidelines, resources to make the Web accessible to people with disabilities
Site Navigation: W3C Home > WAI Home > AUWG
The following table lists the comments received on the July 2011 Working Draft of the Authoring Tool Accessibility Guidelines (ATAG) 2.0, the responses and action taken by the Authoring Tool Accessibility Guidelines Working Group (AUWG). The columns show the text from the ATAG LCWD that prompted the comment; the text of the comment; and the responses by AUWG. The final two columns are for reporting purposes, showing how AUWG disposed of the comment and whether the person making the comment accepted the responses. Where comments or issues repeat, they reference the first instance.
The comments are sorted by commenter response then by disposition, to show the objections first (there were none), then the comments which were not accepted by AUWG. Comments from Microsoft represent multiple commenters inside the company which were presented to AUWG as an aggregated list. The comments were accepted by the member representative in AUWG.
| Order # | ATAG Text | Comments | Responses | Disposition | Response |
| 1 | General Comments | TL1: This document isn't using RFC words. I expect a `should` or `must` before `follow`, the sentence feels awkward without it. | AUWG:WCAG 2.0 and UAAG 2.0 also do not use RFC words. The reason for this is that these are guidelines and not interoperability specifications | 1-Not accepted | 2-No comment |
| 7 | A.2.1.1 Text Alternatives for Rendered Non-Text Content: If an editing-view renders non-text content with programmatically associated text alternatives, then the text alternatives can be programmatically determined. (Level A) |
TL5:`programmatically` sounds wrong, to me <script> is programmatic. I think you mean `structurally`. | AUWG:"Programmatically" is a defined term that is borrowed from WCAG 2.0. This requirement deals with passing text alternative through from the content to assistive technologies. | 1-Not accepted | 2-No comment |
| 10 | A.3.1.5 Customize Keyboard Access: Keyboard access to the authoring tool can be customized. (Level AAA) |
TL7:I seem to recall writing feedback on this somewhere, but basically, I'm not sure I agree with this requirement. It makes more sense for a platform accessibility agent (OS or third party) to offer a consistent UI for customizing keyboard access than having dozens of applications each inventing their own incompatible models. | AUWG:There is an accessibility advantage allowing users to customize keyboard access (e.g. to create keyboard strategies for functions and features unique to the application). This is not absolutely necessary for accessibility, which is why it is listed as AAA.. | 1-Not accepted | 2-No comment |
| 12 | A.3.4.2 Navigate by Programmatic Relationships: If editing-views allow editing of programmatic relationships within web content, then mechanisms are provided that support navigation between the related content. Depending on the web content technology and the nature of the authoring tool, relationships may include, but are not limited to, element nesting, headings, labeling, programmatic definitions, and ID relationships. (Level AAA) |
TL9:I've already commented that I don't like `programmatic`. You might mean `structural` or `DOM associated` or similar. Based on the context, I think `structural` is correct. | AUWG: The point here is to provide another quick way of moving around the authoring tool user interface, at a AAA level. We are refering to the programmatic relationships that exist in program code and markup (e.g., the ability to find where a variable is defined), not just to structural markup-type features. | 1-Not accepted | 2-No comment |
| 25 | B.1.2.1 Restructuring and Recoding Transformations (WCAG): If the authoring tool provides restructuring transformations or re-coding transformations, then at least one of the following is true: (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) (a) Preserve: Accessibility information (WCAG) is preserved in the output; or (b) Warning: Authors have the default option to be warned that accessibility information may be lost (e.g. when saving a vector graphic into a raster image format); or (c) Automatic Checking: After the transformation, accessibility checking is automatically performed; or (d) Checking Suggested: After the transformation, the authoring tool prompts authors to perform accessibility checking. Note: This success criteria only applies to transformations in which the output technology is an "included" technology for conformance. |
Please see above comments on the concept of "automatic". [MS1] |
AUWG: In these cases, a warning each time would not be a very friendly interface. Instead, a developer might choose to offer option (a), (c) or (d). | 1-Not accepted | 3-Accept |
| 26 | B.1.2.1 Restructuring and Recoding Transformations (WCAG): If the authoring tool provides restructuring transformations or re-coding transformations, then at least one of the following is true: (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) (a) Preserve: Accessibility information (WCAG) is preserved in the output; or (b) Warning: Authors have the default option to be warned that accessibility information may be lost (e.g. when saving a vector graphic into a raster image format); or (c) Automatic Checking: After the transformation, accessibility checking is automatically performed; or (d) Checking Suggested: After the transformation, the authoring tool prompts authors to perform accessibility checking. Note: This success criteria only applies to transformations in which the output technology is an "included" technology for conformance. |
MS9a: B.1.2 How does this apply to something like a copy and paste operation from a rich text editor to a plain text editor where structural info will be lost? Who is supposed to tell the author that the structure is gone? Please explain how the SC applies to copy-and-paste or cut-and-paste operations? | AUWG: In these cases, a warning each time would not be a very friendly interface. Instead, a developer might choose to offer option (a), (c) or (d). | 1-Not accepted | 3-Accept |
| 31 | 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: It is recommended that the accessible options be identified, but this is not required. |
TL19:It's probably better to identify the inaccessible options. |
AUWG: It is best left to the the developer. For example, if there are only a few accessible choices, it might be better to call them out. |
1-Not accepted | 2-No comment |
| 9 | A.3.1.1 Keyboard Access (Minimum): All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A) Note 1: The path exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input, but the underlying function (text input) does not. The path exception encompasses other input variables that are continuously sampled from pointing devices, including pressure, speed, and angle. Note 2: This success criterion does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation. |
MS3: Most touch screen devices do not use the keyboard for navigation. Keyboard is only used for text input. The current definition of keyboard interface does not work with the corresponding SC within the context of touch screen devices. Also, please refresh the term PDA. It is no longer in use today. | AUWG: Reworded to address this concernl: Keyboard interfaces are programmatic services provided by many platforms that allow operation in a device independent manner. A keyboard interface can allow keystroke input even if particular devices do not contain a hardware keyboard (e.g., a touchscreen-controlled device can have a keyboard interface built into its operating system to support onscreen keyboards as well as external keyboards that may be connected). Note: Keyboard-operated mouse emulators, such as MouseKeys, do not qualify as operation through a keyboard interface because these emulators use pointing device interfaces, not keyboard interfaces. |
2-Partial accept | 3-Accept |
| 14 | A.3.5.1 Text Search: 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 authors and given focus; and (c) No Match: Authors are informed when no 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. |
MS9: We believe case sensitive search is considered an advanced search function. Thus, we recommend moving the case sensitive search portion of A 3.5.1 should be moved to AAA. | AUWG: See TL10. | 2-Partial accept | 3-Accept |
| 18 | A.3.7.1 Preview (Minimum): If a preview is provided, then at least one of the following is true: (Level A) (a) Pre-existing User Agent: The preview makes use of a pre-existing user agent; or (b) UAAG (Level A): The preview conforms to the User Agent Accessibility Guidelines Level A [UAAG]. |
MS4: The term "pre"-existing is problematic as User agents may be updated to render newer types of content. We suggest the term "pre" be removed. | AUWG: We have replaced this with the term "in-market". | 2-Partial accept | 3-Accept |
| 19 | A.4.1.1 Content Changes Reversible (Minimum): For authoring actions, one of the following is true: (Level A) (a) Reversible: The authoring action can be immediately reversed; or (b) Warn and Confirm: The authoring tool provides a warning to authors that the action is irreversible and requires authors to confirm the action before proceeding. Note 1: Reversing actions (e.g. an "undo" function) are also considered authoring actions, meaning they must also meet this success criterion (e.g. a "redo" function). Note 2: It is acceptable to collect a series of text entry actions (e.g. typed words, a series of backspaces) into a single reversible authoring action. Note 3: It is acceptable to clear the authoring action history at the end of authoring sessions. |
MS5: Please remove "immediately" from condition A. It introduces far too much subjectivity into the success criterion. | AUWG: Reworded as: If an authoring action is not immediately reversible, then the authoring tool requires author confirmation to proceed. | 2-Partial accept | 3-Accept |
| 21 | A.4.2.2 Document All Features: The authoring tool includes documentation for its author-level user interface features. (Level AA) Note: The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2. |
MS6: We need definition for "author-level user interface features". | AUWG: Reworded as follows: "A.4.2.2 Document All Features: For each authoring tool feature, at least one of the following is true: (Level AA) (a) Described in the documentation: use of the feature is explained in the authoring tool's documentation; or (b) Described in the interface: use of the feature is explained in the authoring tool user interface; or (c) Platform service: the feature is a service provided by an underlying platform; or (d) Not used by authors: the feature is not used directly by authors (e.g., passing information to a platform accessibility service). Note: The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2. " |
2-Partial accept | 3-Accept |
| 29 | B.2.2.3 Technology Decision Support: If the authoring tool provides the option of producing a web content technology for publishing for which the authoring tool does not provide support for the production of accessible content, then both of the following are true: (Level A) (a) Warning: Authors are warned that the authoring tool does not provide support for the production of accessible content for that technology; and (b) List: From the warning, authors can access a list of technologies for which the authoring tool does provide support for the production of accessible content. |
TL17:I'm uncertain how (b) will be remotely useful to the user. If the application can produce 100 unrelated accessible things and the user is trying to create a certain 1 thing which is not related to the 100 unrelated accessible things, then other than being forced to have a somewhat prominent advertisement for unrelated features, I think the user is being done a disservice. Two possible ways to address my concern are: s/technologies/[related|similar] technologies/ | AUWG: The WG has taken a different approach: B.4.1.3 Feature Availability Information: If the authoring tool supports production of any web content technologies for publishing for which the authoring tool does not provide support for the production of accessible content, then this is documented. (Level AA) Note: This success criterion concerns the presence or absence of support features, such as accessibility checkers, not any intrinsic property of web content technologies. |
2-Partial accept | 2-No comment |
| 34 | Guideline B.4.1: Ensure the availability of features that support the production of accessible content. | TL20:I don't know that this claim is supportable. Authoring tools back to the age of time (Netscape Gold) had an alt tag field for images, that didn't result in accessible content. | AUWG: We are giving a rationale rather than a hard claim. That said, alt use is higher than some less prominent accessibility attributes (e.g., longdesc). | 2-Partial accept | 2-No comment |
| 36 | B.4.1.4 Feature Prominence: Accessible content support features are at least as prominent as features related to either invalid markup, syntax errors, spelling errors or grammar errors. (Level AA) |
TL22:Having worked with web pages for well over a decade, I can say the same for invalid markup and syntax errors. Having worked in Europe, I can say with some level of confidence that spelling errors are absolutely ignored. As for grammar, people don't even bother looking at them if they don't pay attention to spelling. As such, this requirement has no teeth. You should be aware of this. OTOH, there really isn't any level beyond them to suggest.... | AUWG: Authors will vary in the degree to which they heed any guidance from their authoring tool. The requirement is on authoring tools, not users of authoring tools. | 2-Partial accept | 2-No comment |
| 40 | Glossary | TL26:source views: s/unrendered/raw|underlying/ ? `unrendered` seems to be a term limited to FCP. | AUWG: We have not been able to find a better term. The fact that browsers render things seems to lend support to the use of "unrendered". | 2-Partial accept | 2-No comment |
| 41 | Glossary | WSO1: One area of concern, however, is the inconsistent use of the terms "accessible" and "accessibility." (SEE DETAILS HERE http://lists.w3.org/Archives/Public/public-atag2-comments/2011Sep/0000.html) | AUWG: Related to WCAG-WG's concern. | 2-Partial accept | 2-No comment |
| 2 | General Comments | MS2: The biggest concern for ATAG 2.0 is that it is never clear if ATAG is for a single tool or a collection of tools. It is trying to be both. This leads to a great deal of structural problems. If it is for a single tool, then the SCs are too far reaching and the conformance requirement does not make room for a simple specialized tool to conform. How does ATAG 2.0 conformance work for something like a web accessibility toolbar, photo editor, FTP client, or a social networking site? You need to allow tool makers to say their tool does not provide certain function and it is not intended to do so, but the tool conforms where it is applicable. On the other hand, how would conformance work for a collection of tools where some criteria are met via a portion of the tools? Would one have to specify which tool(s) is used to conform to any given criterion? If the collection of tools include tool(s) in which the conformance claimer has no Intellectual property ownership, would the claimer then be held responsible for the accuracy of the claim of such tool? What if is there is discrepancy between the tool manufacturer and claimers? What if the collection is still not applicable to ATAG in full-for example, only relevant to part A? Is the collection deemed incomplete? Additionally, where does the value chain of the authoring process end? Without knowing the scope, then ATAG 2.0 may require consideration of software such as scanner application, a database, a web service, or enterprise backend systems. Does a mail client become a "web authoring tool" only when it sends a message to somebody who access their email via the web? How is one supposed to know if the mail recipient uses a web client? These are extremely difficult questions. But if left unanswered, ATAG 2.0 will not be viable in practice. The conformance section requires fundamental revision to be viable. Please revise accordingly.Most of the questions posted in this comments are unaddressed by the reply of the update. Please review and address accordingly. Moreover, many of the updated success criteria are still lacking condition parameters. | AUWG: The conformance model has been completely overhauled to address this issue. In particular, a new Partial Conformance category has been added " when an authoring tool would require additional tools or components in order to conform as a complete authoring system. This option may be used for components with very limited functionality (e.g. a plug-in) up to nearly complete systems (e.g. a markup editor that only lacks accessibility checking functionality). " | 4-Accepted | 3-Accept |
| 3 | General Comments | MS12: We do not believe the question about the problem regarding 3rd party making claim on authoring tools that they are not responsible for is properly addressed in the conformance text. | 1 | 4-Accepted | 3-Accept |
| 4 | User agent features: Web-based authoring tools may rely on user agent features (e.g. keyboard navigation, find functions, display preferences, undo features, etc.) to satisfy success criteria. If a conformance claim is made for a web-based authoring tool, the claim must cite the user agent. | TL2:What do you mean `cite`? | AUWG: Reworded as: "Conformance claims are optional, but any claim that is made must record the user agent(s)." |
4-Accepted | 2-No comment |
| 5 | A.1.2.1 Accessibility Guidelines: Non-web-based authoring tool user interfaces follow user interface accessibility guidelines for the platform. (Level A) Note: If a conformance claim is made, then the claim must cite the accessibility guidelines followed. |
TL3:`cite` how? (An example or formal structure would be nice, is "Supports WCAG2" sufficient? Should it be "Supports <url> level X"?) | AUWG: Reworded as: Note: The (optional) explanation of conformance claim results should record the user interface accessibility guidelines that were followed. |
4-Accepted | 2-No comment |
| 6 | A.1.2.2 Platform Accessibility Services: Non-web-based authoring tools implement communication with platform accessibility services. (Level A) Note: If a conformance claim is made, then the claim must cite the platform accessibility service(s) implemented. |
TL4:`cite` is a weird word, I think you want `list` here. | AUWG:Reworded as: Note: The (optional) explanation of conformance claim results should record the platform accessibility service(s) that were implemented. |
4-Accepted | 2-No comment |
| 8 | A.2.1.2 Alternatives for Rendered Time-Based Media: If an editing-view renders time-based media, then at least one of the following is true: (Level A) (a) Alternatives Rendered: Alternatives for the time-based content are also rendered; or (b) User Agent Option: Authors have the option to preview the time-based content in a user agent that is able to render the alternatives. |
TL6:Always rendering captions doesn't seem like the right requirement. I think you want `can be rendered` not `are also rendered`. Being accessible doesn't mean burning captions into content (I just watched a movie last night where the captions were initially projected into the speakers below the screen... -- and I needed the captions). Note that the text for (b) is nicer, it says `has the option to... render the alternatives`, which is really what should be offered in (a). | AUWG: Reworded as: Option to Render: The authoring tool provides the option to render alternatives for the time-based media; or |
4-Accepted | 2-No comment |
| 11 | A.3.1.6 Present Keyboard Commands: Authoring tool user interface components can be presented with any associated keyboard commands. (Level AAA) |
TL8:What does `presented` mean? (This sentence took me 5 minutes to decipher.) ~There should be a way for a user to determine the associated keyboard commands for authoring tool user interface components.~ ? | AUWG: Reworded as: A.3.1.6 Present Keyboard Commands: Provide a way for authors to determine the keyboard commands associated with authoring tool user interface components. |
4-Accepted | 2-No comment |
| 13 | A.3.5.1 Text Search: 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 authors and given focus; and (c) No Match: Authors are informed when no 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. |
TL10:You don't define `case sensitive`. Please be aware that this area runs into I18n issues. |
AUWG: This has been removed. |
4-Accepted | 2-No comment |
| 15 | A.3.6.3 Apply Platform Settings: The authoring tool respects changes in platform display and control settings made by authors. (Level AA) |
TL11:If the user has already specified custom settings in the application, then this requirement seems brittle. It should be compatible with the user being able to specify custom settings in the application. | AUWG: Reworded as: "The authoring tool respects changes in platform display and control settings, unless authors select more specific display and control settings using the authoring tool." |
4-Accepted | 2-No comment |
| 16 | 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) |
TL12:I think you mean complete sets as opposed to subsets of settings. And that multiple just means <app-full-settings-for-morning.settings> and <app-full-settings-for-evening.settings> and not <app-editor.settings> / <app-previewer.settings> -- I think your text sort of implies the latter, which seems to be overreaching, even for AAA. | AUWG: Reworded "A.3.6.4 Multiple Sets: If the authoring tool includes display and/or control settings, then the authoring tool provides the option of saving and reloading multiple configurations of settings." |
4-Accepted | 2-No comment |
| 17 | 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) |
TL13:It sounds like you're asking for a Wizard. If you mean that, perhaps a `such as a Wizard` would be useful. | AUWG: This has been been removed as proposed. | 4-Accepted | 2-No comment |
| 20 | A.4.1.2 Setting Changes Reversible: If actions modify authoring tool settings, then one of the following is true: (Level A) (a) Reversible: The authoring tool setting can be reversed by the same mechanism that made the change; or (b) Warn and Confirm: The authoring tool provides a warning to authors that the setting change is irreversible and requires authors to confirm or save the current settings before proceeding. |
TL14:Would it be sufficient to have a way to save and restore settings (with a warning/way to save current settings)? | AUWG: Reworded: A.4.1.2 Settings Change Confirmation: Mechanisms for changing authoring tool user interface settings can reverse the setting changes or the authoring tool requires author confirmation to proceed. |
4-Accepted | 2-No comment |
| 22 | Applicability after the end of an authoring session: Authoring tools are responsible for the accessibility of web content that they automatically generate after the end of an author's authoring session (see Success Criterion B.1.1.1). For example, if the developer changes the site-wide templates of a content management system, these would be required to meet the accessibility requirements for automatically-generated content. Authoring tools are not responsible for changes to the accessibility of content that the author has specified, whether it is author-generated or automatically-generated by another system that the author has specified (e.g. a third-party feed). | TL15:s/specified/merely selected for use/ ... I'm not sure whether `merely` is needed, but my initial drafting does include it. |
AUWG: Reworded: Authoring tools are not responsible for changes to the accessibility of content that the author causes, whether it is author-generated or automatically-generated by another system that the author has specified (e.g. a third-party feed). |
4-Accepted | 2-No comment |
| 23 | Applicability after the end of an authoring session: Authoring tools are responsible for the accessibility of web content that they automatically generate after the end of an author's authoring session (see Success Criterion B.1.1.1). For example, if the developer changes the site-wide templates of a content management system, these would be required to meet the accessibility requirements for automatically-generated content. Authoring tools are not responsible for changes to the accessibility of content that the author has specified, whether it is author-generated or automatically-generated by another system that the author has specified (e.g. a third-party feed). | MS1 (related to MS1 on previous public draft): The concept of "automatically generate" content does not appear well defined. In the example where the developer changes the template of a content management system illustrates the issue. How is a template changed or configured by a developer considered "automatic"? It appears the example is saying the threshold of "automation" is something that is processed in an on-going basis by machine, regardless if it is configurable by human. If that is the case, we ask the working group to define what is "not automatic". We encourage deeper analysis of both the term "automatic" and related normative text. | AUWG: The definition of automatically generated content has been reworked: "content generation (content authoring, content editing) The act of specifying the actual web content that will be rendered, played or executed by the end user's user agent. While the precise details of how content is created in any given system may vary widely, responsibility for the generation of content can be any combination of the following: - author generated content: Web content for which authors are fully responsible. The author may only be responsible down to a particular level (e.g., when asked to type a text label, the author is responsible for the text, but not for how the label is marked up; when typing markup in a source editing-view, the author is not responsible for the fact that UNICODE is used to encode the text ). - automatically generated content: Web content for which developer-programmed functionality is fully responsible (e.g., what markup to output when an author requests to start a new document, automatically correcting markup errors). - third-party content generation: Web content foe which a third-party author is responsible (e.g., community shared templates)." |
4-Accepted | 3-Accept |
| 24 | B.1.1.2 Content Auto-Generation During Authoring Sessions (WCAG): Authors have the default option that, when web content is automatically generated during an authoring session, then one of the following is true: (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) (a) Accessible: The content is accessible web content (WCAG) without author input; or (b) Prompting: During the automatic generation process, authors are prompted for any required accessibility information (WCAG); or (c) Automatic Checking: After the automatic generation process, accessibility checking is automatically performed; or (d) Checking Suggested: After the automatic generation process, the authoring tool prompts authors to perform accessibility checking. Note 1: Automatic generation includes automatically selecting templates for authors. Note 2: This success criterion applies only to automatic processes specified by the authoring tool developer. It does not apply when author actions prevent generation of accessible web content. |
MS7: What are "restructuring transformations" and "recoding transformations"? We think the concept of "accessibility information" needs reexamination. We believe we are aiming at covering text alternative, audio description, captions, and content structure. If so, there should be a tighter definition of "accessibility information" and that there may be a better term to encompass these items. Moreover, I don't think these items are separated into A, AA, and AAA in WCAG 2.0. | AUWG:An example of AAA alternative content in WCAG 2.0 is "1.2.6 Sign Language (Prerecorded)". There is a table of informative examples in the new draft. | 4-Accepted | 3-Accept |
| 27 | B.2.2.2 Setting Accessibility Properties (WCAG): If the authoring tool provides mechanisms to set web content properties (e.g. attribute values, etc.), then mechanisms are also provided to set web content properties related to accessibility information (WCAG): (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: Success Criterion B.4.1.4 addresses the prominence of the mechanisms. |
TL16:This blob did not end in a period, s/:/./ -- a note follows the `:` but it doesn't make sense to think of that as a `list`. |
AUWG: Editorial. |
4-Accepted | 2-No comment |
| 28 | B.2.2.2 Setting Accessibility Properties (WCAG): If the authoring tool provides mechanisms to set web content properties (e.g. attribute values, etc.), then mechanisms are also provided to set web content properties related to accessibility information (WCAG): (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: Success Criterion B.4.1.4 addresses the prominence of the mechanisms. |
MS8: The term is merely renamed "web content properties related to accessibility information" which is still undefined or at least ill defined. | AUWG:This will be better defined by the informative table of examples that is being added for Accessibility Information. | 4-Accepted | 3-Accept |
| 30 | B.2.3.2 Conditions on Automated Suggestions: During the authoring session, the authoring tool may only automatically suggest programmatically associated text alternatives for non-text content under the following conditions: (Level A) (a) Author Control: Authors have the opportunity to accept, modify, or reject the suggested text alternatives prior to insertion; and (b) Relevant Sources: The suggested text alternatives are only derived from sources designed to fulfill the same purpose (e.g. suggesting the value of an image's "description" metadata field as a long description). |
TL18:You're using an rfc word (`may`) here, which is odd... | AUWG:Reworded as "can". Editorial. | 4-Accepted | 2-No comment |
| 32 | 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: It is recommended that the accessible options be identified, but this is not required. |
MS10: We recommend removal of the note on B 2.4.1. It appears contradictory to B 2.4.2 & B 2.4.3 | AUWG:This has been removed. . | 4-Accepted | 3-Accept |
| 33 | B.2.4.3 Author-Create Templates: If the authoring tool includes a template selection mechanism and allows authors to create new non-accessible templates (WCAG), then authors can enable the template selection mechanism to display distinctions between accessible and non-accessible templates that they create. (Level AA) Note: The distinction can involve providing information for the accessible templates, the non-accessible templates or both. |
MS11: We recommend renaming B 2.4.3 to "Author-created template" | AUWG: Agreed - Editorial. | 4-Accepted | 3-Accept |
| 35 | B.4.1.3 Feature Deactivation Warning: If authors turn off an accessible content support feature, then the authoring tool informs them that this may increase the risk of content accessibility problems. (Level AA) |
TL21:Depending on the UI, this can be an incredibly stupid if not absolutely inane requirement. If I have a dialog called "Accessibility Options", and have check items for various features, then being required to give the user a warning after they uncheck such an option is just plain stupid. Start>Shutdown, are you sure you really really want to shut down? (I've actually seen dialogs which include `really`, sadly.) A better requirement would be to simply require that the user be aware that the option they are disabling will affect accessibility -- either through the UI design itself or via a subsequent warning. |
AUWG: Informing does not have to take the form of a dialog box, this will be made more clear in the implementing document. | 4-Accepted | 2-No comment |
| 37 | Guideline B.4.2: Ensure that documentation promotes the production of accessible content. Rationale: Without documentation of the features that support the production of accessible content (e.g. prompts for text alternatives, accessibility checking tools), some authors may not be able to use them. Demonstrating accessible authoring as routine practice will encourage its acceptance by some authors. |
TL23:This doesn't make sense in context. Documentation is unlikely to include prompts. Perhaps *explanations* of prompts. And *descriptions* or *recommendations* of tools ..."some authors may not be able to use them." This doesn't follow. "Demonstrating accessible authoring as routine practice will encourage its acceptance by some authors." This is a pipe dream and doesn't seem suitable for a standards document. It's even rather weak given its use of `some`.... | AUWG: Reword as: Some authors need support in determining how to use accessible content production features (e.g. how to respond to prompts for text alternatives, how to use the accessibility checking tool). Demonstrating accessible authoring as routine practice or at least not demonstrating inaccessible practices will help to encourage acceptance of accessibility by some authors. |
4-Accepted | 2-No comment |
| 38 | Glossary | TL24: Prompts: s/promptings/prompts/ ? This whole thought makes me sick. Typically prompts just annoy users. Note that this last sentence is missing a <what>, perhaps "to do the right thing". | AUWG: Reworded: prompt: Any authoring tool initiated request for a decision or piece of information from authors. The term covers requests that must be responded to immediately (e.g. modal dialog boxes) as well as less urgent requests (e.g. underlining a misspelled word). |
4-Accepted | 2-No comment |
| 39 | Glossary | TL25: Irreversible Actions: s/irreversible/not undoable/g ? `irreversible` is not a common word, and its primary results on the web are NSFW. | AUWG: Removed and replaced in text with "not reversible". We don't use "undoable" because sometimes the mechanism is called "cancel", etc. The term reversible is also reworded: "reversible authoring action is an authoring action that can be immediately and completely undone by the authoring tool upon a cancel request by an author. Examples of cancel requests include: "cancel", "undo", "redo" (when it used to reverse "undo"), "revert", and "roll-back" Note: It is acceptable to collect a series of text entry actions (e.g., typed words, a series of backspaces) into a single reversible authoring action.." | 4-Accepted | 2-No comment |
Skip to Content 