User Agent Accessibility Guidelines Working Group Teleconference -- 27 Aug 2013

<trackbot> Date: 27 August 2013

<jeanne> meeting: UAWG F2F

<kford> Scribe: kford

<Jan> http://www.w3.org/WAI/UA/UAAG20/

<Jan> http://www.w3.org/WAI/UA/2013/commentsWD.html

OCAD 48 5.1.2

Group talking about different locations for this point.

Group sees some value in moving standards compliance earlier

Group talking about numbering.

And perceived importance.

KP: We covered some of the suggestions around standards in the last editorial pass.

Resolution: Groupdecided to leave 5.1.2 as is and OCAD is closed.

OCAD 46 4.1.6

<Jan> ACTION: Jeanne to check capitalization of handle of 5.1.2 and 5.1.3 [recorded in http://www.w3.org/2013/08/27-ua-minutes.html#action01]

<trackbot> Created ACTION-870 - Check capitalization of handle of 5.1.2 and 5.1.3 [on Jeanne F Spellman - due 2013-09-03].

JA 4.1.6 is related onscreen text

<AllanJ> 4.1.6 OCAD46

<AllanJ> proposal not accepted. 416 items are related to onscreen text.

<AllanJ> 412 are related to user interface components that have a name, role, state.

GL: 4.1.6 K seems a bit quirksome.

Group talks about history.

JAN: Going to be hard to find implamentations.

More discussion from GL and JR if parts of 4.1.6 are to platform specific.

More discussion about separating 4.1.2 and 4.1.6

JR: We do this separation in speech.

JR reads from what we have in the doc around speech.

JR: The speech model is an understandable model.

KP I agree

Discussion about keeping them separate, similar to what we do with speech synthesis.

JR now describing how ATAG conveys similar info from this area.

KP asking if 4.1.1 covers this info.

KP asking if 4.1.1 covers this info.Selection and focus are really important. They shuld be moved to 4.1.2 and then move leave 4.1.6

<Jan> 4.1.2 Expose basic properties: For all user interface components including user interface, rendered content, generated content, and alternative content, the user agent makes available the following, via a platform accessibility service: (a) name, (b) role, (c) state, (d) value, (e) selection, (f) focus. (Level A)

Group working on reworiding for 4.1.2 and 4.1.6

<Jan> 4.1.2 Expose basic properties: For all user interface components including the user agent user interface, rendered content, generated content, and unrendered alternative content, the user agent makes available the following, via a platform accessibility service: (a) name, (b) role, (c) state, (d) value, (e) selection, (f) focus. (Level A)

<Jan> 4.1.2 Expose basic properties: For all user interface components including the user agent user interface, rendered content, and generated content, the user agent makes available the following, via a platform accessibility service: (a) name, (b) role, (c) state, (d) value, (e) selection, (f) focus. (Level A)

<Jan> 4.1.2 Expose basic properties: For all user interface components, including the user agent user interface, rendered content, and generated content, the user agent makes available the following, via a platform accessibility service: (a) name, (b) role, (c) state, (d) value, (e) selection, (f) focus. (Level A)

<Jan> 4.1.6 Expose additional properties: For all user interface components, including the user agent user interface, rendered content, and generated content, the user agent makes available the following, via a platform accessibility service, if the properties are supported by the service: (a) the bounding dimensions and coordinates of onscreen elements, (b) font family of text, (c) font size of...

<Jan> ...text, (d) foreground color of text, (e) background color of text, (f) highlighting, (g) keyboard commands. (Level AA)

<Jan> ...text, (d) foreground and background colors for text, (e) highlighting, (f) keyboard commands. (Level AA)

<Jan> 4.1.6 Expose Additional Properties: For all user interface components, including the user agent user interface, rendered content, and generated content, the user agent makes available the following, via a platform accessibility service, if the properties are supported by the service: (a) the bounding dimensions and coordinates of onscreen elements, (b) font family of text, (c) font size of...

<Jan> ...text, (d) foreground and background colors of text, (e) highlighting, (f) keyboard commands. (Level AA)

<Jan> 4.1.2 Expose Basic Properties: For all user interface components, including the user agent user interface, rendered content, and generated content, the user agent makes available the following, via a platform accessibility service: (a) name, (b) role, (c) state, (d) value, (e) selection, (f) focus. (Level A)

<Jan> 4.1.6 Expose Additional Properties: For all user interface components, including the user agent user interface, rendered content, and generated content, the user agent makes available the following, via a platform accessibility service, if the properties are supported by the service: (a) the bounding dimensions and coordinates, (b) font family of text, (c) font size of text, (d) foreground...

<Jan> ...and background colors of text, (e) highlighting, (f) keyboard commands. (Level AA)

<Jan> 4.1.6 Expose Additional Properties: For all user interface components, including the user agent user interface, rendered content, and generated content, the user agent makes available the following, via a platform accessibility service, if the properties are supported by the service: (a) bounding dimensions and coordinates, (b) font family of text, (c) font size of text, (d) foreground and...

<Jan> ...background colors of text, (e) highlighting, (f) keyboard commands. (Level AA)

<scribe> Scribe: JR

<Jan> Scribe: Jan

Resolution: All agree to use "4.1.2 Expose Basic Properties: For all user interface components, including the user agent user interface, rendered content, and generated content, the user agent makes available the following, via a platform accessibility service: (a) name, (b) role, (c) state, (d) value, (e) selection, (f) focus. (Level A) "
... All agree to use "4.1.6 Expose Additional Properties: For all user interface components, including the user agent user interface, rendered content, and generated content, the user agent makes available the following, via a platform accessibility service, if the properties are supported by the service: (a) bounding dimensions and coordinates, (b) font family of text, (c) font size...
... of text, (d) foreground and background colors of text, (e) highlighting, (f) keyboard commands. (Level AA)"

<jeanne> http://www.w3.org/WAI/UA/2013/ED-UAAG20-20130827/MasterUAAG20130827.html

<jeanne> todays Master document <- http://www.w3.org/WAI/UA/2013/ED-UAAG20-20130827/MasterUAAG20130827.html

<Admin> 4.1.6 add to end of Intent:

<Admin> Keyboard commands include direct keyboard commands (e.g. Control-f to select the find box) and keyboard sequences (e.g. Alternate-f, to call up the File menu and select Save As).

Definition of: user interface

For the purposes of UAAG 2.0, *user interface* includes both:

- the *user agent user interface*: the controls (e.g. menus, buttons, prompts, and other components for input and output) and mechanisms (e.g. selection and focus) provided by the user agent ("out of the box") that are not created by content.

- the *content user interface*: the renderings created from the content, such as text, images, form controls, links, and applets.

The document distinguishes them only where required for clarity.

The term *user interface control* refers to a component of the user agent user interface or the content user interface, distinguished where necessary.

<AllanJ> user agent user interface should include extensions that become part of the user agent user interface (e.g. toolbars, additional menus, etc.)

<kford> RRSAgent: JA: Explain the difference between 4.1.1 and 5.1.3

<kford> JA: Explain the difference between 4.1.1 and 5.1.3

<greg> scribe: greg

Jan: 5.1.3 is about UI design, whereas the 4.1 is about exposing things to assistive technology.

Resolution: 4.1.2 and 4.1.6 are done, having moved some bullet items from .6 to .2, reduced priority of .6 to AA, and done significant wordsmithing.

<jeanne> #1 of user interface: the user agent user interface, the controls (e.g. menus, buttons, prompts, and other components for input and output) and mechanisms (e.g. selection and focus) provided by the user agent ("out of the box") that are not created by content. The user agent user interface also includes extensions that become part of the user agent user interface (e.g. toolbars, additional menus,

<jeanne> etc.)

