minutes: User Agent Telecon 30 Jan 2014

from http://www.w3.org/2014/01/30-ua-minutes.html

30 Jan 2014

See also: IRC log  http://www.w3.org/2014/01/30-ua-irc
<http://www.w3.org/2014/01/30-ua-irc>
Attendees
Presentkford, Jeanne, Jim_Allan, Greg_Lowney, Jan, EricRegretsChairJimAllan,
KellyFordScribeallanj
Contents

   - Topics <http://www.w3.org/2014/01/30-ua-minutes.html#agenda>
      1. review comments -<http://www.w3.org/2014/01/30-ua-minutes.html#item01>
      2. SB02: 1.8.7 <http://www.w3.org/2014/01/30-ua-minutes.html#item02>
      3. SB03 - 1.8.11 <http://www.w3.org/2014/01/30-ua-minutes.html#item03>
      4. SB04 - 2.6 <http://www.w3.org/2014/01/30-ua-minutes.html#item04>
   - Summary of Action
Items<http://www.w3.org/2014/01/30-ua-minutes.html#ActionSummary>

------------------------------

rrsaent, set logs public
review comments -

<jeanne> http://www.w3.org/WAI/UA/2014/LCcomments.html

http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0019.html

<jeanne> http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0015.html

<scribe> scribe: allanj

<jeanne> Minutes discussing Silas
comments<http://www.w3.org/2014/01/23-ua-minutes.html#item03>
SB02: 1.8.7

gl: jan was talking about changing to reflowable text rather than
reflowable content

ja: the comment is concerned with top-level-viewport (TLVP)

<Greg> Current wording: 1.8.7 Reflow Text: The user can specify that text
content in a graphical top-level viewport reflows so the text forms a
single column that fits within the width of the viewport. (Level A)

ja: if we remove TLPV does that solve the problem, or make more problem

gl: previous suggestion, clarify in the applicability notes. "When we refer
to TLVP we mean all of the elements within the viewport"

<Greg> In the top-level applicability notes we could have something like
"WHen this document refers to things 'in' an element, structure, or
viewport, it includes elements within the entire descendant structure (e.g.
'text inside a table' also includes text within a span within the table)." ?

js: problem with this. know example is the table. but could destroy the
readability if the page is a spreadsheet (data table), and all relations
are destroyed.
... seems we could make things worse.

kf: did we mean for this to include tables

jr: we don't mean we want redrawing a table, just squishing it. this is
what happens now
... this works for text, but images present limit on squishability
... we are not saying reflow a table, only reflow the text in a table.
... in content with absolute values we want a mode where use can override

js: this came from EO to change magazine layouts (multicolumn) to single
column.
... pdf does not do this.

jr: assign an action

js: invite silas for more info?
SB03 - 1.8.11

<Jan> *ACTION:* Jan to Develop response to Silas comment on 1.8.7(reflow
text) http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0015.html[recorded
in
http://www.w3.org/2014/01/30-ua-minutes.html#action01]

<trackbot> Created ACTION-938 - Develop response to silas comment on
1.8.7(reflow text)
http://lists.w3.org/archives/public/w3c-wai-ua/2014janmar/0015.html [on Jan
Richards - due 2014-02-06].

<Greg> SB03: Re 1.8.11 (Allow Top-Level Viewport Open on Request) it might
also be worth explicitly stating that, if the user performs some action
whose normal meaning is "open link in new tab" (for example, middle-click
on some browsers) then it should be possible for users to specify that such
actions must ALWAYS perform that meaning, and cannot be overridden by the
page author. Some Javascript...

