See also: IRC log
<trackbot> Date: 08 August 2013
<scribe> scribe: allanj
js: f2f is confirmed. send jeanne
your preferred flights
... I will book flights
1.5.1 Global Volume: The user can independently adjust the volume of all audio tracks, relative to the global volume level set through operating environment mechanisms. (Level A)
gl: there were platform issues.
on IOS there is no distinction between audio tracks (it is a
convention).
... on other platforms, Windows (where it is not a convention)
should it be a requirement or not.
js: platform issues/conventions
should be covered by conformance statement.
... this is tricky to do, could be happy with AA
kim, greg, jim +1
<jeanne> Resolved: 1.5.1 is changed to AA.
<jeanne> gl: Add example of iOS in IER
<jeanne> ... or as a note
js: put in IER, so not normative.
<jeanne> GL: If a platform convention does not support multiple audio tracks
<jeanne> ... multiple audio tracks is not what I was proposing. I was looking at my earlier proposal
<Greg> In http://lists.w3.org/Archives/Public/w3c-wai-ua/2013JulSep/0015.html I said "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.""
<Greg> I also said:
<Greg> <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...
<Greg> ...control for 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.
<jeanne> JS: Audio Track Volume would be a better handle, I think
<Greg> But *that's* the one where it was pointed out that iOS has the convention of not using separate per-app volume settings.
<jeanne> +1 to changing the handle to Audio Track Volume
+1 changing the handle
<jeanne> GL: We lost the SC on the Global Volume setting.
note Action 850 on kelly to write a new SC is still open
<jeanne> GL: That was when it was pointed out that the problem with iOS is that they don't have a default volume, that there are 4 different volume settings which have to be addressed individually.
kelly will have 850 on Monday.
<Greg> http://lists.w3.org/Archives/Public/w3c-wai-ua/2013JulSep/0025.html
PROPOSAL 1:
1.1.4 Display of Alternative Content for Time-Based Media: For recognized on-screen alternative content for time-based media (e.g.
captions, sign language video), the following are all true: (Level AA)
(a) Text configurable: The user can configure recognized text within alternative content for time-based media (e.g. captions) in conformance with 1.4.1,
(b) Alternatives not obscured: Alternative content for time-based media is not obscured by the primary time-based media,
[ed. Maybe obvious, but added for completeness - transparency is not an option]
(c) Controls not obscured: Alternative content for time-based media do not obscure recognized controls for the primary time-based media, and
[ed. transparency is not an option]
(d) Primary media not fully obscured: Alternative content for time-based media do not fully obscure the primary time-based media.
[ed. This is where transparency is allowed...then 1.1.6 requires a non-overlapping option]
gl: 4 issues
<Greg> Re the new sentence“Primary media not fully obscured: Alternative content for time-based media do not fully obscure the primary time-based media”, the term “fully obscure” seems to be saying that it can block 1/2, or 2/3 of the primary time-based media, as long as it doesn’t block 100% of it. That doesn’t seem appropriate.
gl: item D written above
... he must mean overlayed by something opaque
... can only tell because of the note.
... needs to say it more explicitly.
... as written it would be ok to cover 99% or less of the
screen.
<Greg> I think he means by (d) that "alternative content for time-based media does not overlap the primary time-based media if rendered with opaque backgrounds"
js: but folks with low vision need opaque background.
gl: "the use can have all of the following be true" their choice.
definition in document...Obscure: To render a visual element in the same screen space as a second visual element in a way that prevents the second visual element from being visually perceived. Note: While the use of transparent backgrounds for the overlaying visual element (e.g., video captions) is an acceptable technique for reducing obscuration, if space is available it is more effective...
scribe: not to overlap visual elements that are both of interest to the user.
kp: confused. wording issues.
gl: push back to jr and mention problems with D.
table this until Jan returns
gl: what is the convention for
the rest of the document?
... today we are inconsistent. some with handles, some with
out
1.7.2 bullets has no bolded text
1.4.1 bullets all bold except parenthetical
<Greg> 1.7.2 bullets have no bolded text; 1.4.1 bullets have all the text bolded except parentheticals; 1.1.4 bullets have bolded titles ending in colons.
Resolved: fixing bullet handles and capitalization issues is for the editors.
zagnea?
zakim: open item 3
<Greg> Greg comment - http://lists.w3.org/Archives/Public/w3c-wai-ua/2013JulSep/0014.html
<Greg> Kim Proposal - http://lists.w3.org/Archives/Public/w3c-wai-ua/2011OctDec/0108.html
related to comment 27
kp: explains reason for section.
gl: concern about title. moved to a different section?
kp: was principle, then control. what are the choices.
current wording:
Modality Independent Controls
Users interacting with a web browser may do so using one or more input methods including keyboard, mouse, speech, touch, and gesture. It's critical that each user be free to use whatever input method or combination of methods works best for a given situation. Therefore every potential user task must be accessible via modality independent controls that any input technology can access.
For instance, if a user can't use or doesn't have access to a mouse, but can use and access a keyboard, the keyboard can call a modality independent control to activate an OnMouseOver event. See Independent User Interface: Events for additional information on APIs and techniques for modality independent controls.
<Greg> Some people felt the "Overview" or "Summary" should not have content that isn't summarizing something later in the document.
js: perhaps make it a note at beginning of Principle 2
<Greg> (Personally I'm neutral on that.)
kp: add a sentence, 'when we say keyboard accessible, we mean modality independent"
<kford> this would work for me.
<Greg> Kim and Jim feel this note should be in the main doc, not just in the Implementing doc.
Resolved: move Modality Independent Controls to Guideline 2, make it a Note. add a sentence explaining it a bit more. fix "must"
discussing RFC2119
perhaps have a statement at the top that we are NOT using RFC2119. Editors choice.
<KimPatch> ACTION: Jeanne to move Modality Independent Controls to immediatly after Principal 2, make it a Note. add a sentence explaining it a bit more. fix "must" [recorded in http://www.w3.org/2013/08/08-ua-minutes.html#action01]
<trackbot> Created ACTION-860 - Move Modality Independent Controls to immediatly after Principal 2, make it a Note. add a sentence explaining it a bit more. fix "must" [on Jeanne F Spellman - due 2013-08-15].
<scribe> ACTION: Jeanne to add a note to the document about NOT following RFC 2119 [recorded in http://www.w3.org/2013/08/08-ua-minutes.html#action02]
<trackbot> Created ACTION-861 - Add a note to the document about NOT following RFC 2119 [on Jeanne F Spellman - due 2013-08-15].
zakim close this item
https://www.w3.org/2002/09/wbs/36791/20130702/results#xq7
<Greg> Jim suggests keeping the old wording with AA.
gl: prefers old wording
<Greg> I agree that I prefer the original wording, but are there implementations that comply?
<Greg> Jim thinks there's an extension for Firefox that makes all iframes resizable; it cannot be done using style sheets.
kf: did a search, there seems to be extensions, techniques for doing this.
gl: ok with original wording change to AA
ja: any objections to original wording for 1.8.3 and change to AA
none heard.
<scribe> ACTION: jeanne to update document 1.8.3 is now AA [recorded in http://www.w3.org/2013/08/08-ua-minutes.html#action03]
<trackbot> Created ACTION-862 - Update document 1.8.3 is now AA [on Jeanne F Spellman - due 2013-08-15].
https://www.w3.org/2002/09/wbs/36791/20130702/results#xq8
ja: any objections to using "top level viewports"
none heard.
gl: editing on plurals
<Greg> I said: However, there is a problem with the "Zoom out" portion. It consists of two clauses that could conflict, and it's not clear how such conflicts would be resolved. For example, what if reducing to 10% is not enough to let the content fit within the height or width of the viewport,then what? Is it saying that zoom has to go to 10% or the amount necessary to make the content fit,...
<Greg> ...whichever size is smaller? Perhaps rephrase as "Zoom out: to 10% or less of the default size, or enough to let the content fit within the height or width of its viewport, whichever size is smaller."
<Greg> We cannot split an SC into two priority levels; I assume his trailing AA is a copy/paste error.
<Greg> Jim: WCAG only requires 200%.
<Greg> Greg: does any UA that has zoom not go to 500%?
Resolved: New wording for 1.8.6
Resolved: 1.8.6: Zoom: The user can rescale content within top level graphical viewports as follows: (Level A)
Zoom in: to 500% or more of the default size; and
Zoom out: to 10% or less of the default size, or enough to let the content fit within the height or width of its viewport, whichever size is smaller."
<scribe> pending response from Jan about A or AA
https://www.w3.org/2002/09/wbs/36791/20130702/results#xq9
discussion
<Greg> Does anyone not agree with my objection to the rewrite? "What does "when it can be reflowed" mean? It would be extremely inconvenient if such reflowing could not be made automatic (e.g. if the user had to perform an explicit action on each element they want to reflow, or on each page after it is rendered). Other wording might be more acceptable."
kp: like the original wording.
smithing attempts
<Greg> "The user can have content automatically reflow when its graphical viewport is resized, so that that one dimension of the content fits within the height or width of the viewport."
<Greg> "The user can have content automatically reflow when the scaling of its graphical viewport is changed, so that that one dimension of the content fits within the height or width of the viewport."
<Greg> "The user can have content automatically reflow when the scaling of its graphical viewport is changed, so that one dimension of the content fits within the height or width of the viewport."
ja: authoring practice of responsive web design, would be nice if UAs would repair
kf: UA could do it, will they????
if UAs say we won't do this, then we remove it
... we other SCs like this.
<KimPatch> The user can specify that when reflowable content in a graphical viewport rescales, it reflows so that one dimension of the content fits within the height or width of the viewport.
discussion of 'can have' vs 'specify'
<Greg> Some SC say "can have", some "can specify", etc. To my mind the "can have" is generally better because "can specify" *could* be interpreted as requiring the user have a choice (that is, they have to be able to turn it off), whereas "can have" more correctly implies that it can be optional or always on, but just can't be always off.
gl: wants some statement for the entire document - conventions used in document - user can specify means foo, user can choose means foo.
<scribe> ACTION: jeanne to modify 1.8.12 to be The user can specify that when reflowable content in a graphical viewport rescales, it reflows so that one dimension of the content fits within the height or width of the viewport. [recorded in http://www.w3.org/2013/08/08-ua-minutes.html#action04]
<trackbot> Created ACTION-863 - Modify 1.8.12 to be The user can specify that when reflowable content in a graphical viewport rescales, it reflows so that one dimension of the content fits within the height or width of the viewport. [on Jeanne F Spellman - due 2013-08-15].
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/seetting/setting/ Succeeded: s/Guidleine/Guideline/ Found Scribe: allanj Inferring ScribeNick: allanj Default Present: Jeanne, Jim_Allan, Kim_Patch, Greg_Lowney, kford Present: Jeanne Jim_Allan Kim_Patch Greg_Lowney kford Regrets: Jan Eric WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 08 Aug 2013 Guessing minutes URL: http://www.w3.org/2013/08/08-ua-minutes.html People with action items: jeanne[End of scribe.perl diagnostic output]