OCAD45 re 4.1.5

re 4.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. (Level A)

OCAD45: Still isn't possible for ARIA as far as I know.

<AllanJ> This is unrelated to ARIA. it is only to allow AT to write to the interface the same way a user can when using a mouse or keyboard.

Jan: It is related to ARIA because UI means both UA UI and rendered content.
... When an element's state is set using a script, it sets the ARIA state, causing the UA to set a state in the platform API.
... Joseph says that for Javascript-drawn checkbox, if you change its state using MSAA the UA does not correctly communicate this to the author's javascript, because it's not due to a Check Event.

<AllanJ> is this another case of javascript being a blackhole, it is unrecognized by user agent or msaa?

Greg: Is that a UA bug?

Jan: More that everything hasn't been worked out yet.

Greg: If AT uses MSAA to check a checkbox, the UA should map that to an event such as click that it can send to the script, thus hiding the fact that it was not done by a user with a real input device.

Jeanne: Seems really important.

Jim: Seems to fall into the broad category of javascript problems.

Kelly: It will always be the case that there are situations where things cannot be done programmatically.

Greg: It's important to ensure that AT can be used to edit content and driving UI the same was as mouse or keyboard, and we do want to support platform API as the method so that AT can be written to be app-neutral.

Jan: It isn't worded to require platform API, just some programmatic method.