<Greg> ..."onClick" events manage to (accidentally) override middle-clicks
and cause something to happen on the current page instead of opening a new
tab. (In many cases this can be worked around by right-clicking on the link
and selecting "open in new tab", instead of middle-clicking, but that can
be extra effort and it's an annoyance.)

ja: thought middle click controlled by mouse not the browser.
... this sounds like a new SC. Persistance of behavior setting, for each
website or across all websites.

<Greg> GCL: I agree with the sentiment but unfortunately as you say those
non-standard behaviors are usually implemented in Javascript, so the user
agent may not be able to interfere in any reliable way other than by
blocking scripts altogether. (It could fail a script's calls to the
function that opens a new top-level viewport, but it can't force the script
to make such a call.)

<Greg> GCL: For the working group, what would we expect the user agent to
do if the user has said content can't open new top-level viewports, then
the user clicks a control that is explicitly to do so? Should the script's
call to open a new tab simply fail? Should the user agent warn the user, so
as to explain why their click isn't working? I don't think it should, for
example, simply take the link...

<Greg> ...in the current viewport, as that could break some scripts.

<Greg> Current wording: 1.8.11 Allow Top-Level Viewport Open on Request:
The user can specify whether author content can open new top-level
viewports (e.g. windows or tabs). (Level AA)

gl: when action opens a new viewport, don't want a script to open a new tab

js: saying if user sets a mapping for some action, then don't let the
author override the mapping
... this seems to be related to 2.3.5

gl: or 2.8.1

ja: middle click - open link in new tab works in IE, FF, Chrome

js: what is the generalization not just for middle click.

gl: explains his comment

<Greg> A) we could use my proposed response above, or b) we could add an SC
saying that the user agent should not allow scripts to override default
inputs which are associated with a specific list of actions, such as
opening a link in a new tab. However, I don't favor the latter.

gregs response: I agree with the sentiment but unfortunately as you say
those non-standard behaviors are usually implemented in Javascript, so the
user agent may not be able to interfere in any reliable way other than by
blocking scripts altogether. (It could fail a script's calls to the
function that opens a new top-level viewport, but it can't force the script
to make such a call.)

jr: there are special cases where sites could not over-ride specific
actions (ALT-D address bar)

gl: could come up with a list...

<Greg> It seems a daunting task to create a list of commands that scripts
should not be allowed to override, and the list would ideally change over
time and between products.

ja: seems prescriptive

<Greg> 2.3.5 was the SC that refers to "conventional bindings for the
operating environment (e.g. arrow keys for navigating within menus)".

jr: order of keypress - OS, browser, javascript, etc
... 2.3.5 and others give conflicting advice.

kf: the lowest common denominator wins. the OS could say, I will take all
input.
... the goal is for applications to play well together

jr: browser could reveal UI of a page
... could we extend 2.3.5 to include mouse and gestures?

kf: why if I am a UA developer, should I have to do this. The OS should
handle it.

jr: if someone does a keyboard remapping at the OS level. then user doesn't
need to do it in the UA

kf: we may have over reached.
... if I hit alt I and want it to be alt J, you can only remap commands
within the user interface.
... but 2.3.5 says any key combination can be remapped.

<Jan> Keytweak remapper for Windows:
http://core.ecu.edu/psyc/wuenschk/Help/KeyTweak.htm

kf: do we expect UA to allow its UI to be remapped to what ever keys
necessary.

***regroup***

gregs response: I agree with the sentiment but unfortunately as you say
those non-standard behaviors are usually implemented in Javascript, so the
user agent may not be able to interfere in any reliable way other than by
blocking scripts altogether. (It could fail a script's calls to the
function that opens a new top-level viewport, but it can't force the script
to make such a call.)

Resolution: Reject comment, per gregs response: I agree with the sentiment
but unfortunately as you say those non-standard behaviors are usually
implemented in Javascript, so the user agent may not be able to interfere
in any reliable way other than by blocking scripts altogether. (It could
fail a script's calls to the function that opens a new top-level viewport,
but it can't force the...
... script to make such a call.)

<Jan> FYI: And keyboard remapping on Android
http://www.howtogeek.com/175267/the-htg-guide-to-using-a-bluetooth-keyboard-with-your-android-device/
SB04 - 2.6

<Greg> SB04: Re 2.6 - I think there definitely needs to be some
easily-accessible switch to temporarily STOP all event handlers, then start
them again later. Some websites have badly-implemented scripts that try to
do fancy things as you move the mouse over elements, and these play badly
with user stylesheets. For example, eBay's feedback mechanism can go
horribly wrong at very large zoom levels....

