User Agent Accessibility Guidelines Working Group Teleconference -- 03 Nov 2011

<trackbot> Date: 03 November 2011

<jeanne> Meeting: UAWG F2F Day 1

<Jan> Editors drafts prior to meeting: http://lists.w3.org/Archives/Public/w3c-wai-ua/2011OctDec/0029.html

<Jan> http://www.w3.org/WAI/UA/2011/ED-UAAG20-20111020/

<Jan> http://www.w3.org/WAI/UA/2011/ED-IMPLEMENTING-UAAG20-20111020/

<jallan> scribe: jallan

<scribe> Meeting: UAWG TPAC Face to Face Meeting - Day 1

<scribe> Chair: KellyFord, JimAllan

Attendees: GregL, KimP, JanR, MarkH, JeanneS, JimA, KellyF

<scribe> Agenda: Thursday 9 -9:15 logistics 9:15-10:30 writing 10:30-10:45 break 10:45 - 11:15 review 11:15 - 12:00 open issues 12-1 lunch 1-2:15 writing 2:15 - 2:30 break 2:30 - 3 review 3:00 - 4:15 writing 4:15-5:00 review

Discussion of A, AA, and AAA

<Jan> http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20111028/#intro_understand_levels_conformance

<Jan> http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-levels-head

gl: questions for deciding priorities

<jeanne> Greg's email on Designing Software Accessibility Standards -> http://lists.w3.org/Archives/Public/w3c-wai-ua/2009AprJun/0107.html

visitors joined - CliffT (E&O), WayneD

js: reviews history of levels in WCAG.
... they are not defined in WCAG or ATAG on purpose.

Greg reviews his email on Designing Software A11y Standards

kf: we will use a lot of this in our thinking.

jr: we could put this in the understanding conformance section ... it is informative

<scribe> ACTION: Jan to work with Greg to craft the understanding conformance in the Implementing document. [recorded in http://www.w3.org/2011/11/03-ua-minutes.html#action01]

<trackbot> Created ACTION-635 - Work with Greg to craft the understanding conformance in the Implementing document. [on Jan Richards - due 2011-11-10].

Walk through the document

<Jan> http://www.w3.org/WAI/UA/2011/ED-UAAG20-20111020/

use this version http://www.w3.org/WAI/UA/2011/ED-UAAG20-20111103/

<Jan> http://www.w3.org/WAI/UA/2011/ED-UAAG20-20111103/

jr: render means presenting to user
... alt, captions

1.1.1 needs work

jr: the handle is wrong

1.1.2 needs work -

stem not good, browse and render what?

<Jan> JR: Handle is wrong...text doesn't mention browse

<greg> 1.1.2 should we somewhere address the ability to have the alternative content presented to you without replacing the default verison, e.g. display title or alt text in pop-up or tooltip?

1.1.3 OK!

<greg> 1.1.2 JR pointed out its title doesn't really match the SC text.

1.1.4 (change stem to Rendering Alternative Cascade Order)

<greg> 1.1.1 and/or 1.1.4 should we address option to have alt content supplement rather than replace the primary content.

<greg> and/or 1.1.2

jr: @@reword 1.1.2 to include render simultaneously or make a new SC @@

1.2.1 OK

small discussion on level. Kelly AA others A

visitor - John from RIM

discussion of 1.2.2 what alt="" means.

gl: this should be off by default. should be in the intention.

kf: should be AAA

jr: @@there are use cases beyond alt, captions, build captions from voice track,@@

1.2.2 OK move to AAA

1.2.3 repair missing associations

jr: very broad, tough to evaluate

kf: kick out of uaag

gl: not specific enough, what does repair mean

kf: not practical,

jr: talks about ATAG, range of examples.
... planting seeds for best practices

cliff: this sounds like what people curse about MSWord, predicting what you want to do. or what it thinks you mean

@@in next wd - 1.2.3 what do folks think of this@@

1.2.4 broken alternative content

1.2.4 @@needs more discussion. how to test. perhaps move to gl1.1@@

1.3.1 highlighting items

1.3.1 @@review, too many options, should say "these could include". should remove f. presence of alternative content @@

1.3.2 highlighting options

<mhakkine> Something to think about re 1.2.4 future discussion: is "broken" the best term? Why not just "unrenderable"?

gl: need to change the use case in 1.3.2

@@editorial - order of 1.3.1 - 3

<greg> specifically as JR suggested, the "active keyboard focus" highlighting is a potentially confusing case.

mh: what about audiory highlighting....iphone example.

kf: not for this version of uaag.

mh: or does screen reader provide the audiory highlighting.

@@1.3.2 review, reword, add auditory(?)

1.3.3 highlighting input controls

contradicts 1.3.1 about abled/disabled items

gl: 1.3.3 is very useful.

@@1.3.3. review.

1.4.1 configure text

jr: add character and line spacing

kf: change stem to 'configure rendered text'

add d) line spacing and e) letter spacing