Kelly: Can we take ARIA out of the equation?

Jan: Gmail is an example of a complex script that keeps lots of its own state information.
... Browser has no problem changing state of a checkbox...

Kelly: the browser should expect read and write to everything through the platform API.

Jan: Agreed.

Kelly: Thus ARIA seems irrelevant here.

Jan: Just calling out that ARIA does not solve the write-access part of the problem.
... Using ARIA the UA and AT know this element acts as a checkbox...
... ...maybe this is fine, and authors just need to catch up.

Kelly: I'd leave this, despite implementation questions.

Jan: Just wanted to call this out as an issue.

<AllanJ> +1 leaving it as is

Kelly: I want to find out what Chrome and other UA do, what events are bubbled to scripts when element state is changed programmatically.
... The general requirement is still true, this general state is what we need, we assume recognized part is covered somewhere else (at a high level)...

Greg: Despite the wording of the comment, this is not about ARIA but about whether scripts get notified and *can* handle it correctly when element state is changed programmatically by anything other than the script itself.

Jan: Correct.

Kelly: I think we're okay on this.

Resolution: No change. The general requirement is still true. Scripts need to be notified by the browser when element state is changed, including changed programmatically.

OCAD43 re 3.4.1

3.4.1 Avoid unpredictable focus: The user can prevent focus changes that are not a result of explicit user request. (Level A)

OCAD43: This seems like the superset (and so the possible replacement) of 1.8.9 and 2.1.4.

1.8.9 Open on Request: The user can specify whether author content can open new top-level viewports (e.g. windows or tabs). (Level AA)

2.1.4 Separate Selection from Activation: The user can specify that focus and selection can be moved without causing further changes in focus, selection, or the state of controls, by either the user agent or author content. (Level A)

<AllanJ> agree that 3.4.1 is the more general case that includes 1.8.9 (189 should be removed) and is only about focus changes. except 189 allows configuration??

<AllanJ> 2.1.4 is about change in state of selection for radio buttons and checkboxes when an item receives focus. this is different than moving focus in an unpredictable manner. 2.1.4 should remain as is.

Jim: Agreed 3.1.4 is a more general case that includes 1.8.9, the latter could be removed, except 1.8.9 allows configuration as well.
... opening a new viewport changes focus...

Greg: Opening a new viewport may not change focus, based on UA configuration as well as scripted behaviors.

Jan: 3.4.1 is alone in 3.4 which is about predictable behaviors. Could anything else fit there?

Greg: Examples of unpredictable behavior might include changing visible portion when window resized, random tab order when not specified by author, allowing scripts to close windows or tabs, etc.

Kim: Tons of examples for 3.4.1 in the Implementing document. Most along the Perceivable lines.

Jan: 1.8.9 and 2.1.4 are separate enough that they deserves to live.

Kim: Each is necessary in its context, fitting in and contributing to the SC around them.

<AllanJ> leaving these alone seems fine to me.

<AllanJ> does no harm currently.

Greg: We could leave it for now; if Jan finds a better way to combine or reorganize later he can submit that, but it seems we could move on for now.

Jan: Goal is to streamline and shorten the document, and prevent readers from being turned off by perceived repetition.

Kelly: two questions: does experience say this will be a problem, and what's the cost of message around with it at this point.

