W3C

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

03 Jun 2010

See also: IRC log

Attendees

Present
+1.512.206.aaaa, AllanJ, kford, Jeanne, +1.425.895.aabb, Greg, sharper
Regrets
Patrick_Lauke, Mark_Hakkinen
Chair
Kelly_Ford
Scribe
kford

Contents


<trackbot> Date: 03 June 2010

/say zakim, agenda?zakim, microsoft is kford

Survey http://www.w3.org/2002/09/wbs/36791/20100521/

Close on issues discussed in mail thread at http://lists.w3.org/Archives/Public/w3c-wai-ua/2010AprJun/0095.html.

<scribe> Scribe: kford

JA: This is from webapps working group.

They were past last call when I sent some comments about view mode.

<AllanJ> http://www.w3.org/TR/2010/WD-view-mode-20100420/

JA: I mentioned UAAG 2.0 had SC to allow override for chrome inclusion/exclusion.
... Asked for a statement to ask for addressing this.
... Webapps thought this was more a CSS issue.
... Are we OK with these statements and can they go to CR?
... I'm OK with it and agree with their reasoning.

group talking about locating changed text because we do not see it in the document.

<jeanne> http://dev.w3.org/2006/waf/widgets-vmmf/

<jeanne> http://dev.w3.org/2006/waf/widgets-vmmf/CR.html

<Greg> I see the new wording as being problematic because the browser can be running in a mode that no longer falls into any of the five view mode categories. Specifically, if the browser is running fullscreen (in that it takes up the entire screen) but the user has selected an option to always display chrome, then the result will not match any of the five views.

Group still discussing because feels concerns haven't been addressed in most current document.

Webapps feels some of this is due to limitations of the platform.

<Greg> I think that if they specify that view-mode:fullscreen applies when there's no chrome, they should note that while this mode normally has no chrome, user settings may override this to display chrome.

Group talking about implications of kiosk modes for browsers.

SH: How are we addressing this in our guidelines?

<Greg> Alternatively, they could go back to the older wording, or modify it to explicitly say that fullscreen "may or may not have chrome".

<Greg> (They also might want to include an explanatory note to the effect that if a window takes up the entire screen area but has no chrome, it would be counted as view-mode:floating.)

SH: How are we addressing this in our guidelines?
... I think webapps still gives the user the choice and we just have to make sure the user has something to experience when the choice is made.

<AllanJ> ftom the webapps group "The idea here is that the UA would make a best effort at matching the intent in a way that makes sense rather than be ultra strict. For instance, if the app goes fullscreen but keeps a teeny bit of chrome (at user option or not) to make it easier to exit fullscreen, then matching the view-mode: fullscreen media query is quite clearly the right thing to do."

<Greg> I'm having trouble coming up with a scenario where this flaw hurts the user: if a page is displayed in fullscreen mode but with chrome (because of the user's preference setting), and the UA applies the fullscreen stylesheet that was authored with the assumption there would be no chrome, but there IS chrome, how does that hurt the user?

<Greg> Unless the problem is that when chrome is presented, it brings with it lots of keyboard shortcuts (e.g. Alt+F to display the file menu), and that may conflict with shortcut keys used by the page content.

<Greg> Therefore it could be that what the author really wants to do is choose a different style sheet based on whether or not there is chrome, and the current view-mode feature spec fails to address that.

<Greg> ...if the UA may or may not display chrome in fullscreen mode.

<Greg> Jeanne noted that the most common reason to hide the chrome is to disable the back button. Hiding chrome is bad, but disabling the back button is sometimes necessary. Therefore we should suggest to the appropriate working group that HTML have a way to disable the back feature, if they're not already planning it.

Group continues discussion.

SH brings up second paragraph in group's documens saying user is in control.

group good with webapps.

JA sending reply.

<AllanJ> scribe, allanj

Close on areas we want feed back on for next publication and items we've changed.

<AllanJ> JS: writing status section for new draft. what are the items we want feedback on. Last time we were specific, but got little feedback

<AllanJ> ... happy to stick with those

<jeanne> http://www.w3.org/TR/2010/WD-UAAG20-20100311/#status

<AllanJ> ... is there anything new we want to get feedback on

<AllanJ> KF: we've made lots of changes to techniques.

<AllanJ> JS: will note those.

<AllanJ> ... what do we want feedback on.

<AllanJ> ... keep the original list.

<AllanJ> JA: expand the audio/video stuff

<AllanJ> JS: possible publishing window next week

Survey http://www.w3.org/2002/09/wbs/36791/20100521/

Proposal for 3.10.5 Scrollbars http://www.w3.org/2002/09/wbs/36791/20100521/results#xq7