@@need examples

1.4.1 OK!

1.4.2 preserving size destinctions

1.4.2 OK!

1.5 volume configuration

kf: seems jarring

js: perhaps reorder

mh: it is the size of the audio

1.5.1 global volume

kf and jr: make 'however....' a note

kp; remove 'however...

wouldn't change anything.

cliff: perhaps make an if/then...make it easier to read

if the global setting is mute, then the user may overide...

example-you set an alarm, and you have muted the system, but the alarm comes through

<jeanne> 1.5.1 Global Volume:

<jeanne> The user can independently adjust the volume of all audio tracks, relative to the global volume level set through operating environment mechanisms. If the global setting is mute, the user agent may override a global mute on explicit user request that cautions the user about the implication. (Level A)

<jeanne> \

1.5.1 @@ no -- possible rewroding -- The user can independently adjust the volume of all audio tracks, relative to the global volume level set through operating environment mechanisms. If the global setting is mute, the user agent may override a global mute on explicit user request that cautions the user about the implication. (Level A)

1.6.1 OK -- needs A & B

1.6.2 speech pitch and range

mh: what about picking by voice name (perfect paul, etc)

gl: voice profiles, male female

<clifftyllick> Suggestion: Split 1.5.1 into 1.5.1 and 1.5.2. In 1.5.1, deal with reducing volume relative to the global level. In 1.5.2, deal with increasing volume relative to the global level. Ping me later if interested and I will draft such wording.

kf: add c) voice where supported

jr: is this a new sc?
... some technologies, these are sampled.
... perhaps AA
... if synthesizer supports voices, then ...

gl: change 1.6.1 to rate, volume and voice

1.6.1 @@ add c) voice (when more than one is available)

<greg> Change 1.6.1 title to "Speech Rate, Volume, and Voice".

wayne: voices are speech fonts

<greg> We reworded 1.6.2 to match 1.6.1

1.6.2 OK

1.6.3 Advance speech characteristics

kf: wording is off

1.6.4 OK

<greg> 1.6.3 changes to "The user can ADJUST..."

1.6.3 is OK

1.7.1 author style sheets

jr: css is a technique. requirement should be around typography

kp: for example author style sheets.

js: css is an html technology

jr; user can override the author provided typography with their own.

kf: combining 2 actions to 1 SC

<Jan> JR: Maybe all of 1.7 is one SC about ability to control typography

kf: turn off AND choose if they are applied
... is Level A turn off, then prompt for the others.

jr: in 1.4.1 we talk about configuring text.
... lots of other stuff you can do with style sheets

ja; 1.4.1 is simple interface for fonts, etc.

gl: make 2 SC from 1.7.1
... make a new SC, to use CSS for different purposes. use print css for on screen, use onscreen for printing.
... not just talking about typography, chunks of information, moving things about.

kf: like 1.7.3

gl: Jan, do we want to genericize this.

<greg> That is, a style sheet is an example of "styling presets"; groups of settings that are designed to work together. Per Jan's comment we might genericize this to "style sheets and equivalents".

1.7.all @@ wayne to clean up

<greg> Either in SC or Intent should make explicit that user choice of style sheets should override author-prescribed limitations such as device-type specifiers (e.g. the user should be able to use a print style sheet on the screen and a screen style sheet on a printer).

