See also: IRC log
<trackbot> Date: 29 October 2010
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0030.html
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0027.html
<scribe> scribe:jeanne
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0030.html
JR: At the F2F, we discussed ways that simpler tools could conform to ATAG. The problem was in checking and repair. The suggestion was to break out checking and repair into Part C. When I went to do it, it didn't work, for reasons set out in the email.
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0016.html
JR: what I did instead is pose a reordering of
Part B that pulls checking and repair into it's own Principle.
... then Conformance is split into Content production with Checking &
Repair and Content without Checking & Repair
... and Content without Checking & Repair must allow external Checking
& Repair
<Jan> JS: I like it, let's do it...the devil is in what we call it
<Jan> AR: Agree with JS, allow more tools to be covered by ATAG.
JT: Go ahead with it
<Jan> JT: I think we should go ahead.
<Jan> Resolution: All accepted: http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0030.html
JR: Also add explanatory note
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0016.html
JR: Many of the Part B notes use checking as an
examples.
... Having a Part C breaks the clear dichotomy of Part A and B. There are very
few changes to the SC, just moving them around.
... B1. The things that the tools decide for the Author. B2 Authors are
supported by the tool. B3 is Checking and Repair B4. is Documentation
... templates are moved into B1
... transformations are kept in B1
... B2 now had technology decision support
... accessible options prominent is moved to B2
TB: Maybe templates deserve a guideline separate from pre-authored content.
AC: It makes a lot of sense. Especially what was B1 and B2.
TB: Does this reflect a more logical grouping of related items?
JR: The main changes are in B1. How do you
auto-generate content? It comes from chunks of code that already exist - a very
similar concept to templates
... Jutta said earlier that templates and pre-authored content are
fundimentally different.
<Jan> Resolution: All accept http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0016.html
<Jan> TB: Agrees tentatively.
TB: I want to think about it more, but go ahead and put it in the new version.
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0027.html
JR: We have dealt with MS2 with the chunk of text from the first proposal. We will add a note under the conformance requirements on Specialized Authoring tool. Some authoring tools provide a fairly limited set of authoring functions compared to the range of possible authoring functions addressed in these guidelines (e.g., a photo editor, a CSS editor, a status update field in a social networking
application, etc.). In this case, most of the ATAG 2.0 requirements are simply not applicable, since most of the requirements are conditional on particular authoring functions being present (e.g., automatically generated content must only be accessible if this functionality exists).
TB: Can this be tested whether or not it is a Simple tool?
JS: I also propose to add this paragraph to the introduction
[review of major comments proposal status]
<Jan> http://www.w3.org/WAI/AU/2010/atag20-8Jul10LC-comments-updated27oct10.html
JR: It is better to say what the platform needs to do rather than decide whether or not a platform is accessible.
<Jan> http://www.w3.org/WAI/AU/2010/atag20-8Jul10LC-comments-updated27oct10.html
IBM wants to move it, it is a simple change. Any objections? [none]
<Jan> Resolution: Proposal on IBM10 is approved
<Jan> Resolution: Proposal on IBM11 is approved
They believe it is critical for definition of non-text content be aligned to WCAG.
scribe: computer code or markup, is considered
non-text content
... they DON'T want it to apply to code. Non-text content is only images.
<Jan> Resolution: Proposal on WCAGWG9 is approved
JR: We can't expect the Authoring Tool to know that it is a keyboard trap. The focus is still stuck in the keyboard trap, so we need to move the editing view keyboard focus to a known location.
<Jan> Resolution: Proposal on GL3 is approved
JR: Static view option: Editing views can be paused and set to not play automatically.
JS: Staying at lvl A
<Jan> Resolution: Proposal on MS11 is approved
Methods of undoing settings changes. Something else to think about regarding "Implementing Success Criterion A.4.1.2 Undo Setting Changes: Actions that modify authoring tool settings are either reversible or include a warning to authors that the action is irreversible. (Level A)": the text noticeably does not mention "Undo" as a method for achieving this. I can tell you from first hand experience
that when speech recognition enters the wrong command into a program, the user interface can be changed in a way that is very difficult to correct because you don't know what command made the change. That argues for an "undo" method for application settings. On the other hand, when applications like Adobe Photoshop Lightroom place interface changes and content changes into the same undo stack it
causes another set of major usability problems
JR: The proposal is to add an example that shows a cancel as a way of undoing a setting change
<Jan> Resolution: Proposal on GL44 is approved
"Clarify minimum requirements for Help Authors Decide. "Implementing Success Criterion B.2.2.3 Help Authors Decide" again may want to clarify whether simply providing instructions in the manual or online help is sufficient, without any active prompting or guiding the user during their task. If not, how can you phrase it so this is clear?"
Proposed: B.2.2.3 Help Authors Decide: For checks that require authors to decide whether a potential web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), instructions are provided from the check that describe how to make the decision. (Level A)
JR: MS also says that they interpreted it as needed artificial intelligence.
JT: The goal of the rewording were to identify
what needs to happen to help authors decide, and to show the relationship
between the checking and the decision making support.
... Concern with "provided from". It requires a link between the checking and
the decision support.
JR: Decision support is going to require some text, some where.
<Jan> Resolution: Proposal on GL27 is approved
"Clarify minimum for B.3.4.1 Model Accessible Practices. Re "B.3.4.1 Model Accessible Practice (WCAG Level A): A range of examples in the documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 Level A accessible authoring practices. (Level A)", because "a range" is undefined, the minimum is left unclear. One solution would be to formally require the practice you
list in the example, which is that "most" examples demonstrate accessible rather than inaccessible practices."
Proposed: Examples in the documentation (e.g., markup, screen shots of WYSIWYG editing views) demonstrate WCAG 2.0 accessible authoring practices.
-Level A
-Level AA
-Level AAA
JR: My wording now shows that all examples, but
Greg wants us to nail down a number.
... we want a range so we can be flexible but testable.
... Postpone for a rewording.
<scribe> ACTION: JR to reword GL33 proposal [recorded in http://www.w3.org/2010/10/29-au-minutes.html#action01]
<trackbot> Created ACTION-304 - Reword GL33 proposal [on Jan Richards - due 2010-11-05].
"Clarify minimum requirements for Status Report. "Implementing Success Criterion B.2.2.6 Status Report" again could better clarify the minimum requirements for conforming. For example, if the user chooses a menu command to check the document and it provides a dialog box listing the errors and potential errors, but provides no way to save or print that information, does that still count as a "report"?
What if the dialog box only shows one error or potential error, and the user has to press a "Next" button to display each successive point?"
Propose: reply to Greg "Point taken, but at some point we can't control bad UI."
<Jan> Resolution: Proposal on GL28 is approved
On to the less straightforward proposals:
"A.2.2.1: “Additional information” is undefined. In order to determine what is considered additional information, one must know what is considered baseline information. We realize that AUWG considers underlining of misspelled words to be a piece of “additional information”, but there is no way to tell what is it that makes such information qualified as being “additional”. This will make
it impossible to determine if the criterion is met.. We can at best project the concept into the similar scenarios for grammatical errors and coding errors—purely because it is an educated guess. Define “additional information” to make it objectively testable or revise the success criterion."
Proposed: "Proposal: A.2.2.1 Editing-View Messages: If an editing-view provides messages to authors by modifying the content renderings or adding temporary content, then those messages can be programmatically determined."
AC: If they don't have control over the font file, does it matter, but if you can apply a font style, then that is programmatically available
JR: This is for spelling or grammar checking that
makes a visual change to the document. The user doesn't need to know it is a
red underlined text, they need to know it is a spelling error.
... They make modifications to the content that will not be published, it is
just information that the author has access to.
"provide additional information to authors that will not be published to end users"
another example is the images of tags in the editing view that will never be published to users.
<scribe> ACTION: alastairc to reword the proposal for MS6 on spellchecking in the editing view. [recorded in http://www.w3.org/2010/10/29-au-minutes.html#action02]
<trackbot> Sorry, couldn't find user - alastairc
<scribe> ACTION: alastair to reword the proposal for MS6 on spellchecking in the editing view. [recorded in http://www.w3.org/2010/10/29-au-minutes.html#action03]
<trackbot> Created ACTION-305 - Reword the proposal for MS6 on spellchecking in the editing view. [on Alastair Campbell - due 2010-11-05].
"A.3.7 – We wonder if there should be a Level AAA requirement that the preview be accessible."
JR: Since the purpose of a preview is the view the material the way the final user will see it, it doesn't make sense to require an accessible browser.
Proposal: A.3.7.1 Preview (Enhanced): If a preview is provided, authors can specify which user agent performs the preview (Level AAA)
GP: Do we have a provision where there is not a preview provided?
JR: there are options, only one of which must be satisfied.
<Jan> Resolution: Proposal on OC9 is approved
JR: if someone is designing from scratch, they need to comply with UAAG, but if they are using a major browser, thought has already been put into accessibility
"Consider recommending an Undo stack. A.4.1 discusses Undo and Redo, but only applies to a single operation. As one error may invalidate actions taken after it, and a user may not recognize an error immediately (especially when using AT), consider adding a Level AA or AAA success criteria about allowing the user to undo more than just the single most recent operation (i.e. a stack for undo or
undo/redo operations)."
Proposed: A.4.1.X Content Changes Reversible (Enhanced): Authors can sequentially reverse a series of reversible authoring actions (e.g., by an "undo" function). (Level AAA)
<Jan> Resolution: Proposal on GL18 is approved
"Clarify minimum for A.4.1.2 Undo Settings Changes. In "Implementing Success Criterion A.4.1.2 Undo Setting Changes: Actions that modify authoring tool settings are either reversible or include a warning to authors that the action is irreversible. (Level A)", what is the minimum acceptable level of functionality? Would it be acceptable for an application to make the user quit and restart the
application to get out of a mode? What if the application provides only a single command to reset all settings to factory default? That would seem to not meet the intent, since it may reset settings that the user needs in order to make the application accessible. (See my other comment on this SC.)"
Proposed: A.4.1.2 Setting Changes: Actions that modify authoring tool settings then one of the following are true:
(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 includes a warning to authors that the action is irreversible and requires authors to confirm the action."
JT: grammar "one of the following IS true"
GP: Another option: Warning to go back to
default, and a reminder to save what you got, in case you want to call it back
up.
... assuming the application has that ability.
"You have indicated you want to revert to defaults, but you have made changes to the configuration, do you want to save that?
JR: We have a section on multiple profiles
<Jan> Resolution: Proposal on GL32 is approved
<Jan> (b) Warn and confirm: The authoring tool includes a warning to authors that the action is irreversible and requires authors to confirm the action or save the current settings before proceeding."
<Jan> Full wording: A.4.1.2 Setting Changes: If actions modify authoring tool settings, then one of the following are true:
<Jan> (a) Reversible: The authoring tool setting can be reversed by the same mechanism that made the change; or
<Jan> (b) Warn and confirm: The authoring tool includes a warning to authors that the action is irreversible and requires authors to confirm the action or save the current settings before proceeding."
<Jan> Resolution: Modified proposal on GL32 is approved
[note: There are two MS21]
"B.1.2.2 Condition b is absolutely not possible if the output is a third party format. This SC essentially asks authoring tool makers to judge and make claim to users which format is less accessible. It would require constant update to keep such info up-to-date and the potential liability of claiming one format is less accessible than another is not something that any manufacturer can accept,
especially when it comes to 3rd party format. Please remove condition b."
Proposal: Reworded: (b) Warning: if accessibility information required to meet the WCAG 2.0 success criteria will not be preserved in the output, then authors are warned (e.g., when saving a structured graphic to a raster image format).
AC: what was the further discussion with MS?
JR: the objection was "accessibility information will be lost", for legal reasons around accessibility. They are ok with "data will be lost"
GL: Sometimes you may use an intermediate
mechanism. For example, PDFmaker tells you what will be brought over, it will
not tell what is left behind.
... there is so much housekeeping that we will be required to monitor.
TB: We don't know where it will go
GP: if the graphic doesn't come through, what happens to the alternate text when you save as text?
TB: A generic warning that says "we can't guarentee"
<alastairc> AC: Perhaps: "Accessibility information may be lost", at least that prompts a check on the other end?
JR: It would be annoying to always get that message with a cut and paste.
JT: MAY be lost, not will be lost.
GP: I would rather have a yellow light reminding people of the implications of what they are going to do.
JR: Export rather than cut and paste.
... [definition of accessibility information] is not just text alternatives
for non-text content
GP: another scenario: You may export the text and preserve the information, but the new application rendering the information may not be able to make it available.
JR: That's a user agent issue, and is not our problem.
<scribe> ACTION: Jan to reword MS21 issue on B.1.2.2 with Alastair and GregP [recorded in http://www.w3.org/2010/10/29-au-minutes.html#action04]
<trackbot> Created ACTION-306 - Reword MS21 issue on B.1.2.2 with Alastair and GregP [on Jan Richards - due 2010-11-05].
"B.1.3.1: needs to be clarified that the tool must provide a mode of operation that complies with this requirement. It should be allowed to be turned off and it should not be required to be the default at Level A. Requiring it by default would be okay at Level AAA."
<Jan> Proposal: If the authoring tool automatically generates content, then it provides the default option of having that web content meet the WCAG 2.0 success criteria when published.
<Jan> Resolution: Modified proposal on IBM45 is approved
JR: when the author process has completed (recognizing that the author may ignore prompts)
"B 2.1.1 (a) and elsewhere term "accessible content" is used where perhaps "conforming with WCAG 2.0" would be better. "
"provide support for the production of accessible content" is already a wordy term without adding a reference to WCAG.
JR Proposal to tighten up the wording:
B.2.1.1 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 authors have the option to be warned that web content accessibility problems may result. (Level A)
Note: From the warning, authors should be able to determine technology options for which the authoring tool does provide support for the production of accessible content.
JS: the wording is awkward, and difficult to parse.
JT: We are requiring the tool to have another option dialog. From a UI perspective - that's covered in the rewording.
<Jan> ACTION: JR to With JS to reword WCAGWG (awkward for-for, don't want to imply an extra dialog) [recorded in http://www.w3.org/2010/10/29-au-minutes.html#action05]
<trackbot> Created ACTION-307 - With JS to reword WCAGWG (awkward for-for, don't want to imply an extra dialog) [on Jan Richards - due 2010-11-05].
"B.2.1.2 What happens if there some properties are set via context menu, some are set on the ribbon, and some are set in a separate dialogue? This SC implies the accessibility-related properties need to be in all of them. We believe there is an unstated assumption that all the mechanisms are interchangeable. That is not a valid assumption. Please revise B.2.1.2"
Proposal: B.2.1.2 Set Accessible Properties: If the authoring tool provides mechanisms to gather information from authors to set properties of web content (e.g., attribute values, etc.), mechanisms are also provided to gather accessibility information required to meet the WCAG 2.0 success criteria.
- The WCAG 2.0 Level A success criteria are met (Level A); or
- The WCAG 2.0 Level A and Level AA success criteria are met (Level AA); or
- The WCAG 2.0 Level A, Level AA, and Level AAA success criteria are met (Level AAA).
ed. note: B.3.2.4 would then set requirements on prominence.
<Jan> JS: B.2.1.2 Set Accessible Properties: If the authoring tool provides mechanisms to set properties of web content (e.g., attribute values, etc.), mechanisms are also provided to gather accessibility information required to meet the WCAG 2.0 success criteria.
AC: I think that is a far as we can take it.
JS: I also want to add a resources link in the implementing document to reference the prominence sections
<Jan> JS: In Implementing doc make sure to provide links to prominence requirements
<Jan> Resolution: Modified proposal on MS24 is approved
"B.2.2.4 This SC is AA or AAA. How is a tool supposed to help locate relevant content to meet WCAG 2.0 3.3.2 or 1.3.3, for example? This SC demands far too much intelligence from the tool to be level A. Move SC to AA or AAA."
Proposal: B.2.2.4 Help Authors Locate: For checks that require authors to decide whether a potential web content accessibility problem is correctly identified (i.e., manual checking and semi-automated checking), the relevant content is identified to the authors. (Level A)
Note: Depending on the nature of the editing-view and the scope of the potential web content accessibility problem, identification might involve highlighting elements or renderings of elements, displaying line numbers, or providing instructions.
AC: Check if they have problems or potential problems.
<Jan> Resolution: Proposal on MS32 is approved
JR: We want to avoid overly general instructions so people cannot find it.
"OC25: -B.2.4.3 – The wording of this item is really difficult to understand. It takes many times through to get an idea of what is being asked for. Recommend rewriting."
Proposal: The authoring tool does not attempt to repair alternative content for non-text content using only text values that are equally available to user agents (e.g., do not use the image filename).
JT: Grammatically, it is a double negative.
JR: it is better not to put useless information into alterative text. E.g. in a social networking site, a user can upload a profile picture. The tool could automatically label it "profile picture"
<Jan> Proposal: The authoring tool does not attempt to repair alternative content for non-text content using text values that are equally available to user agents (e.g., do not use the image filename).
<Jan> Resolution: Modified proposal on OC25 is approved
"B.2.4.4 This SC seems extraneous. If text alternative can be accessed, then obviously it can be reused. If nothing, at least delete “for future reuse.” since it represents future event which is unverifiable at the time of conformance claim. Consider deleting the SC or at least delete “for future use.”"
Proposal: "B.2.4.4: Suggest Previous Author Entries: If the authoring tool prompts authors for alternative content for non-text content, then both of the following are true (Level AA):
(a) if authors insert the same non-text content, then they should have the option to have any previously entered alternative content automatically suggested; and
(b) authors are able to edit or remove text alternatives in the list of previous entries"
Also see notes from GL30. MEDIUM: Clarify minimum requirements for Save for Reuse. "B.2.4.4 Save for Reuse: Authors have the option of having any recognized plain text alternative content that they enter (e.g., short text labels, long descriptions) stored for future reuse. (Level AA)" does not make it clear whether the content strings need to be associated with the original content (e.g. with the
image), or that the user should be able to delete obsolete or erroneous entries to keep the list from becoming unwieldy. I worry that a simple way of complying is just to have a single, ever-growing list of previously used strings that can quickly change from useful to detrimental (like Thunderbird's list of recipients), so even if the minimum is left vague, I recommend at least providing some
guidance or best practices.
<Jan> Resolution: Proposal on MS50 is approved
"Note misleading about scope of A.2.2.3: ATAG's "Implementing Success Criterion A.2.2.3" has a note that is misleading as it seems to limit the scope of the SC to only properties that can be edited by the authoring tool, whereas the SC clearly applies to all properties that are rendered whether they can be edited or not. The SC says "If an editing view (e.g., WYSIWYG view) RENDERS any presentation
properties for text, then those properties can be programmatically determined." Whereas the note says "See Implementing Success Criterion A.2.2.2, substituting all text presentation properties that are BOTH RENDERED AND EDITABLE by the authoring tool for the four presentation properties listed in A.2.2.2." (emphasis added)"
<Jan> Resolution: Proposal on GL2 is approved
Proposal: If a presentation properties for text is both rendered and editable by an editing-view, then the property can be programmatically determined. (Level AAA)
"Identify accessibility features in documentation. B.3.3 requires that features that support the production of accessible content be documented, but I would suggest adding (either as a best practice or as a new SC) that the user should be able to find a list or index of such features. This would be equivalent to UAAG 2.0's "5.3.4 Centralized View: There is a centralized view of all features of the
user agent that benefit accessibility, in a dedicated section of the documentation. (Level AA)" However, in ATAG this should apply to both accessible content support features and to features that make the tool's user interface accessible."
AUWG: We will add a centralized index of documentation at AAA. Proposal: "B.3.3.X Instruction Index: The documentation contains an index to the instructions for using the accessible content support features. (AAA)"
JR: accessible content support features is a
definition in the glossary. [reads]
... it may make more sense to scatter accessibility support information
throughout the document, but provide an index.
<Jan> Resolution: Proposal on GL20 is approved
Let's do this again on November 12 (Friday) from 9 to 12 Eastern US
Next meeting on Monday at our regularly scheduled time.