WAI-AU F2F Day 1

 

 

<AndrewR> scribe: Andrew

<AndrewR> JR - just about to start the document walkthrough

<AndrewR> A1

<AndrewR> PRINCIPLE A.1: Authoring tool user interfaces must follow applicable accessibility guidelines

<AndrewR> 2 guidelines in this section

<AndrewR> Guideline A.1.1 [For the authoring tool user interface] Ensure that Web-based functionality is accessible.

<AndrewR> identical wording at 3 levels

<AndrewR> JR - suggesting we change wording to "conform to" rather than "meet"

<AndrewR> changing the wording of the applicability notes slightly

<AndrewR> removing the applicability reminder

<AndrewR> JR - difference between the formatting between the style of ATAG and WCAG

<AndrewR> does anyone have concerns changing the formatting to match WCAG and UAAG?

<AndrewR> all fine with this

<AndrewR> Reed - we are depending on WCAG to be testable

<AndrewR> Guideline A.1.2 [For the authoring tool user interface] Ensure that non-Web-based functionality is accessible.

<AndrewR> does WCAG apply to a client uploader?

<AndrewR> no

<AndrewR> Reed - sentence doesn't seem to make sense

<AndrewR> changing the wording now

<AndrewR> brainstroming words for "non web-based tools"

<AndrewR> e.g. client side, desktop software

<JR> Non-Web-based authoring tool user interfaces comply with and cite the "Level A" requirements of standards and/or platform conventions that benefit accessibility. The "Level A" requirements are those that are functionally equivalent to WCAG Level A success criteria

<AndrewR> Reed - do platform conventions have "levels" e.g. A, AA?

<JR> Issue: Definition of "functional equivalent"

<trackbot> Created ISSUE-167 - Definition of \"functional equivalent\" ; please complete additional details at http://www.w3.org/WAI/AU/tracker/issues/167/edit .

<AndrewR> JR - that's where "functional equivalent comes in"

<AndrewR> JS - have we heard any progress on ISO 24751 becoming freely available?

<AndrewR> JT - we haven't heard yet

<AndrewR> JT - the intention is that it should become free

<AndrewR> Reed - how does this map to MSAA / IA2?

<AndrewR> platform conventions normally have 2 levels

<AndrewR> WCAG etc have 3 levels

<AndrewR> JR - WCAG, although being heavily web based, isn't like "apples and oranges" compared to the platform conventions

<AndrewR> A1.2 will need revisiting

<AndrewR> if / when ISO becomes free

<AndrewR> PRINCIPLE A.2: Editing views must be perceptible

<JR> • This guideline does not apply to plain text editors as they do not render non-text content.

<JR> Editing views that render non-text content provide authors with access to any recognized equivalent alternatives.

<JR> Ensure access to presentation information

Guideline A.2.2 [For the authoring tool user interface] Ensure that the interface can be presented in different ways.

