Minutes for UAWG telecon 18 July 2013

http://www.w3.org/2013/07/18-ua-minutes.html

Full text:
User Agent Accessibility Guidelines Working Group Teleconference
18 Jul 2013

See also: IRC log
Attendees

Present
Regrets
    Jim, Kim
Chair
    SV_MEETING_CHAIR
Scribe
    Jan

Contents

    Topics
        Jan proposal for minor UAAG2 comments
        Survey from 4 July https://www.w3.org/2002/09/wbs/36791/20130702/
        Jan proposal for removing summaries http://lists.w3.org/Archives/Public/w3c-wai-ua/2013JulSep/0000.html
        Survey from 4 July https://www.w3.org/2002/09/wbs/36791/20130702/
    Summary of Action Items

<trackbot> Date: 18 July 2013

<scribe> scribe: Jan
Jan proposal for minor UAAG2 comments

<kford> JAN: We did some of this from our last call.

http://lists.w3.org/Archives/Public/w3c-wai-ua/2013JulSep/0002.html

last minutes: http://lists.w3.org/Archives/Public/w3c-wai-ua/2013JulSep/0005.html

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

<jeanne> July 1

JR: The wording under "Modality Independent Controls" seems oddly normative for introduction
... Aren't we covered by the 3 SCs in Guideline 2.12 - Other Input Devices