1.8.1 highlight viewport

jr: this is covered int 1.3.1

<greg> That is, 1.8.1 is equivalent but not identical to 1.3.1.d.

jr: this is a duplication (mostly) of 1.3.1

discussion of merging and location of 1.8.1.and 1.3.1

kf: remove 1.3.1 d and leave 1.8.1 as is...jr agree

wayne: when thinking about highlighting, then viewports are something to think about

jr: add note to 1.3.1 see 1.8.1 for viewports
... remove c, d from 1.3.1

kp: add note to see 1.8.1 for viewport info

<greg> The window item from 1.3.1 can be moved into 1.8, which would be renamed to "Help users use and orient within windows and viewports".

<greg> Because windows are just a subclass of viewports.

<JohnS> Scribe:johnS

Section 1.8

<Jan> http://www.w3.org/WAI/UA/2011/ED-UAAG20-20111103/

<jeanne> http://www.w3.org/WAI/UA/2011/ED-UAAG20-20111103/

Kelly: 1.8.1 is a yes

Greg: on Mono device colour is ignored

Kelly: if not possible it is not expected.

1.8.1 is good

Greg: highlight viewport
... implies only inner most viewport
... window inside is a tab, inside tab is a frame, inside fram is a input field.

Jan: the whole chain should be captured

Kelly: I think the requirement includes the whole chain
... moving on 1.8.2
... any objections?
... no objections

1.8.3 resizable