<Reed> ACTION: RS to define "presentation view" [recorded in http://www.w3.org/2008/10/23-au-minutes.html#action01]

<trackbot> Sorry, amibiguous username (more than one match) - RS

<trackbot> Try using a different identifier, such as family name or username (eg. rscano, rshaffne)

<Reed> ACTION: Reed to define "presentation view" [recorded in http://www.w3.org/2008/10/23-au-minutes.html#action02]

<trackbot> Created ACTION-26 - Define \"presentation view\" [on Reed Shaffner - due 2008-10-30].

<JR> Authors need to have the ability to perceive the presentation of the content being edited because authoring tools often use the presentation to provide information about the state of the content (e.g., underlining spelling errors) and to provide a realtime demonstration of how the content will appear to most end users. At the same time, some authors will require display settings that differ...

<JR> ...from the presentation that they intend to define for the published content (e.g., an author sets high contrast for themselves, while editing content that is not intended to be high contrast).

<Reed> Proposed definition for Presentation View: The presentation view is the final rendering of any content. It is the output which will be viewed by consumers other than the author. Users with disabilities must have access to this view so that they can ensure their content is consumable by any audience.

<AndrewR> JS - what about widgets that grey out when not available?

<AndrewR> this checkpoint is about giving the ability to edit content with their display settings and publish it using "default" visual settings

<AndrewR> this checkpoint is about giving the #user# the ability to edit content with their display settings and publish it using "default" visual settings

<AndrewR> i.e. edit in high contrast but publish with corporate colour scheme

<AndrewR> JS - lets list what we want to achieve in plain English

<AndrewR> 1 - edit in your own colour scheme

<AndrewR> 2 - anything visual added to the screen to indicate something, i.e. spell check underline, is available

<Reed> editing view is indepenent of presentation view

<Reed> alerts specifc to editing view (e.g. spelling squigglies) are provided programatically

<Reed> programatically provide the presentation view to assistive technologies

<Reed> ACTION: reed define editing view [recorded in http://www.w3.org/2008/10/23-au-minutes.html#action03]

<trackbot> Created ACTION-27 - Define editing view [on Reed Shaffner - due 2008-10-30].

<AndrewR> A2.2.1 needs to become a checkpoint on its own

<JR> Guideline A.2.2 [For the authoring tool user interface] Ensure that the authors display preferences. [Techniques]

<JR> Guideline A.2.2 [For the authoring tool user interface] Ensure the independence of authors’ display preferences. [Techniques]

<JR> Rationale: Some authors will require display settings that differ from the presentation that they intend to define for the published content (e.g., an author sets high contrast for themselves, while editing content that is not intended to be high contrast).

<AndrewR> UAAG has a good programmatic access section we may want to look at

<JR> Guideline 2.1 Facilitate programmatic access by assistive technologies

<JR> 2.1.1 Accessibility Platform Architecture: Support an accessibility platform architecture relevant to the platform.

<JR> 2.1.2 Name, Role, State, Value, Description: For all user interface components (including the user interface and rendered content), the name, role, state, value, description are made available via an accessibility platform architecture.@@more work needed@@ @@techs includes "visited link state"

<JR> 2.1.3 Accessible Alternative: If any functionality is not supported by the implemented accessibility platform architecture(s), then a separate accessible alternative for that functionality that is supported by the implemented accessibility platform architecture(s) is provided and a description of the inaccessible functionality appears in the conformance claim.

<JR> 2.1.4 Programmatic Availability of DOMs: If the user agent implements one or more DOMs, they must be made programmatically available to assistive technologies. @@techs include CSS DOM

<JR> 2.1.5 Write Access: If the user can modify the state or value of a piece of content through the user interface (e.g., by checking a box or editing a text area), the same degree of write access is available programmatically.

<JR> 2.1.6 Properties: If any of the following properties are supported by the accessibility platform architecture, they must be made available via the architecture:

<JR> (a) the bounding dimensions and coordinates of rendered graphical objects

<JR> (b) font family of text

<JR> (c) font size of text

<JR> (d) foreground color of text

<JR> (e) background color of text.

<JR> (f) change state/value notifications @@(e.g. of DOMs)

<JR> 2.1.7 Timely Communication: For APIs implemented to satisfy the requirements of this document, programmatic exchanges proceed in a timely manner (Level AA).

<Reed> http://cgi.w3.org/member-bin/irc/irc.cgi

<Reed> one more thought, is there a definition of timely manner?

<jallan> it's still an issues in UAAG

<JR> We're back

<AnnM> can whoever was just talking speak up a little please?

<Reed> set scribe: reed

<Reed> <JR> do we all agree that what we mean is that is allowable to provide functionality that doesn't use architecture so long as it's provided another way?

<AnnM> sure

<JR> Old wording: 2.1.3 Accessible Alternative: If any functionality is not supported by the implemented accessibility platform architecture(s), then a separate accessible alternative for that functionality that is supported by the implemented accessibility platform architecture(s) is provided and a description of the inaccessible functionality appears in the conformance claim.

<Reed> <RS> 2.1.3 does not make sense as stated

<jeanne> http://www.w3.org/WAI/UA/2008/WD-UAAG20-20081023/MASTER20081023.html

<Reed> Current Happenings: Fixing links to publish updates

<jeanne> http://www.w3.org/WAI/AU/2008/WD-ATAG20-20081023/MASTER20081023.html

<Reed> Jan is currently drafting new proposal for 2.1.3

<Reed> in UAAG

<Reed> to be used here

<Reed> <reed> people should be able to use anything to provide access, doesn't need ot be api

<Reed> <jr> need to be careful about giving people additional ways to do things

<Reed> <jr> provide more conventional UI that does

<JR> RS: In 2.1.3....says now if doesn't support platform architecture...

<JR> Janina: We've really been trying to give ATs fighting chance out of the box with the engineered APIs

<JR> RS: Agree...this needs to read...when possible support platform API...but some UI characteristics can't be represented on an architecture...

<JR> RS: But if you have a UI that can't be represented then you should be able to document your own

<JR> JS: Also don't think API carved in stone

<JR> JR: Out seems to be use a new UI

<JR> RS: Not realistic to think devs go to new UIs for an out to accessibility...they may just want to do something new

<Reed> <JR> if you can support the UI you are building with existing API

<Reed> do so

<Reed> <observer> if not, bridge into existing API's

<JR> JR: Proposal: Remove 2.1.3 Accessible Alternative

<Reed> NOTE: numbers in these discussion pertain to UAAG as they exist currently

<Reed> <JR> keep as is and then explain in techniques ways to get to things

<Reed> <observer> they have their own ways of doing things on their platforms

<Reed> they = mozilla

<JR> JR: Proposal: Reword 2.1.1 as: Accessibility Platform Architecture: Support an accessibility platform architecture relevant to the platform and the technology.

<Reed> <js> what is the new number?

<Reed> JS = Jeanne

<jeanne> <JR> Janina: Also don't think/<JR> Janina: Also don't think

<Reed> <JR> it's basically a new concept for ATAG

<JR> PRINCIPLE 2. Facilitate programmatic access by assistive technologies

<JR> PRINCIPLE A.2. Facilitate programmatic access by assistive technologies

<jeanne> s/ s/JS: Also don't think /Janina: Also don't think /

<JR> PRINCIPLE A.3: Editing views must be perceivable

<Reed> JR: a.2 will be facilitate access programatically

<Reed> jr: we got through all of a.2 which was goal for morning session

<Reed> jr: i want to skip over enhanced keyboard and UAAG has already done good work

<Reed> Note: Postponed

<Reed> <js> remove not used very often

<Reed> jr: how do you feel about global?

<JR> When an author is able to decide whether or not something will happen. An option may be local (e.g., prompting whether to save before closing a piece of content) or a global (e.g., preference settings). etc.).

<Reed> js: when an author is "presented with a choice"

<Reed> js: or choices

<JR> When an author is presented with choices. An option may be local (e.g., prompting whether to save before closing a piece of content) or global (e.g., preference settings).

<JR> • A.3.2.1 Data Saved: If the authoring tool ends an authoring session due to a time limit (e.g., authenticated session expires), then authors have the global option to ensure that the content being edited is saved. For Web-Based Authoring Tools, this applies to any content that has already been submitted to the server by the user agent.

<Reed> <rs> timing should prevent inactivity

<Reed> <jr> here we are talking about total session time and not inactivity

<Reed> <js> there should be a prompt for a logging out

<Reed> <observer> is there anything about this in UAAG?

<Reed> <js and jr> yes there is

<Reed> <observer> it's about activity

<Reed> <jr> wcag covers things like games which covers things like games

<Reed> <rs>inactivity on the web will force logouts

<Reed> <jr> there are two types

<jeanne> JR: three are different types of time limits. The important thing is to offer the author an ability to extend the time.

<jeanne> WCAG quote:

<JR> Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar")

<Reed> RS: it would apply in subscription too

<Reed> JR: moving targets, this is interesting but timing is only a component

<Reed> JR: they have it too in the other standards (it being moving target clauses)

<jeanne> http://www.w3.org/WAI/AU/2008/WD-ATAG20-20081023/MASTER20081023.html#gl-tool-control-time

<Reed> JR: I have a rewrite

<Reed> JR: when do you have moving targets in an authoring tool

<Reed> JR: what about selectable part of animation instead?

<JR> e.g., selectable component of an animation

<Reed> RS: need to have global option or moment?

<Reed> JS: yeah, just moment

<JR> • A.3.2.3 Moving Targets: If the user interface includes any moving targets for authors' actions (e.g., selectable component of an animation), then authors have t option to stop that movement.

<Reed> JR:do we want to get rid of it completely?

<Reed> JR et al: we are removing that section (passes without objection)

<Reed> JR: moving to A3.3

<Reed> discussing scope of editing view

<Reed> <js> it needs to be there so that the author can see it

<Reed> <jr> the term recognize I put a note in

<JR> • Recognized: If success criteria apply to “recognized” types of content (e.g., “recognized equivalent alternatives”, the conformance claim must list the recognized types.

<Reed> jr: rationale being because blinked could mean many things

<Reed> jr: must define what blinking types are being blocked

<Reed> jr: i could put a bunch of shapes outside the screen

<Reed> rs: what level is this?

<Reed> jr: right now it is recognized blinking or flashing

<Reed> jr: you should be able to pause a movie player

<Reed> jr: there are ways of doing this that you wouldn't think would cause it

<Reed> observer: it's good in that it includes the problem, and it excludes what doesn't

<Reed> js: i dont want to exclude things that are being imported in

<Reed> jr: you wont ahve time to pause

<Reed> js: why dont we postpone this one

<Reed> jr: redner every static thing but run no clock

<Reed> js: important for low vision who need to look at things outside their current viewing area

<Reed> jr: global option to not start the clock

<jeanne> For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it

<Reed> RS: every app should have a static view

<Reed> RS: we will need to define static view

<Reed> JR: should be AA

<Reed> NOTE: jan writing now

<JR> A.3.3.2: Static View: If an editing view renders content then then the author has the global option of a static view in which time-based content appears in a fixed state.

<Reed> RS: should clarify what we mean by rendering

<JR> A.3.3.2: Static View: If an editing view renders content (e.g. WYSIWYG) then then the author has the global option of a static view in which time-based content appears in a fixed state.

<JR> A.3.3.2: Static View: If an editing view renders content (e.g. WYSIWYG) then then authors have the global option of a static view in which time-based content appears in a fixed state.

<Reed> JR: would be a good idea to pass to UAAG

<Reed> cough cough jallan

<Reed> JR: moving to next section

<Reed> A.3.5

<Reed> SORRY

<Reed> A.3.4

<Reed> JS: can we look at the rationale?

<Reed> NOTE: drafting changes

<Reed> when the authoring tools follow the structure present in the content to simplify navigation

<JR> when the authoring tools follow the structure present in the content to simplify navigation and editing.

<JR> > when the authoring tools use the structure present in the content to simplify navigation and editing.

<JR> People who have difficulty typing or operating the mouse benefit when the authoring tools use the structure present in the content to simplify navigation and editing.

<JR> People who have difficulty typing or operating the mouse benefit when authoring tools use the structure present in the content to simplify navigation and editing.

<jeanne> New version: http://www.w3.org/WAI/AU/2008/WD-ATAG20-20081023/MASTER20081023.html#gl-tool-struct-nav

<Reed> RS: what is a simple action?

<Reed> JR: should break out head and identical elements

<JR> A.3.4.2 Navigate By Element Type: If an editing view displays a structured element set, authors can move the editing focus forward/backward to the next identical element.

<JR> A.3.4.3 Navigate By Headings: If an editing view displays a structured element set, authors can move the editing focus forward/backward to the heading, regardless of level.

<Reed> JS: Point of order, you dont want me to copy techniques do you?

<Reed> moving to tree structures

<Reed> everyone seems to be ok with tree strucutres

<Reed> PAUSED FOR LUNCH

<JR> 4.1.1 Keyboard Operation: All functionality can be operated via the keyboard using sequential and/or direct keyboard commands that do not require specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the authors' movement and not just the endpoints (e.g., free hand drawing). This does not forbid and should not discourage...

<JR> ...providing mouse input or other input methods in addition to keyboard operation. (Level A)

<JR> 4.1.2 No Keyboard Trap (Minimum): The authoring tool prevents keyboard traps as follows (Level A):

<JR> (a) in the UI: if keyboard focus can be moved to a component using the keyboard, then focus can be moved away from that component using standard sequential keyboard commands (e.g., TAB key)

<JR> (b) in the rendered content: provides a documented direct keyboard command that will always restore keyboard focus to a known location (e.g., the menus).

<JR> (c) in the rendered content: provides a documented direct keyboard command that will always move keyboard focus to a subsequent focusable element

<JR> 4.1.4 Separate Selection from Activation: Authors have the global option to have selection separate from activation (e.g., navigating through the items in a dropdown menu without activating any of the items). (Level A)

<JR> 4.1.5 Discovery of Keyboard Commands: Authors have the global the option to have any *recognized* direct keyboard commands displayed with their associated controls. (Level A)

<JR> 4.1.6 Standard Text Area Navigation Conventions: Editing views that render text support the standard text area conventions for the platform including, but not necessarily limited to: character keys, backspace/delete, insert, "arrow" key navigation (e.g., "caret" browsing), page up/page down, navigate to start/end, navigate by paragraph, shift-to-select mechanism, etc. (Level A)

<JR> 4.1.7 Keyboard Navigation: Authors can use the keyboard to traverse all of the controls forwards and backwards, including controls in floating toolbars, panels, and user agent extensions using the navigation conventions of the platform (e.g., via "tab", "shift-tab", etc. "). (Level AA)

<JR> 4.1.8 Important Command Functions: Important command functions (e.g. related to navigation, display, content, information management, etc.) are available in a single key command. (Level AA)

<JR> 4.1.11 Intergroup Navigation: Allow the user to navigate from group to group of focusable items (e.g., toolbars, dialogs, panels, etc.) (Level AAA)

<JR> =======

<JR> 4.1.10 Override of UI Keyboard Commands: The user can override any keyboard shortcut binding for the user agent user interface except for conventional bindings for the operating environment (e.g., for access to help). The rebinding options must include single-key and key-plus-modifier keys if available in the operating environment. (Level A)

<JR> 4.1.xx Specify preferred keystrokes: The user has the option to establish a preferred set of keys that will be used to override *recognized* author supplied keybindings (i.e. access key). (Level AA)

<JR> 4.1.xx User Override of Accesskeys: The user can override any author supplied content keybinding (i.e. access key) that the user agent can *recognize*. The user must have an option to save the override of user interface keyboard shortcuts so that the rebinding persists beyond the current session. (Level AA)

<JR> Real-time content authoring

Definition of authoring tool

<JR> Working on: Real-time content authoring tools (e.g., chats, collaboration tools, whiteboards, etc.), especially those that archive as Web content, are considered authoring tools and can be made more accessible for both participants and users of the stored archives. While not all parts of ATAG 2.0 will usefully apply, some discussion is provided in ATAG 2.0 Techniques Appendix E: Real-time...

<JR> ...content production.

<JR> Live content authoring tools (e.g., chats, collaboration tools, whiteboards, etc.) are required only to meet Part A. However, many guidelines in Part B may still usefully apply, especially if the tool archives as Web conten. For more information, please see the Techniques - Appendix E: Real-time content production.

<JR> • Recognized: If success criteria apply to “recognized” types of content (e.g., “recognized equivalent alternatives”, the conformance claim must list the recognized types.

<JR> (e.g., listing the elements recognized as images)

<JR> ACTION: JR to Change "recognized" to tool-recognized, move Part A note into Definitions [recorded in http://www.w3.org/2008/10/23-au-minutes.html#action04]

<trackbot> Created ACTION-28 - Change \"recognized\" to tool-recognized, move Part A note into Definitions [on Jan Richards - due 2008-10-30].

<JR> Josh: Looks to me that compliance to ATAG for CMS...

<JR> Josh: Same as WCAG to Web...

<JR> JR: Josh: Then if that could go into procurement process... very potent

PART B: Support the production of accessible content

<JR> 1. Author Availability: Any success criteria in Part B that refer to authors only apply during authoring sessions when authors are available.

<JR> authoring session

<JR> A state of the authoring tool during which content can be edited by the author. The end of an authoring session is the point in time at which a session ends and the author has no further opportunity to make changes without starting another session. This may be under the control of the author (e.g., closing a document, publishing) or it may be controlled by the authoring tool (e.g., when the...

<JR> ...authoring tool transfers editing permission to another author on a collaborative system). Note: Automated content generation may continue after the end of an authoring session (e.g., CMS updates).

<JR> 4. Authoring Systems: As per the definition of authoring tool, several software tools can be used in conjunction to meet the success criteria in Part B. (e.g. an authoring tool could make use of a 3rd party software accessibility checking and repair program.

<JR> 1. Author Availability: Any success criteria in Part B that refer to authors only apply during authoring sessions when authors are available.

<JR> 3. Existing Technologies: The success criteria in Part B only apply to support for accessible authoring practices that are relevant to technologies that the authoring tool already has the ability to create or edit. For example, a markup authoring tool that adds images by simply linking to their URIs would be required to support the production of alternative text for images in the markup, but...

<JR> ...it would not be required to add image editing functionality to ensure sufficient contrast in case any images are of text.

<JR> 2. Responsibility After Authoring Sessions: Authoring tools are not responsible for accessibility problems that result from carrying out instructions made by the author during authoring sessions (e.g., the content of a third-party feed specified by the author), but they are responsible if the changes are automatically generated (e.g., the developer makes site wide changes to a CMS).

<Reed> thanks zakim

<jeanne> new version on line: http://www.w3.org/WAI/AU/2008/WD-ATAG20-20081023/MASTER20081023.html#part-support-production

<JR> JR Proposal: May Switch Views: permissible to require authors to switch editing views to perform search results (e.g., from WYSIWYG to instruction level to search for markup tags).

<jeanne> issue: A.3.6 needs to be focused for needs specific to authoring tools

<trackbot> Created ISSUE-168 - A.3.6 needs to be focused for needs specific to authoring tools ; please complete additional details at http://www.w3.org/WAI/AU/tracker/issues/168/edit .

<JR> ACTION: JR to To propose text for "Manage preference settings" to make it more authoring tool specific (Issue-168) [recorded in http://www.w3.org/2008/10/23-au-minutes.html#action05]

<trackbot> Created ACTION-29 - Propose text for \"Manage preference settings\" to make it more authoring tool specific (Issue-168) [on Jan Richards - due 2008-10-30].

<JR> was: (i.e., moving focus back from, exiting from)

<JR> JR: Could we just remove the example?

<Reed> jr: moving focus back from, exiting from

<Reed> js: it's a little complicated as it is right now

<Reed> cs:they all seem to say the samething

<Reed> jan is rewriting the section

<JR> If a preview is provided, then a keyboard accessible way of returning from the preview is provided and is documented in the help system.

<Reed> talking about the concept of simple action

<JR> If a preview is provided, then it is possible to return from the preview using a simple action which is documented in the help system.

<Reed> discussing whether things must be seperately documented in the authoring tool help system

<Reed> JS: we should add video player component

<Reed> CS: multiple levels of component don't make sense

<Reed> multiple people: how do we know what it is calling?

<Reed> JR: just conform what it will call for

<Reed> many: why do we need this at all then?

<Reed> everyone ok with dropping previewers just for the sake of having them? reword?

<JR> the preview makes use of an existing user agent (e.g., opening the content in a third-party browser, browser component, video player, etc.)

<rshaffne> Discussing A3.7.2

<jeanne> new update http://www.w3.org/WAI/AU/2008/WD-ATAG20-20081023/MASTER20081023.html#tool-previews-scA

<rshaffne> scribe: rshaffne

<scribe> continued debate on whether we need to ahve this section at all

UAAG agrees to buy drinks

fix, jallan agrees to buy drinks

<jallan> in austin, texas

talking about undo

usability versus accessibility

CS: you may not know you made a mistake until you already looked in a browser

talkign about A4.1.5

CS: should save force settings, again usability versus accessibility?

JR: we should put in notes that killing undo on save may negatively impact some users

<JR> It is acceptable for certain committing actions (e.g., "save", "publish") to reset the undo history.

RS: some note about how this might negatively impact some users

Moving on to A4.2

RS: maybe for triple aa talk about providing tutorials for key features accessibly?

JR: some instead of key

<jeanne> new version: http://www.w3.org/WAI/AU/2008/WD-ATAG20-20081023/MASTER20081023.html#principle-understandable

<JR> A.4.2.2 AAA Accessibility Feature Tutorials: Tutorials are provided for some of the features that are specifically required to meet Part A of these guidelines.

JR: are people ok with this?

general agreement

do we need to say not to document documentation?

seems people are in agreement there should be some sort of help description

JR: Jutta needs to drop off for a panel

JS: before we leave 4.2.2 what do we mean by some for tutorials?

JR; should provide how to get to things

RS: do we need to just copy and paste?

JR: then should we eliminate our other keyboarding pieces?

all: no no, just include what's unique

JR: we basically need to focus on new things we need to say then, ok

there is discussion going on about what should be in ATAG versus UAAG versus both

and what goes where just because something is a standard first

no keyboard trap

<JR> 4.1.2 No Keyboard Trap: The authoring tool prevents keyboard traps as follows (Level A):

<JR> (a) in the UI: if keyboard focus can be moved to a component using the keyboard, then focus can be moved away from that component using standard sequential keyboard commands (e.g., TAB key),

<JR> (b) in the rendered editing views: provides a documented direct keyboard command that will always restore keyboard focus to a known location (e.g., the menus), and

<JR> (c) in the rendered editing views: provides a documented direct keyboard command that will always move keyboard focus to a subsequent focusable element

RS: keep specific examples

<JR> A.3.1.1 Important Command Functions: If the authoring tool includes any of the following functions, authors can enable key-plus-modifier-key (or single-key) access to them (where allowed by the operating environment)(Level A):

<JR> (a) open help system,

<JR> (b) open new content,

<JR> (c) open existing content,

<JR> (d) save content,

<JR> (e) close content,

<JR> (f) cut/copy/paste,

<JR> (g) undo/redo, and

<JR> (h) open find/replace function.

<JR> 4.1.2 No Keyboard Trap: The authoring tool prevents keyboard traps as follows (Level A):

<JR> (a) in the UI: if keyboard focus can be moved to a component using the keyboard, then focus can be moved away from that component using standard sequential keyboard commands (e.g., TAB key),

<JR> (b) in the rendered editing views: provides a documented direct keyboard command that will always restore keyboard focus to a known location (e.g., the menus), and

<JR> (c) in the rendered editing views: provides a documented direct keyboard command that will always move keyboard focus to a subsequent focusable element

<JR> 4.1.5 Discovery of Keyboard Commands: Authors have the global the option to have any *recognized* direct keyboard commands displayed with their associated controls. (Level A)

JR: could we put out a note with UAAG?
... helps explain why things came to be and things we were thinking about

CS: what do you want to talk about?

JR: we have been thinking about keyboarding a lot and we joined forces and we came up with this

most is general software but some tweaks are authoring tools

<scribe> ACTION: JR figure out the note on keyboarding [recorded in http://www.w3.org/2008/10/23-au-minutes.html#action06]

<trackbot> Created ACTION-30 - Figure out the note on keyboarding [on Jan Richards - due 2008-10-30].

JR: certain things should be deprecated still

Jeanne handling

A general feeling of satisfaction passes over the room

DAY ADJOURN

<jeanne> scribenick: AndrewR, reed, rshaffna

This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/JS: Also don't think /Janina: Also don't think/
WARNING: Bad s/// command: s/ s/JS: Also don't think /Janina: Also don't think /
Found embedded ScribeOptions:  -final

*** RESTARTING DUE TO EMBEDDED OPTIONS ***

WARNING: Bad s/// command: s/ s/JS: Also don't think /Janina: Also don't think /
Found Scribe: Andrew
Found Scribe: rshaffne
Inferring ScribeNick: rshaffne
WARNING: No scribe lines found matching previous ScribeNick pattern: <AndrewR\,\ reed\,\ rshaffna> ...
Found ScribeNick: AndrewR, reed, rshaffna
WARNING: No scribe lines found matching ScribeNick pattern: <AndrewR\,\ reed\,\ rshaffna> ...
Scribes: Andrew, rshaffne
ScribeNicks: AndrewR, reed, rshaffna, rshaffne
Default Present: Jan_Richards, Jeanne_Spellman, Andrew_Ronksley, Reed_Shaffner, +0208123aaaa, Room_138, AnnM, Jutta, Jim_Allan(observing), Joshue
Present: Jan_Richards Jeanne_Spellman Andrew_Ronksley Reed_Shaffner Janina Sajka(Observing) +Jim_Allan(observing) Joshue_O'Connor(observing)
Regrets: Dana Simberkoff
Got date from IRC log name: 23 Oct 2008
Guessing minutes URL: http://www.w3.org/2008/10/23-au-minutes.html
People with action items: jr reed rs

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.