<Greg> ... You move the mouse over the "5 star" rating, but as you do so,
it adds an extra element into the text, causing the whole thing to reflow
(the designers weren't expecting it to reflow - they didn't think it might
be zoomed), and the reflow takes the star somewhere else so it is no longer
under the mouse pointer, and this causes another event, undoing the first
event, but then the star is...

<Greg> ...again under the pointer, and so on ... result is a
rapidly-flickering control, and less than 50/50 chance of it being
activated when you click. Only workaround is to zoom out or increase the
window size, but I wish I had a button that says "stop all event handlers
until my next click" (bonus points if the user agent can AUTOMATICALLY
detect the "rapid-fire" situation and turn them off...

<Greg> ...until the next click).

greg comment: SC 2.11.3 already requires the user be able to turn off
scripts, but it does not require that it be easy or convenient (nor that it
be specific to a the current top-level viewport). That could potentially be
added as a separate, lower-level SC, but I'm not sure how we'd say what is
required to be convenient. By the way, your example is a good one that we
could add to the...

scribe: Implementing document.

ja: this is not just a problem with scripts, but also CSS. Example of bold
link on hover, bold takes more space causing text to shift, moving link
from mouse, so link becomes unbold, but then is under mouse and becomes
bold...repeat...nice flicker

gl: 1.7.3 allow tuning off author css

<Greg> Problems caused by behaviors in author-provided stylesheets (e.g.
links getting larger when hovered over) can be disabled by 1.7.3 Disable
Author Stylesheets.

<Greg> This requires point of regard to be maintained when the user turns
styles on or off: 1.8.6 Maintain Point of Regard: The point of regard
remains visible and at the same location within the viewport when the
viewport is resized, when content is zoomed or scaled, or when content
formatting is changed. (Level A)

ja: are 3 comments on 2.6.1

chrome says it can't be done.

gregs response

GCL: In this case the success criteria is actually limited to "recognized
input methods explicitly associated with an element", so the user agent is
not expected to present the user with a list that includes every possible
event being handled by a global event listener, if the specific technology
does not allow it to tell which specific events are being watched for.
However, if the user...
... agent can tell, for a given element, which events are being listened
for by a element-specific, container element, or global listeners, it
should be able to make this list available to the user. If you still feel
this is a problem could you please

elaborate

gl: the script has to register with the browser what it wants to listen to.
it could be a generic listener, or specific.

<Jan> +1 to GCL's response on CR06

Resolution: CR06. ask for more input. per greg's response: GCL: In this
case the success criteria is actually limited to "recognized input methods
explicitly associated with an element", so the user agent is not expected
to present the user with a list that includes every possible event being
handled by a global event listener, if the specific technology does not
allow it to tell which...
... specific events are being watched for. However, if the user agent can
tell, for a given element, which events are being listened for by a
element-specific, container element, or global listeners, it should be able
to make this list available to the user. If you still feel this is a
problem could you please elaborate.

jr: SB04 this is covered by 2.11.3. as per GCL: SC 2.11.3 already requires
the user be able to turn off scripts, but it does not require that it be
easy or convenient (nor that it be specific to a the current top-level
viewport). That could potentially be added as a separate, lower-level SC,
but I'm not sure how we'd say what is required to be convenient. By the
way, your example is a good...
... one that we could add to the Implementing document.

Resolution: SB04 not accepted, per GCL: SC 2.11.3 already requires the user
be able to turn off scripts, but it does not require that it be easy or
convenient (nor that it be specific to a the current top-level viewport).
That could potentially be added as a separate, lower-level SC, but I'm not
sure how we'd say what is required to be convenient. By the way, your
example is a good one that...
... we could add to the Implementing document.

s/reject/not accepted
 Summary of Action Items *[NEW]* *ACTION:* Jan to Develop response to Silas
comment on 1.8.7(reflow text)
http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0015.html[recorded in
http://www.w3.org/2014/01/30-ua-minutes.html#action01]

[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

Received on Thursday, 30 January 2014 19:49:31 UTC