- From: Jeanne Spellman <jeanne@w3.org>
- Date: Fri, 29 Oct 2010 13:17:36 -0400
- To: AUWG <w3c-wai-au@w3.org>
Minutes:
http://www.w3.org/2010/10/29-au-minutes.html
Action Items:
[NEW] ACTION: alastair to reword the proposal for MS6 on
spellchecking in the editing view. [recorded in
[48]http://www.w3.org/2010/10/29-au-minutes.html#action03]
[NEW] ACTION: alastairc to reword the proposal for MS6 on
spellchecking in the editing view. [recorded in
[49]http://www.w3.org/2010/10/29-au-minutes.html#action02]
[NEW] ACTION: Jan to reword MS21 issue on B.1.2.2 with Alastair and
GregP [recorded in
[50]http://www.w3.org/2010/10/29-au-minutes.html#action04]
[NEW] ACTION: JR to reword GL33 proposal [recorded in
[51]http://www.w3.org/2010/10/29-au-minutes.html#action01]
[NEW] ACTION: JR to With JS to reword WCAGWG (awkward for-for, don't
want to imply an extra dialog) [recorded in
[52]http://www.w3.org/2010/10/29-au-minutes.html#action05]
Text of minutes:
[1]W3C
[1] http://www.w3.org/
Authoring Tool Accessibility Guidelines Working Group Teleconference
29 Oct 2010
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0027.html
See also: [3]IRC log
[3] http://www.w3.org/2010/10/29-au-irc
Attendees
Present
Alastair, Andrew, GregP, Jan, Jutta, Tim_Boland, jeanne,
Jeanne, Tim, Greg
Regrets
Sueann, N.
Chair
Jutta Treviranus
Scribe
jeanne
Contents
* [4]Topics
1. [5]Partial conformance proposal
2. [6]Part B Reorg Proposal
3. [7]Identify (and assign actions for) the major areas where
work is still needed
4. [8]Consider "straightforward" existing proposals
5. [9]IBM10
6. [10]IBM11
7. [11]WCAGWG9
8. [12]GL3
9. [13]MS11
10. [14]GL44
11. [15]GL27
12. [16]GL33
13. [17]GL28
14. [18]MS6
15. [19]OC9
16. [20]GL18
17. [21]GL32
18. [22]MS21
19. [23]IBM45
20. [24]WCAGWG17
21. [25]MS24
22. [26]MS32
23. [27]OC25
24. [28]MS50
25. [29]GL2
26. [30]GL20
27. [31]Plan for next meeting
* [32]Summary of Action Items
_________________________________________________________
<trackbot> Date: 29 October 2010
<Jan>
[33]http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0030.h
tml
[33]
http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0030.html
<Jan>
[34]http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0027.h
tml
[34]
http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0027.html
<scribe> scribe:jeanne
Partial conformance proposal
<Jan>
[35]http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0030.h
tml
[35]
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>
[36]http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0016.h
tml
[36]
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:
[37]http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0030.h
tml
[37]
http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0030.html
JR: Also add explanatory note
Part B reorg
Part B Reorg Proposal
<Jan>
[38]http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0016.h
tml
[38]
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
[39]http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0016.h
tml
[39]
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>
[40]http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0027.h
tml
[40]
http://lists.w3.org/Archives/Public/w3c-wai-au/2010OctDec/0027.html
Identify (and assign actions for) the major areas where work is still
needed
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]
Consider "straightforward" existing proposals
<Jan>
[41]http://www.w3.org/WAI/AU/2010/atag20-8Jul10LC-comments-updated27
oct10.html
[41]
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.
IBM10
<Jan>
[42]http://www.w3.org/WAI/AU/2010/atag20-8Jul10LC-comments-updated27
oct10.html
[42]
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
IBM11
<Jan> Resolution: Proposal on IBM11 is approved
WCAGWG9
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
GL3
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
MS11
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
GL44
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
GL27
"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
GL33
"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
[43]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].
GL28
"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:
MS6
"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
[44]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
[45]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].
OC9
"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
GL18
"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
GL32
"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
MS21
[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
[46]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].
IBM45
"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)
WCAGWG17
"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
[47]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].
MS24
"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
MS32
"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
"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
MS50
"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
GL2
"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)
GL20
"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
Plan for next meeting
Let's do this again on November 12 (Friday) from 9 to 12 Eastern US
Next meeting on Monday at our regularly scheduled time.
Summary of Action Items
[NEW] ACTION: alastair to reword the proposal for MS6 on
spellchecking in the editing view. [recorded in
[48]http://www.w3.org/2010/10/29-au-minutes.html#action03]
[NEW] ACTION: alastairc to reword the proposal for MS6 on
spellchecking in the editing view. [recorded in
[49]http://www.w3.org/2010/10/29-au-minutes.html#action02]
[NEW] ACTION: Jan to reword MS21 issue on B.1.2.2 with Alastair and
GregP [recorded in
[50]http://www.w3.org/2010/10/29-au-minutes.html#action04]
[NEW] ACTION: JR to reword GL33 proposal [recorded in
[51]http://www.w3.org/2010/10/29-au-minutes.html#action01]
[NEW] ACTION: JR to With JS to reword WCAGWG (awkward for-for, don't
want to imply an extra dialog) [recorded in
[52]http://www.w3.org/2010/10/29-au-minutes.html#action05]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [53]scribe.perl version 1.135
([54]CVS log)
$Date: 2010/10/29 17:16:04 $
_________________________________________________________
[53] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[54] http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 29 October 2010 17:17:59 UTC