- From: Jim Allan <jimallan@tsbvi.edu>
- Date: Thu, 30 Jan 2014 13:49:04 -0600
- To: WAI-ua <w3c-wai-ua@w3.org>
- Message-ID: <CA+=z1WkJLt6n=80yd3W=VRRtbMOEhea2Vs7SD0vh8uVN5DiS0Q@mail.gmail.com>
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