<Greg> (We should be using Implementing at http://www.w3.org/WAI/UA/2013/ED-UAAG20-20130701.)

GL: It was Kim's idea...

JR: So maybe we should wait

<Greg> It doesn't really fit where it ended up.

JR: Agreed

GL: Did it come up in email?
... I will send an email to Kim + UA list

<Greg> Done.
Survey from 4 July https://www.w3.org/2002/09/wbs/36791/20130702/
Jan proposal for removing summaries http://lists.w3.org/Archives/Public/w3c-wai-ua/2013JulSep/0000.html

<Greg> Here's the original description of the intent for the summaries that Kim and I came up with: http://lists.w3.org/Archives/Public/w3c-wai-ua/2010OctDec/0007.html

http://www.w3.org/WAI/UA/UAAG20/#summary18

JS: We hadn't got there (summaries)...we could raise priorities..
... We could look at it again then

KF: Let's just see what they look like when they are finished editing
... Even if we change later to Rationale the wording isn't lost

JS: Hopefully a good editorial pass will fix them up

<Greg> Our goals were:

<Greg> * make them *easy to read*,

<Greg> * make them as *self-explanatory* as possible, and

<Greg> * *convey the general idea of each success criterion* while leaving the legalistic details for elsewhere (e.g. the normative wording of the success criteria, applicability notes, intent paragraphs, and examples),

<Greg> * *clarify the relationships between the success criteria *for a guideline that are often difficult to figure out in the full, legalistic versions.

<Greg> To achieve those goals we tried to:

<Greg> * *address the developer directly* and *use the imperative* (e.g. "Provide..." and "Let..." rather than "...is provided" and "...can..."),

<Greg> * *avoid jargon* (e.g. "W3C's Web Content Accessibility Guidelines" rather than "WCAG", "menus, buttons, dialogs, etc." rather than "user agent user interface elements"),

<Greg> * *choose words and phrases that suggest everyday speech* rather than technical documents (e.g. "make sure" instead of "ensure"),

<Greg> * *include inline examples and explanations* rather than just restating the requirements,

<Greg> * *avoid going into too much detail* (e.g. don't try to list all the conditions and exceptions, don't call out priorities except to contrast items), and

<Greg> * *break out the upshot for each success criterion* (e.g. following each sub-item summary with its corresponding SC number in parentheses).
Survey from 4 July https://www.w3.org/2002/09/wbs/36791/20130702/

<kford> Resolved: Revisit issue of changing summaries to rational after editorial work is completed.

https://www.w3.org/2002/09/wbs/36791/20130702/results

JR: Q1...no one answered

Q2: JR and GL sent more email to the list. Prob too complicated for our small group today.

Q3: JR51 on 1.5.1 https://www.w3.org/2002/09/wbs/36791/20130702/results#xq5

<Greg> I think it's fine to reduce the priority of the current 1.5.1, but the title should be changed to something more appropriate such as "Volume of individual tracks" or "Track volume."

GL: OK with making 1.5.1 AA

<Greg> Because we'd no longer have any Level A SC about adjusting volume, I also suggest renaming it to 1.5.2 and inserting a new SC, "1.5.1 Volume Control: The user can adjust the volume of all audio played, relative to the global volume level set through *operating environment* mechanisms. (Level A)" I think it's quite reasonable for any media player to provide at minimum one volume control for...

<Greg> ...the media it's playing, and so widely implemented as to be expected by users, and entirely necessary for users who need to adjust their media volume without affecting the volume of their synthesized speech, etc.

GL: Proposes new "1.5.1 Volume Control: The user can adjust the volume of all audio played, relative to the global volume level set through *operating environment* mechanisms. (Level A)"
... To go ahead of what's there.

<Greg> This is not really adding a new SC, but restoring an old one that was lost.

<Greg> JR: Netflix app on Android just uses the global media volume setting, so it would fail this proposed SC.

GL: GL: On iOS global volume is same as media playing

<Greg> KF: Narrator on Windows 8 and VoiceOver on Apple platforms implement "audio ducking", where the global volume is reduced while speech is being generated.

KF: On VoiceOver and Narrator, there is audio-ducking...global audio is reduced when screen reader is active

GL: Other cases of conflict...someone playing audio with very low level...

<Greg> Audio ducking might help with conflict between speech and other audio, but if a person needs to increase the volume of one very quiet video a lot, they don't want speech of notifications to blow their ears out.

JR: So then how would it apply in Android..."Media Vlume" example?

GL: OK but app should still have its own volume

<Greg> Thus I'd lean towards requiring each app have its own volume control, for when people need to *increase* volume, or use speech other than the system default utility (that implements audio ducking).

<jeanne> JR: In the a

<jeanne> JR: In the Android case, there are four different volumes: media volume, notification volume

<jeanne> ...ringtone, and system. And call volume

<jeanne> ... there is no universal global volume in the first place.

<jeanne> ... probably the media volume could be considered the Global volume, and then the Netflix app just uses the Android media volume.

<jeanne> GL: If I use the volume up button, will that boost everything, or are the other volumes a percentage of the Media volume.

<jeanne> KF: The way devices are evolving, wouldn't we be better saying that we require it at AA, and not A. In particular on the mobile platforms (and this is still evolving) all applications are trying to reconsile all the different demands for audio. Especially a phone call.

GL: If on windows someone using JAWS...no audio-ducking...if Netflix just used default volume we are back to the problem.

KF: In win7, any app that is playing audio, Win allows you to mod the volume of that sound.
... In Win8, older apps still have that, but modern applications have just one level

GL: I went to the volume mixer in Win7....
... let's me mix volume for each app...
... So on Win7, everything would meet

<Greg> But if a UA didn't let the user adjust its volume on WinXP, where the system doesn't provide per-app volume control, I'd consider that UA remiss.

<scribe> ACTION: KF to To write a proposal for a new SC in 1.5 to cover the issue of audio volume intereference with AT and potentially other audio sources [recorded in http://www.w3.org/2013/07/18-ua-minutes.html#action01]

<trackbot> Created ACTION-850 - Write a proposal for a new SC in 1.5 to cover the issue of audio volume intereference with AT and potentially other audio sources [on Kelly Ford - due 2013-07-25].

<Greg> For me the goals are two: preventing conflict between UA sound and assistive technology sound, and also accommodating users who need to avoid very loud or very soft sounds and thus need to adjust volume for one app or media.

Question 4 JR9 on 1.8.1

https://www.w3.org/2002/09/wbs/36791/20130702/results#xq6

<Greg> Per Jim's comment that there were no implementations, Firefox lets the user adjust focus rectangle thickness, but unfortunately it doesn't work very well at all (leaving visual artifacts as the focus moves).

Resolution: Split 1.8.1 Highlight Viewport into 1.8.1 Highlight Viewport, 1.8.x Customize Viewport Highlighting

<Greg> Why do we have this (or these) SC instead of just including these in 1.3.1 (Highlighted Items) and 1.3.2 (Highlighting Options)?

<Greg> In fact, 1.3.1.b does list focus cursors.

KF: Are you ok with wording if duplicate?

<Greg> I'd change1.8.1 to say "The user can have the viewport with the input focus be highlighted" or equivalent, so that mobile/touch-based UI's don't have to indicate focus rectangle when not in a mode where focus is relevant.

JR: OK

<Greg> That is, if the user wants or needs focus indicators, they should be able to have them, but if they don't need them it's okay for them to be hidden (e.g. by default on touchscreen devices).

<Greg> 1.3.1 is already written correctly in this regard.

KF: Can we approve wording and then look at if 1.3.1 and 1.8.1 are duplicates?

1.8.1 Highlight Viewport: The user can have the viewport with the input focus be highlighted.

1.8.1 Highlight Viewport: The user can have the viewport with the input focus be highlighted. (Level A)

Resolution: All agree with "1.8.1 Highlight Viewport: The user can have the viewport with the input focus be highlighted. (Level A)"

1.8.x Customize Viewport Highlighting: The user can customize attributes of the highlighting mechanism (e.g. shape, size, stroke width, color, blink rate). (Level AA)

<Greg> We could add to 1.3.2.d "Shape and size when the indicator is an image".

<Greg> ACTION: Greg to review 1.8.1,x to see if they can be merged into 1.3.1-2 to avoid duplication [recorded in http://www.w3.org/2013/07/18-ua-minutes.html#action02]

<trackbot> Created ACTION-851 - Review 1.8.1,x to see if they can be merged into 1.3.1-2 to avoid duplication [on Greg Lowney - due 2013-07-25].
Summary of Action Items
[NEW] ACTION: Greg to review 1.8.1,x to see if they can be merged into 1.3.1-2 to avoid duplication [recorded in http://www.w3.org/2013/07/18-ua-minutes.html#action02]
[NEW] ACTION: KF to To write a proposal for a new SC in 1.5 to cover the issue of audio volume intereference with AT and potentially other audio sources [recorded in http://www.w3.org/2013/07/18-ua-minutes.html#action01]

Received on Thursday, 18 July 2013 18:33:09 UTC