<AllanJ> GL: what are the features we need

<AllanJ> ... user can get to all the content

<AllanJ> ... user can tell where they are in the document

3.10.8 do not take focus http://www.w3.org/2002/09/wbs/36791/20100521/results#xq8

<AllanJ> gl: Does "user's request" mean in response to user input, even if the user may not realize that a new window will open? For example, the user is running a web application and chooses the "Save" command, and although this normally doesn't trigger a pop-up, this time a network error or server limit prevents the document from being saved, and the application wants to put up a warning dialog box...

<AllanJ> ...telling the user and asking how it should proceed. This dialog would be in response to user input, yet not expected by the user. If the user has chosen to allow pop-ups but not to let them take focus, should the browser give this dialog focus?

<AllanJ> ja: that seems to be explicit user request

<AllanJ> gl: so that's a 'user action'

<AllanJ> ... so what if I open a web page an explicit request, and the page opens three other windows.

<AllanJ> ja: don't want the 3 pages to be as a result of explicit request

<scribe> ACTION: kford to look at survey results from http://www.w3.org/2002/09/wbs/36791/20100521/results and draft new text addressing issues in 3.10.8. [recorded in http://www.w3.org/2010/06/03-ua-minutes.html#action01]

<trackbot> Created ACTION-400 - Look at survey results from http://www.w3.org/2002/09/wbs/36791/20100521/results and draft new text addressing issues in 3.10.8. [on Kelly Ford - due 2010-06-10].

<AllanJ> gl: but our language does not exclude that.

Proposal for 3.10.9 Stay on Top http://www.w3.org/2002/09/wbs/36791/20100521/results#xq9

<AllanJ> kf: accept, JS write an action item

<jeanne> ACTION: JS to update document with revised 3.10.9 to include editorial comments from the survey of May 29 - June 3 [recorded in http://www.w3.org/2010/06/03-ua-minutes.html#action02]

<trackbot> Created ACTION-401 - Update document with revised 3.10.9 to include editorial comments from the survey of May 29 - June 3 [on Jeanne Spellman - due 2010-06-10].

Proposal for 3.10.10 Close Viewport http://www.w3.org/2002/09/wbs/36791/20100521/results#xq10

<AllanJ> KP: watch for being to mouse centric

<AllanJ> gl: do we really need this?

<AllanJ> gl: close the window? or close the currently active 'tab' in the browser?

<AllanJ> ... close any browser window or UA document (tab).

<AllanJ> KF: both

<AllanJ> gl: we need to change the definition.

<AllanJ> ... of 'top level viewport'

<AllanJ> gl: back to the beginning. user should be able to close any UA window or any window or document (tab)

<AllanJ> gl: according to definition, it only addresses the former.

<AllanJ> kf: should be the latter

<AllanJ> gl: closing a browser window is a platform issue.

<AllanJ> gl: is a frame a viewport?

<Greg> Kelly says that the user should be able to close any browser window or tab, but not a frame or a fixed-size div that has scrollbars.

<Greg> That means we should have a term for those; 'viewport' might be the right term, but not using our current definition in UAAG20.

<AllanJ> kf: if this SC used some other term, or we redefined term, is this SC ok.

<AllanJ> gl: have to clarify the definition of viewport.

<AllanJ> issue: resolution of 3.10.10 pending on definition review in action-240 viewports, scrollbars and overflow

<trackbot> Created ISSUE-70 - Resolution of 3.10.10 pending on definition review in action-240 viewports, scrollbars and overflow ; please complete additional details at http://www.w3.org/WAI/UA/tracker/issues/70/edit .

kelly to start e-mail threads on remaining survey questions.

Summary of Action Items

[NEW] ACTION: JS to update document with revised 3.10.9 to include editorial comments from the survey of May 29 - June 3 [recorded in http://www.w3.org/2010/06/03-ua-minutes.html#action02]
[NEW] ACTION: kford to look at survey results from http://www.w3.org/2002/09/wbs/36791/20100521/results and draft new text addressing issues in 3.10.8. [recorded in http://www.w3.org/2010/06/03-ua-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/06/03 19:39:08 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: kford
Inferring ScribeNick: kford
Default Present: +1.512.206.aaaa, AllanJ, kford, Jeanne, +1.425.895.aabb, Greg, sharper
Present: +1.512.206.aaaa AllanJ kford Jeanne +1.425.895.aabb Greg sharper
Regrets: Patrick_Lauke Mark_Hakkinen
Found Date: 03 Jun 2010
Guessing minutes URL: http://www.w3.org/2010/06/03-ua-minutes.html
People with action items: js kford

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.
[End of scribe.perl diagnostic output]