W3C home > Mailing lists > Public > w3c-wai-au@w3.org > October to December 2010

Minutes of AUWG special teleconference of 29 October

From: Jeanne Spellman <jeanne@w3.org>
Date: Fri, 29 Oct 2010 13:17:36 -0400
Message-ID: <4CCB01B0.7030909@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 29 October 2010 17:18:00 GMT