See also: IRC log
<trackbot> Date: 18 July 2013
<scribe> scribe: Jan
<kford> JAN: We did some of this from our last call.
<jeanne> July 1
JR: The wording under "Modality
Independent Controls" seems oddly normative for
... 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.
GL: Did it come up in
... I will send an email to Kim + UA list
<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
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).
<kford> Resolved: Revisit issue of changing summaries to rational after editorial work is completed.
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
... In Win8, older apps still have that, but modern applications have just one level
GL: I went to the volume mixer in
... 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
<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.
<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].
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Resolution/GL/ Found Scribe: Jan Inferring ScribeNick: Jan WARNING: No "Present: ... " found! Possibly Present: GL Greg Greg_Lowney IPcaller JR JS Jan Jeanne KF Kelly P15 Q2 Q3 aaaa https inserted joined kford kford_ sharper trackbot ua You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Regrets: Jim Kim WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 18 Jul 2013 Guessing minutes URL: http://www.w3.org/2013/07/18-ua-minutes.html People with action items: greg kf WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]