Jan: if we felt 3.4.1 was completely covered by 2.1.4, we could safely remove it and not lose anything, combine the examples, etc.

Kim: That would be better, taking out the one that has no context would be better than taking out either of the two others.

Jeanne: Think these need to stay so that we don't lose the whole "unpredictable" part.

Resolution: Keep 3.4.1, 2.1.4, and 1.8.9 as are for now; Jan may come back with proposal later.

OCAD39 re 2.11.8

2.11.8 Track Enable/Disable of Time-Based Media: During time-based media playback, the user can determine which tracks are available and select or deselect tracks, overriding global default settings, such as captions or audio descriptions. (Level AA)

OCAD39: Both the examples in the implementing document are taken care of by something in GL1.1? So perhaps this can be removed.

<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2013JulSep/0039.html

Jim: 2.11.8 is covered by 1.1.1 and is an implementation detail. remove 2.11.8 add example to 1.1.1 Betty, has an auditory processing problem. she is watching a movie that has several caption and audio tracks . She pulls up a menu to determine which is available she switches between audio tracks until she find one she can understand. She also reinforces the audio by selecting a caption track.

<Jan> 1.1.1 Render Alternative Content: The user can choose to render any type of recognized alternative content that are present for a content element. (Level A)

1.1.1 Render Alternative Content: The user can choose to render any type of recognized alternative content that are present for a content element. (Level A)

Greg: They are not the same as 1.1.1 is about all forms of tracks, whereas 2.11.8 is just alternative content.
... Neither is a subset of the other.

Jan: Our media player handles enabling/disabling alternative content tracks, but not other tracks, so should it fail?

Greg: A use case a is if a video had a dialog track and a music track, for example, a person with impaired hearding or cognition may need to disable the background noises in order to understand the speech.

Jan: Our tool should never be able to meet AA compliance then?

Greg: We're saying that right now such a tool meets A but not AA because it doesn't let the user choose to disable arbitrary tracks.
... Another use case is my former coworker who had seizures triggered by low-level sounds such as white noise, and so had to turn off any audio that included fountains, surf, and the like.

Jan: 2.11.8 is semi-redundant to 1.5.1 Global Volume, which lets the user turn down (off) audio tracks. However, it doesn't handle differenent video tracks.

Jan interprets the SC as about alternative content, whereas Greg interpreted it as being about tracks in general. Greg emphasized "tracks", while Jan emphasized "such as captions and audio description".

Jan: Greg's two use cases would be covered by 1.5.1.

<Jan> Jan: Any concerns about audio track levels is handled by 1.5.1 Global Volume: The user can adjust the volume of each audio tracksindependently of other tracks, relative to the global volume level set through operating environment mechanisms. (Level A)

<jeanne> ACTION: jeanne to move examples from 2.11.8 to 1.1.1 and remove 2.11.8 [recorded in http://www.w3.org/2013/08/27-ua-minutes.html#action02]

<trackbot> Created ACTION-871 - Move examples from 2.11.8 to 1.1.1 and remove 2.11.8 [on Jeanne F Spellman - due 2013-09-03].

Decided that we don't need 2.11.8's ability to disable video tracks, because the only important use cases we come up with involve alternative media, which are covered by 1.1.1.

The important use cases regarding non-alternative audio tracks are covered by 1.5.1.

Resolution: Delete 2.11.8 and move its examples and intent to 1.1.1.
... Add to 1.5.1 Examples the use case above about a person who has seizures triggered by low-level sounds such as white noise, and so has to turn off any audio that included fountains, surf, and the like.

<AllanJ> example: Betty, has an auditory processing problem. she is watching a movie that has several caption and audio tracks . She pulls up a menu to determine which is available she switches between audio tracks until she find one she n

<AllanJ> understand. She also reinforces the audio by selecting a caption track.

<jeanne> ACTION: Jeanne to add Betty example from Jim's email of 27 August 2013 to 1.1.1 [recorded in http://www.w3.org/2013/08/27-ua-minutes.html#action03]

<trackbot> Created ACTION-872 - Add betty example from jim's email of 27 august 2013 to 1.1.1 [on Jeanne F Spellman - due 2013-09-03].

OCAD34 and OCAD35, re 2.10.1 and 2.10.2

2.10.1 Three Flashes or Below Threshold: In its default configuration, the user agent does not display any user interface components or recognized content that flashes more than three times in any one-second period, unless the flash is below the general flash and red flash thresholds. (Level A)

2.10.2 Three Flashes: In its default configuration, the user agent does not display any user interface components or recognized content that flashes more than three times in any one-second period (regardless of whether not the flash is below the general flash and red flash thresholds). (Level AAA)

OCAD34: (Re 2.10.1) This is good for the User Agent UI, but hard to automatically determine in playing content. Perhaps 2.11.1 handles this?

OCAD35: (Re 2.10.2) Could this also then be removed? (related to comment OCAD34)

<AllanJ> jim's proposal: remove 2.10.1 and promote 2.10.2 to A (UI should not be doing this anyway, no browser does this so easy check), and change wording of 2.10.2 to : 2.10.2 Three Flashes: In its default configuration, the user agent does not display any user interface components that flashes more than three times in any one-second period (regardless of whether not the flash is below the general...

<AllanJ> ...flash and red flash thresholds). (Level A) [removed 'or recognized content' and changed level from AAA to A]