<greg> (It seems that in 1.8.1 "THE viewport" and "(incuding nested" seem contradictory, mixing singular and plural, but it's probably acceptable.)

Kim: Change to resizable viewport

Kelly: why graphical?

Jim: can't if is auditory

Jan: we can remove graphical

1.9.4

corection

1.8.4

Scrollbard

<greg> 1.8.4 Scrollbars has problems. It requires them in all cases, not allowing them to b optional. Scrollbars are one example mechanism for showing the user where they are and/or allowing them to scroll.

Jan: if the rendered content extends beyond the rendered dimentions then the scrollbar is provided

Greg: problems: 1. requires scrollbar in all cases, 2. scrollbar is one mechanism to show that content extend beyond but not the only mechanism that

shows this

Jan: can we call them scroll indicator?

Greg: this is a complicated one, so we need to move on
... I'll take an action on this and have a discussion on scroll bar

Wayne and Mark will be involved to discuss scroll bar with Greg

Jan

1.8.5 Viewport history

Kelly: I have a problem with this being Level A

<jallan> ACTION: Greg to rewrite 1.8.4 scrollbars, and Mark and Jan [recorded in http://www.w3.org/2011/11/03-ua-minutes.html#action02]

<trackbot> Created ACTION-636 - Rewrite 1.8.4 scrollbars, and Mark and Jan [on Greg Lowney - due 2011-11-10].

Kim: Why?

Kelly: The concept is great, but if I have selected a block of text and navigate away, do I have to come back with the block of text selected?

Greg: the user agent must have the ability to restore the state

Kelly: if I'm on a webpage and select some text, and navigate away, it doesn't come back.

Greg: it scroll to the right place but doesn't restore selection

Kim: firefox on a PC restrones it

Jim: a broser can't do this in a web application
... web application will break this

Kelly: the back on HTML5 is meant to do this.
... yes or no?

I can' go with yes but I think it's wrong

Greg: you would like us to qualify it to say when content is static

would not apply to dynamic content

Kelly: what is I select a header and it isn't there when I get back.

<sharper> - how long would the history stay for?

<sharper> between sessions?

Kim: I wouldn't mind if the selction went away if I came back as long as I knew the content changed

<scribe> ACTION: Jan craft 1.8.5 [recorded in http://www.w3.org/2011/11/03-ua-minutes.html#action03]

<trackbot> Created ACTION-637 - Craft 1.8.5 [on Jan Richards - due 2011-11-10].

<sharper> Are we taking a note of the things we JUNK so we don't revisit these?

1.8.6 open on request

Jim, when writting this tab was just coming into use

Kelly: most htings do this

<Jan> ACTION: JR to write a top-level conformance condition re: exception for dynamic content [recorded in http://www.w3.org/2011/11/03-ua-minutes.html#action04]

<trackbot> Created ACTION-638 - Write a top-level conformance condition re: exception for dynamic content [on Jan Richards - due 2011-11-10].

Kelly: any objection?

Greg: one question, so then web browser, the user says no, and the web browser wants to put up a dialogue box

this prevents a dialog box from poping up?

Kelly: no, this says confirmation

Greg: well this would require a confirmation before popping up a dialogue box

Jan: this talks about author content not chrome

Kelly: Top level viewport rendering author content

Greg: if the script call something to display a message box,

Jan: it is not a top level viewport

Greg: a mesage box is not?

Jan: are you talking about a dialogue box? becuase that means a top level window

Greg: not clear on the distinction between top level window ... and

Kelly: move on in 30 sec

<jallan> 1.8.6 OK!

Kelly: missing a 1.8.8

Jeanne: the renumbering will be done after the face to face

<greg> Slight concern that we don't distinguish between top-level content windows and messageboxes, e.g. if authored script calls print, browser puts up a choose printer dialog box, that is or could seem to be a top-level window.

the renumbering will happen before publishing

Kelly:

1.8.9 Close viewport

seems pretty basic to me

why is this AA?

<jallan> 1.8.7 OK!

Jeanne: because of the scripting
... when people open adds

Jan: shouldn't everybody be able to close viewprots?

what's the accessibilty extra?

Kim: when users have difficulty moving things around to close it is difficult

Jeanne:

Jan: this is not an accessibility only tihng

worried aobut the case that the top level viewport is the chrome

Kelly: this needs to go away, because there isn't a concept of closing the top level viewport

you can make them go away, but it doesn't close them

specially in the mobile world where applicaions aren't closed but goes away

Kim: when something pops up in from on the viewport, and can't reach content underneath.

Jan: I get the point, but I think this applies to all users.

Greg: iOS, it is unclear whether you are closing the window

Kelly: Windows 8, in immersive ... can't close the broser

Jeanne: get rid of 1.8.9

<jallan> 1.8.9 remove

1.8.10 Same UI

Greg: I like it

Kelly: why is this not A?

Greg: we had a lot of discusison about that

Kelly: ok

<jallan> 1.8.10 OK

1.8.11 indicate viewport position

Jan: if 1.8.4 becomes scrool indication why can't it do double duty?

Jeanne: how does it work in teh audio browser?

Jim: you querry and it tell you X% in that

Kelly: I'm ok with merging 1.8.4 and 1.8.11 Indicate viewport position

Jan: I withdraw, let's keep it simple and move on
... let's make this Level A and put it side by side with 1.8.4

1.10

provide alternative views

Simon: we werr talking about combining this with 2.7 hiertical ...

correction 2.5.7 ==2.5.7

simon: we agreed to amalgamate the two, I send some wording, but I'm trying to find out where it's comming.

Jim: 1.10.3 and 2.5.7 has the same wording

Kelly: 1.10.1 Text view
... why not call it source view?

agreed

Wayne: can we switch text source to source text?

Kelly: it's a linked termed

Jeanne: it's a definition, I need an action to change this

Simon: I think we agreed on the telecom except for Greg
... there was no action, and no comments.
... it felled off the agenda
... I'll be happy to do.

Kelly: you need to do what the groups tells you to do

Simon: I'm happy to make the changes

Jeane: one is hiertical view and one is ... the types are different

Simon: this implies operability

greg: 2 different things:
... 1. simon correctly pointed out that the ouline view should not change to an interaction outline view

2. Structural navifation should not move to a ...

Jim: that's why we have 2 diffrerent things: to allow for them

Greg: yes it's broader, the 2 requiremetns do need to remain seperate

<greg> That is, there was discussion of combining the SC about configuring elements for outline view and for structural navigation, which I believe should remain separate.

<jallan> http://www.w3.org/Search/Mail/Public/search?type-index=w3c-wai-ua&index-type=t&keywords=2.5.7&search=Search

Mark: this is talkin gabout navifation not view
... this says hieratical view, but should say navigation

Greg: we need both

Jeanne: there was a discussion where we delibrately separated into two seperate handle

Greg: I am against combining them, but I am for moving it all to navigation
... 1.10.2 outline view does not have structural view and navigation
... what about combining 1.10.3 configure elemenets for structural navigation and 2.5.7 configure elemenets for hierchical views

Simon: what's the problme? can you provide example

Greg: only show me H1 and H2, I do'nt want to see H3

for structural navigation: but take me to he next header, I mean every header, do not skip H3,H4...

you want to navigate to things that are hidden in the navigation view

simon: I understand but I don't like it

GreG: another example, if I say don't show me the structual navigation woul dbe things like take me to the next row, but I don't want to see every row shown on the outline view

Kelly: you want to navigate in more details than you want to view

Greg: when outline it up I only want to see a limited subsection
... 1.10.3 hierarchical view is wrong it sohuld say structural navigation

<mhakkine> 1.10.2 Hierarchical View: An "outline" view of rendered content is provided, composed of labels for important structural elements (e.g. heading text, table titles, form titles, and other labels that are part of the content). (Level AA) Note: The outline constitutes the important structural elements for the user (See 1.10.3). A label is defined by each markup language specification. For example, in HTML, a heading (H1-H6) is a label for the section that foll

<mhakkine> 1.10.2 Hierarchical View:

<mhakkine> 1.10.3 Configure Elements for Hierarchical View

<mhakkine> 2.5.7 Configure Elements for Structured Navigation:

simon: why can't we say the user has the option to configure important and structure

Greg: it is not the same list
... so it needs to say independent

Kelly: I'm ok with independent.
... we're moving toward the same thing.
... where does this leave us?

<jallan> proposed 1.5.x The user can independently configure the sets of important elements (including element types) for structured navigation and hierarchical/outline view. (Level AAA)

<jallan> proposed 2.5.x The user can independently configure the sets of important elements (including element types) for structured navigation and hierarchical/outline view. (Level AAA)

<jallan> proposed 2.5.x The user can independently configure the sets of important elements (including element types) for structured navigation and hierarchical/outline views. (Level AAA)

Greg: Simon's point if there's an outline view I should be able to click to navigate. it should become operable

Kelly: outline view should be first perceivable

Greg: we want user's to be able to navigate by it.
... if we're going to standardize outline, structural/hierarchical

Kelly: can I throw out an radical?
... we have 1.10.2 which is provide a hierarchical view which we call outline view

1.10.3 let you configure the elements for that

leave those alone

now we have 2.5.7 which is provide structural navigation

and another which is configure the structural navigation elements

we shouldn't combine these

scribe: I do'nt htink they should be combined because I can picture someone implementing the first one, but not the secondary

Greg: we're going to keep 4

Jan; this stays with 1,

Greg: then we're keeping eveyrthing pretty much what is is now, and cleaning up the wording and it's operable for navigation.
... we need to provide good examples for this

Wayne: we need a hook in there....

<jallan> @@ technique for 2.5.7, 1.10.2 include dialog box include in outline view, include in navigation@@

Greg: when formating, text insersion point, and viewport persists.

Kelly: it's 12:08 can we confirm

Jim: what did we decide?

<greg> So I think our plan is to keep two SC in 1.10, provide outline view and customize its elements, and two SC in 2.5, provide structural navigation and customize ts elements. Plus we will change the SC about outline view to ensure that users can navigate using it. And finally we will normalize the wordings.

Kelly: 1.10.2 is ok it just needs ot be operable

Greg: Simon are you goood wit htaht need wording?

Kelly: Simon, do you agree with this?

Simon: this has been coming back for the last 5 months and we keep going around in circles, as long as everybody agrees, let's move on

Kelly: we need work in 1.10.2 that say that the viw must be provided and must be able to operate it

Jan: I'll take the action to try to make it operable

Kelly: 1.10.2 goes on the no list

<Jan> ACTION: JR to propose how to explain that 1.10.2 outline view should be operable [recorded in http://www.w3.org/2011/11/03-ua-minutes.html#action05]

<trackbot> Created ACTION-639 - Propose how to explain that 1.10.2 outline view should be operable [on Jan Richards - due 2011-11-10].

1.10.3, title needs to change but we're good with that

1.11.1 access relationship

1.11.1

Simon: i thought someone request some changes on this

Jeanne: there are some old action items

Kelly: vote no

1.11.1 Access relationship we need to check is there are old action items attached, if none we're ok with this

Greg: on 1.11.1 the phrase based on the user's position in content is different than teh phrase we used elsewhere: based on an element

EG user can do something for an element

<greg> 1.11.1 the phrase "based on the user's position in content" is different from the phrase we use elsewhere which emphasizes based on an element.

1.11.1 needs to go into purgatory

<greg> But that's purely stylistic.

1.11.2 extended link information

Kelly: are we ok with that? AAA

<sharper> http://lists.w3.org/Archives/Public/w3c-wai-ua/2011JanMar/0046.html

<sharper> Here is the discussion

<greg> In 1.11.2 Extended Link Information, the phrase "the user agent provides" is not hthe phrase we use elsewhere for presenting info to the user.

Kelly: it's a no for no 1.11.2 extended link information because we have a thread on this
... let's break for lunch

<kford> 2.7.1 Change Preference Settings

<kford> The user can change settings that impact accessibility. (Level A)

<kford> Intent:

<kford> Users have a variety of needs when it comes to customization of a user agent. This success criteria ensures that a user can customize settings offered by the user agent to meet those needs.

<kford> 2.7.2 Persistent Accessibility Settings

<kford> : User agent accessibility preference settings persist between sessions. (Level A)

<kford> Intent:

<kford> When a user has customized settings within the user agent to maximize accessibility,

<kford> this success criteria ensures that customization is saved between browsing sessions. The user can then have those settings automatically used in subsequnet browsing sessionsrrsagent, make minutes

2.7.4 Multiple Sets of preference settings: The user can save and retrieve multiple sets of user agent preferences settings. (Level AA)

Intent Some users may need to change their setting preferences under different circumstances such as varying levels of user fatigue or changes in environmental noise or lighting conditions. Providing an easy method for saving and switching between a set of preferences helps the user complete intended tasks in different situations.

<mhakkine> 2.7.3 Restore all to default: The user can restore all preference settings to default values. (Level A)

<mhakkine> Users who configure accessibility preference settings may decide that their chosen settings may not be suitable and wish to restore these settings to their default values. For some users, it may be difficult to easily recall all modified settings while others may find it difficult to navigate to each modified setting, especially if a particular setting may have impacted their ability to do so. This success criteria provides a means for a user to easily restore

<mhakkine> This success criteria provides a means for a user to easily restore all preference settings to their default values using a single function or action.

<kford> 4.2.3 Return Focus [former 1.9.7, before that 3.11.7]:

<kford> At any time, the user agent can retrieve input focus from a nested viewport (including nested viewports that are user agents). (Level A)

<kford> Being able to return focus to a predictable location can help users orient themselves within the full range of user interface and content offered by a user agent. This success criteria ensures that the user agent can always move focus back to sucha location.

<kford> 4.2.3 Return Focus [former 1.9.7, before that 3.11.7]:

<kford> At any time, the user agent can retrieve input focus from a nested viewport (including nested viewports that are user agents). (Level A)

<kford> 4.2.3 Return Focus [former 1.9.7, before that 3.11.7]:

<kford> At any time, the user agent can retrieve input focus from a nested viewport (including nested viewports that are user agents). (Level A)

<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2011OctDec/0038.html

2.5.1

<Jan> 2.5.1 (moving to 2.3.X) Discover navigation and activation keystrokes: The user can discover direct navigation and activation keystrokes both programmatically and via perceivable labels. (Level A)

<Jan> Intent 2.5.1 (moving to 2.3.X): To ensure that users using a keyboard interface have the ability to both discover and be reminded of keystrokes, while they are using the user agent. Some of these users may be using assistive technologies enabling communication of the keystrokes by programmatic means, while other users will need visual indicators, such as underlines.

<Jan> Intent 2.5.1 (moving to 2.3.X): The user of a keyboard interface can both discover and be reminded of keystrokes. Some of these users may be using assistive technologies enabling communication of the keystrokes by programmatic means, while other users will need visual indicators, such as underlines.

<jallan> Resolution: move 2.5.1 to 2.3.x

<Jan> Intent 2.5.1 (moving to 2.3.X): The user of a keyboard interface needs to be able to discover and be reminded of keystrokes. Some of these users may be using assistive technologies enabling communication of the keystrokes by programmatic means, while other users will need visual indicators, such as underlines.

2.11.8

<Jan> 2.11.8 Semantic Navigation of Time-Based Media: The user can navigate by semantic structure within the time-based media, such as by chapters or scenes present in the media (Level AA)

<Jan> Intent 2.11.8: To allow users to navigate time-based media in ways that are more meaningful than arbitrary time increments.

<Jan> BUT is this a sub-class of (2.3.1 Direct Navigation to Important Elements)

<Jan> Intent 2.11.8: Users need to be able to navigate time-based media in ways that are more meaningful than arbitrary time increments.

<jallan> users with disabilities need to efficiently navigate through chunks (chapters, scenes) of media

2.11.9

<Jan> 2.11.9 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. These selections may override global default settings for captions, audio descriptions, etc. (Level AA)

<Jan> Intent 2.11.9: To give users the ability to choose the tracks to meet their accessibility needs when authors have provided many alternatives.

<Jan> NOTE similarity to 1.1.2 Browse and Render

<jallan> Some users with disabilities need to choose different languages or audio tracks (descriptive video)

<Jan> Intent 2.11.9: Users need the ability to choose the tracks that best meet their accessibility needs (e.g. the caption track in their own language) when authors have provided many alternatives.

<mhakkinen> 2.7.1 Change Preference Settings

<mhakkinen> The user can change settings that impact accessibility. (Level A)

<mhakkinen> Users have a variety of needs when it comes to customization of a user agent. This success criteria ensures that a user can customize settings offered by the user agent to meet those needs.

<jallan> the document has many SC that say specify, configure, etc. this allows the changing.

<mhakkinen> 2.7.2 Persistence of Settings Affecting Accessibility

<mhakkinen> User agent accessibility preference settings persist between sessions. (Level A)

<mhakkinen> When a user has customized settings within the user agent to maximize accessibility, this success criteria ensures that customization is saved between browsing sessions. The user can then have those settings automatically used in subsequent browsing sessions.

<jallan> @@remove 2.7.1

<jallan> Resolution: Remove 2.7.1

2.7.2 persistence of a11y settings

<jallan> 2.7.2 Persistence of Settings Affecting Accessibility-- User agent accessibility preference settings persist between sessions. (Level A) Intent: When a user has customized settings within the user agent to maximize accessibility, this success criteria ensures that customization is saved between browsing sessions. The user can then have those settings automatically used in subsequent browsing sessions.

<jallan> discussion of whether this applies to multiple users

<jallan> the intent is a per user basis.

<mhakkinen> 2.7.3 Restore all to default: The user can restore all preference settings to default values. (Level A)

2.7.3

<mhakkinen> Users who customize settings may find that their chosen settings are not suitable and decide to restore these settings to their default values. For some users, it may be difficult to easily recall all modified settings while others may find it difficult to navigate to each modified setting, especially if a particular setting may have impacted their ability to do so. This success criteria provides a means for a user to easily restore all preference setting

<mhakkinen> This success criteria provides a means for a user to easily restore all preference settings to their default values using a single function or action.

<mhakkinen> For some users, it may be difficult to easily recall all modified settings while others may find it difficult to navigate to each modified setting, especially if a particular setting may have impacted their ability to do so. Users who customize settings may find that their chosen settings are not suitable and decide to restore these settings to their default values. This success criteria provides a means for a user to easily restore all preference settin

<mhakkinen> revised intent:

<mhakkinen> tion or action.

2.7.4

2.7.4 Multiple Sets of Preference Settings: The user can save and retrieve multiple sets of user agent preference settings. (Level AA)

2.7.5 Restore related preferences to default: The user can restore groups of related preference settings to default values (e.g. reset keyboard shortcuts, reset colors and sizes of rendered content). (Level AA)

2.7.5

<Jan> scribe: Jan

John: In mobile space this isn't really possible...

KF: We should remove

JS: Agreed

John: Recommend remove

GL: is this the only one that talks about groups of settings...
... e.g. the ability to send someone an appearance scheme

John: I agree re: modifying but not resetting

GL: Useful on windows - appearance scheme
... Not as useful if it was ALL settings

KP: e.g. in GMail addon to change keyboard shortcuts

<greg> This is not directly about 2.7, but it is beneficial for programs to allow users to save, distribute, and load groups of related settings without having it carry ALL settings with it.

Resolution: Remove 2.7.5

<JohnS> 2.7.6 Change preference setting outside the UI: The user can adjust preference settings from outside the user agent user interface. (Level AA)

2.7.6

<jallan> scribe: jallan

john: on mobile platforms there is no way to do this

<JohnS> Intent: When the user inadvertently selects a setting that renders the UI inaccessible, a method must be provided to allow the user to reset the UI.

<JohnS> Examples: 1. On a desktop device, there is a command line interface to reset the accessibility parameters. 2. On a mobile a hard button could be used to reset the accessibility parameters on user command.

greg: concerned about using only 'reset', prefers adjust

use 'user preferences' instead of a11y parameters

<JohnS> The user should have the ability to set user preferences to enable accessibility features of a UA prior to launching the UA.

jan: the control settings for the UA chrome
... if chrome slaved to the settings of the os. the user could change the OS to affect the UA UI so the user has ....

<JohnS> he user should have the ability to set user preferences to enable the controls of the accessibility features of a UA.

<scribe> ^^ new intent

<JohnS> 2.7.7 Portable Preference settings: The user can transfer preference settings onto a compatible system. (Level AAA)

<jeanne> ACTION: Jeanne to smith the IER for 2.7.6 [recorded in http://www.w3.org/2011/11/03-ua-minutes.html#action06]

<trackbot> Created ACTION-640 - Smith the IER for 2.7.6 [on Jeanne F Spellman - due 2011-11-10].

2.7.7

<JohnS> Intent: A user can migrate preference setting from one device to another in order to maintain accessibility parameters.

A user who has spent time customizing accessibility preferences to meet their needs, they can easily migrate preference setting to another device in order to maintain accessibility of other user agents

<JohnS> Intent: User will spend time customizing a UA to maximize accessibility, the user should be able to migrate the customization to maintain accessibility when using a compatible system. This will also allow rehabilitation professional of setting the required setting once.

jan: Portable Preference settings: The user can transfer preference settings onto a compatible user agent.

<Jan> jan: Portable Preference settings: The user can transfer preference settings between instances of the user agent

kelly: if you have portable preference settings you must include accessibility preference settings.
... wants to remove this. it is only about a11y settings

kim and greg have use registry files to help users with accessibility

kelly says this will not fly

jeanne: this is AAA, it is planting a seed.

mark: chome has this feature, synchronization

<jeanne> I think that if this is a step toward GPII, it is a good thing to include it at AAA

proposed rewording: Portable Preference settings: The user can transfer preference settings between instances of the user agent

this is roaming preferences

Intent: User will spend time customizing a UA to maximize accessibility, the user should be able to migrate the customization to maintain accessibility when using a compatible system. This will also allow rehabilitation professional of setting the required setting once.

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

03 Nov 2011

Attendees

Contents

Discussion of A, AA, and AAA

Walk through the document

2.5.1

2.11.8

2.11.9

2.7.2 persistence of a11y settings

2.7.3

2.7.4

2.7.5

2.7.6

2.7.7

Summary of Action Items

Scribe.perl diagnostic output