Minutes: UAWG telecon 8 Aug 2013

from: http://www.w3.org/2013/08/08-ua-minutes.html

User Agent Accessibility Guidelines Working Group Teleconference

08 Aug 2013

See also: IRC log  http://www.w3.org/2013/08/08-ua-irc

Attendees

PresentJeanne, Jim_Allan, Kim_Patch, Greg_Lowney, kfordRegretsJan,
EricChairSV_MEETING_CHAIRScribeallanj

Contents

Topics

F2F update
JR51 - decide A or AA
UAAG2: Clarifying obscuration
add handles to 1.1.6
Survey from 4 July start on question 5 - JR10
quetion 5
JR11 on 1.8.6
JR13 on 1.8.12

Summary of Action Items

________________________________

Summary of Action Items

[NEW] 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]
[NEW] 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]
[NEW] 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]
[NEW] 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> Date: 08 August 2013

F2F update

<scribe> scribe: allanj

js: f2f is confirmed. send jeanne your preferred flights
... I will book flights

JR51 - decide A or AA

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.

UAAG2: Clarifying obscuration

<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

add handles to 1.1.6

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

Survey from 4 July start on question 5 - JR10

quetion 5

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].

JR11 on 1.8.6

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

JR13 on 1.8.12

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].


[End of minutes]

--
Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964