<AllanJ> or keep 2.10.2 at AAA but still change wording. and keep 2.10.1 but change wording to

<AllanJ> 2.10.1 Three Flashes or Below Threshold:In its default configuration, the user agent does not display any user interface components that flashes more than three times in any one-second period, unless the flash is below general flash and red flash thresholds. (Level A) [removed "or recognized content"]

Greg: I'd just cut out the "or rendered content" from both.

Jan: A person who needs to avoid flashing already has the ability to avoid videos until they approve them.

Resolution: remove "or recognized content" from 2.10.1 and 2.10.2.

OCAD33 re 2.9.2

2.9.2 Retrieval Progress: By default, the user agent shows the progress of content retrieval. (Level A)

OCAD33: I think this is in the wrong GL, it doesn't allow time-independent interaction

<Kim> addition to intent of 2.10.1 and 2.10.2:

<Kim> It's recommended that this also be applied to recognized content.

<AllanJ> jim's comment -

<AllanJ> Agree, this is not about time independence. the download monitor is informing the user of what is happening. seems better in Understandable (GL4).

<AllanJ> however,

<AllanJ> Every browser does this. informing the user about downloading status is basic usability; as long as the download monitor is programatically accessible and its messaging is accessible as per our other guidelines. Proposal Delete it.

Greg: Some browsers (e.g. Blackberry browser) don't tell you how much is being downloaded, just that *something* is being downloaded.

Kelly: Recommend deleting this SC.

Kim: For some people with disabilities its much more difficult if they have to start over. especially if they thought it was necessary when it wasn't.
... I've watched users go around and around and around trying it over and over again, which can use up their entire day's maximum amount of typing.

Kelly: The examples included don't make a sufficient case for differential benefit for people with disabilities.

Jim: The original comment was that this was in the wrong SC, but couldn't find a good place for it under Perceivable.

Kelly: Willing to keep it if we move it and give it a more compelling example.

Greg: I think it's important to clarify what this requires: does it mean percent complete, or it it enough to distinguish between "done" and "not yet done"?

Kelly: Another reason for keeping it is that one often has a limited number of times you can ask for help.

Jan: Like the idea of phrasing it as "state of content retrieval activity", rather than "progress of content retrieval".

Greg: Should this also be about processing/rendering, as opposed to just about downloading? For example if the knows the page is still being rendered and so is still running and not yet ready to accept input, should the user be told?

Jim: Propose keep the SC but move to 3.2, and add a new example that Kim will write.

Resolution: Keep SC 2.9.2 but move to 3.2, and add a new example that Kim will write.

OCAD31 re 2.8.1

<AllanJ> jim's comment: proposal. leave it. it was many SC, they were combined because they all interrelated and built upon each other.

2.8.1 Customize display of controls representing user interface commands, functions, and extensions: The user can customize which user agent commands, functions, and extensions are displayed within the user agent's user interface as follows:(Level AA) (a) Show: The user can choose to display any controls available within the user agent user interface, including user-installed extensions. It...

scribe: is acceptable to limit the total number of controls that are displayed onscreen. (b) Simplify: The user can simplify the default user interface by choosing to display only commands essential for basic operation (e.g. by hiding some control). (c) Reposition: The user can choose to reposition individual controls within containers (e.g. Toolbars or tool palettes), as well as reposition the...
... containers themselves to facilitate physical access (e.g. To minimize hand travel on touch screens, or to facilitate preferred hand access on handheld mobile devices). (d) Assign Activation Keystrokes or Gestures: The user can choose to view, assign or change default keystrokes or gestures used to activate controls. (e) Reset: The user has the option to reset the containers and controls...
... to their original configuration.

OCAD31: This SC is probably twice as long as the next biggest. Has a different feel.

<AllanJ> jim's comment: proposal. leave it. it was many SC, they were combined because they all interrelated and built upon each other.

Jan: Okay with that.

<Kim> Extra example for 2.9.2 which is going to be moved to 3.2 Larry has severe repetitive strain injuries and is limited to typing for only a short period of time every day. He downloads a long document, and is surprised to see that the download is progressing slowly. He periodically checks the progress bar rather having to type to repeatedly check to see if it's done.

Jan: Recognize it would be a lot of work to split 2.8.1 back into multiple SC, along with their Examples, etc.
... Odd to use "GUI" in the Guideline's title.

Jeanne: Will change that to "graphical" controls.

<jeanne> ACTION: jeanne to go through the guidelines and remove any period at the end of a guideline. [recorded in http://www.w3.org/2013/08/27-ua-minutes.html#action04]

<trackbot> Created ACTION-873 - Go through the guidelines and remove any period at the end of a guideline. [on Jeanne F Spellman - due 2013-09-03].

(The group worked on and incorporated Kim's new example for showing status of retrieval progress.)

OCAD27 re 2.6.1 Access to input methods

2.6.1 Access to input methods: The user can discover recognized input methods explicitly associated with an element, and activate those methods in a modality independent manner. (Level AA)

OCAD27: User can discover?

<AllanJ> jim's proposal: 2.6.1 Access to input methods: The user can have presented any recognized input methods explicitly associated with an element, and activate those methods in a modality independent manner.

Kim: "the user can have presented" is ambiguous language, as it could be misread as "the user can have (themselves) presented" as opposed to "the user can have presented (to them)".

Greg: "The user can determine which input methods" or "The user can identify the input methods"?

Kelly: Can't say "the user can" as the UA doesn't know what the user is and is not capable of perceiving. The SC can't test the user.

<Kim> The user agent provides a means for the user to determine recognized input methods explicitly associated with an element, and a means for the user to activate those methods in a modality independent manner.

Resolution: Change 2.6.1 to read "The user agent provides a means for the user to determine recognized input methods explicitly associated with an element, and a means for the user to activate those methods in a modality independent manner."

OCAD26 re 2.5.3

2.5.3 Configure Elements for Structural Navigation: The user can configure sets of important elements (including element types) for structured navigation and hierarchical/outline view. (Level AAA)

OCAD26: "configure sets of" implies ability to create multiple sets

<AllanJ> jim's comment: this is level AAA, I know of no UA that does this. Suspect it will be eliminated because of lack of implementation.

<AllanJ> Proposal: reword (make it singular)

<AllanJ> 2.5.3 Configure Elements for Structural Navigation: The user can configure a set of important elements (including element types) for structured navigation and hierarchical/outline view.

Resolution: Change 2.5.3 to read "2.5.3 Configure Elements for Structural Navigation: The user can configure a set of important elements (including element types) for structured navigation and hierarchical/outline view. (AAA)"

OCAD25 re 2.5.2

2.5.3 Configure Elements for Structural Navigation: The user can configure sets of important elements (including element types) for structured navigation and hierarchical/outline view. (Level AAA)

2.5.2 Navigate by structural element: The user agent provides at least the following types of structural navigation, where the structure types exist:(Level AA) (a) by heading (b) within tables

OCAD25: How is this related to 1.10.1?

<AllanJ> jim's comment: proposal: remove reference for 2.5.2 in Related resources for 1.10.1

Resolution: from "2.5.1 Location in Hierarchy" Remove from 1.10.1 Related Resources.

OCAD24 re 1.10.2

Jan: This reference wasn't actually in 1.10.2 any more, so this is moot.

Jim: But also propose deleting 1.10.2.

2.5.2 Navigate by structural element: The user agent provides at least the following types of structural navigation, where the structure types exist:(Level AA) (a) by heading (b) within tables

<Jan> 1.10.2 Access to Element Hierarchy: The user can determine the path of element nodes going from the root element of the element hierarchy to the currently focused or selected element. (Level AAA)

Starting over...

<Jan> 2.5.1 Location in Hierarchy: When the user agent is presenting hierarchical information, but the hierarchy is not reflected in a standardized fashion in the DOM or platform accessibility services, the user can view the path of nodes leading from the root of the hierarchy to a specified element. (Level AA)

1.10.2 Access to Element Hierarchy: The user can determine the path of element nodes going from the root element of the element hierarchy to the currently focused or selected element. (Level AAA)

The question is, are these redundant to each other?

Greg: I thought the distinction was that one was about hierarchy of nodes in the DOM, the other was about hierarchy of information NOT in the DOM such as artists, albums, etc. in a media library.

2.5.1 is iTunes Library (for example), 1.10.2 is the DOM.

Agreement that they read confusingly similarly.

Greg: I believe this was originally Simon's SC.
... I would not object to deleting 2.5.1, as it's only AAA.

Jim: The comment was that they seemed to be the same, but discussion reveals they are very different. The question of whether 2.5.1 should stay, or be reworded, or deleted, is an open issue.

Jan: If we as a group had trouble understanding it, it is potentially a problem.
... the original OCAD comment was very minor, only about a problem in the IER.

<Jan> ACTION: Jan to look at 2.5.1 Location in Hierarchy including possibly to check in with Simon. [recorded in http://www.w3.org/2013/08/27-ua-minutes.html#action05]

<trackbot> Created ACTION-874 - Look at 2.5.1 location in hierarchy including possibly to check in with simon. [on Jan Richards - due 2013-09-03].

Resolution: closed comment OCAD24, accepted.

OCAD22 re 2.3.5

2.3.5 Customize Keyboard Commands: The user can override any keyboard shortcut including recognized author supplied shortcuts (e.g. accesskeys) and user agent user interface controls, except for conventional bindings for the operating environment (e.g. arrow keys for navigating within menus). The rebinding options must include single-key and key-plus-modifier keys if available in the...

scribe: operating environment. The user must be able to save these settings beyond the current session. (Level AA)

OCAD22: Save requirement should be removed as it is covered by 2.7.1. Also the single-key and key-plus-modifier text seems like overkill.

<AllanJ> jim's comment: proposal: eliminate last sentence it is covered by 2.7.1. remove the sentence related to key-plus-modifier. That is covered by overriding accesskey which is a key plus modifier.

Greg: I don't think it's obvious to a developer that 2.7.1 would cover this, but if we add to 2.7.1 a list of potentially overlooked implications such as this, then I'd be okay deleting this sentence.

Kelly: Concern that if the user needs to be able to rebind the "D" key, it can make normal functionality unusable.

Kim: Need to redo it, as if you're doing speech recognition and every key is interpreted as a long series of commands, it's a real problem.

Jan: It doesn't say it has to allow rebinding of letter keys.

Kelly: It doesn't say otherwise.

<AllanJ> discussion of gmail and recognized keybindings....but gmail keybindings are all in javascipt and the browser is unaware of the keybindings.

<AllanJ> scribe: allanj

kp: there are more webapps using single key keybindings. these are a huge problem

<greg> Kim: Increasing number of web apps use single letter keys as command, and that's a problem.

<scribe> scribe: greg

<scribe> scribe: allanj

jim describes gmail (single keys turned on) and google chat conflicting.

greg: modal commands that are context sensitive are a problem

kp: single letter commands are becoming a nightmare

srcibe: gret

<scribe> scribe: greg

Kim: Would be fine narrowing to being able to change shortcuts, but avoid requiring the user be able to rebind letter keys.

Discussion of conflicts between webapp key commands and those of the user agent.

Kim: In favor of being able to redefine keys that are used for commands, but not letters and so forth that aren't used for commands.

Kelly: Kim wants the user to have control over whether keypress is handled by the UA or a script, but this doesn't really address that.

<AllanJ> briefly discussed the previous SC related to the browser serving itself first (keybindings) before javascript. currently all browsers let javascript have the keybindings first then anything not trapped is passed to the browser.

<AllanJ> this was removed as it was never going to be implemented.

Jan: Browsers reserve some command keys, correct?

Kelly: IE reserved Alt+D; cannot be used as accesskey.

Jan: The UA always grabs the keys first, regardless of whether they're reserved or passed on to the script first.

<AllanJ> proposal: 2.3.5 Customize Keyboard Commands: The user can override any keyboard shortcut including recognized author supplied shortcuts (e.g. accesskeys) and user agent user interface controls, except for conventional bindings for the operating environment (e.g. arrow keys for navigating within menus). The user must be able to save these settings beyond the current session. (Level AA)

<AllanJ> perhaps remove the last sentence also, and add a statement about saving in the intent.

Kim, Jan and Greg agree on removing the Save from the SC and instead noting it in the IER.

<AllanJ> add to the intent "the user should be able to save these settings beyond the current session"

<Kim> The user should be able to save, import and export these settings.

<AllanJ> add to related resources: GL 2.7

<AllanJ> proposal proposal: 2.3.5 Customize Keyboard Commands: The user can remap any keyboard shortcut including recognized author supplied shortcuts (e.g. accesskeys) and user agent user interface controls, except for conventional bindings for the operating environment (e.g. arrow keys for navigating within menus). (Level AA)

Greg: I don't like the idea that UA could allow remapping only to a very limited set of inputs, such as Ctrl plus a single letter (which is a real-world case), but I'm not going to fight about it.

<AllanJ> opera allows remaping, firefox does with extension

<AllanJ> opera only allows remaping of accesskeys, but not its own controls

Jan: We may have difficulty finding implementations that let one remap *all* keyboard commands.

Resolution: Accept wording 2.3.5 Customize Keyboard Commands: The user can remap any keyboard shortcut including recognized author supplied shortcuts (e.g. accesskeys) and user agent user interface controls, except for conventional bindings for the operating environment (e.g. arrow keys for navigating within menus). (Level AA)

OCAD16 re 2.1.4

OCAD16: Does "author content" need a definition? Sometimes also says "author supplied"

<AllanJ> proposal: 2.1.4 Separate Selection from Activation: The user can specify that focus and selection can be moved without causing further changes in focus, selection, or the state of controls, by either the user agent or author supplied content. (Level A)

Jim: That is, change "author content" to "author supplied content".

Greg: "The user can resize viewports within restrictions imposed by the platform."
... "The user can resize viewports within restrictions imposed by the platform, overriding any values specified by the author."

<Jan> 1.8.3 Resize Viewport: Users can maximize the size of top-level viewports up to the size of the display even if the author has specified a smaller size. (Level A)

<Jan> 1.8.3 Resize Viewport: The user can resize viewports within restrictions imposed by the platform, overriding any values specified by the author. (Level A)

Resolution: Accept wording 1.8.3 Resize Viewport: The user can resize viewports within restrictions imposed by the platform, overriding any values specified by the author. (Level A)

OCAD8 re 1.3.2

Options: When highlighting classes specified by 1.3.1 Highlighted Items, the user can specify highlighting options that include at least: (Level AA) (a) foreground colors, (b) background colors, and (c) borders (configurable color, style, and thickness)

OCAD8: This seems like too much configurability, especially if the user agent developer has chosen highlighting styling to maximize visibility within the widest variety of possible content situations. Fluid UIOptions for example enlarges input fields and makes images underlined and bold.

Resolution: Keep 1.3.2 as it is, because even though many UA developers may think they have chosen a good default highlighting option, there will be users who will require further customization.

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

27 Aug 2013

Attendees

Contents