See also: IRC log
<trackbot> Date: 21 June 2012
<scribe> Scribe: kford
JR: reads his definition.
Prefaced with not entirely happy but maybe we can adjust.
... One concern I have is all the things that might be hidden and what counts as top level functionality. Open, save, bold, these might not be user agent but what about when you are saving, say as PDF or text.
... When Greg did this he assumed thereJR: My concern with the previous definiton was that it was too broad.
... I tried to get at the problem by saying we felt it was important to have fast access to key features that were in nested menus or functions in general.
... Greg went with the approach if you have tool bars do x. I'm taking the approach that we want to have toolbars to make commands easier to get to.
JA: This has become complicated. Goes over where Greg started from and JR's now means you have to have them.
<Greg> Configurable toolbars have numerous benefits, including but not limited to: (a) providing quicker (i.e. with fewer actions) access to commands that are normally hidden or nested; (b) providing pointer access to commands that normally have only keyboard access; (c) providing reminders of available options for people with memory limitations; (d) providing keyboard access for commands that are...
<Greg> ...normally done only with the pointing device (in UI that doesn't provide menus); (e) providing graphic items for commands that might otherwise only have text; (f) provide persistent visual display of information that would normally be hidden or nested (e.g. a drop-down list box showing font size or name); etc.
JR: Thnis gives you more ability to do whatever you want with your UI but does demand that you have this one area that's configurable.
JA: Anything that does this?
KP: Word. Kim goes over the Office Quick Access toolbar that allows you to add almost any command.
<JAllan> can also create unique ribbons with own most used commands or anything else
JA: I think we now have two separate items. One is now talking about creating your own toolbars and one talking about being able to show/hide and such.
<Greg> Should it also address commands that are available through the keyboard but not through nested menus?
<Greg> One could have it apply to commands available through menu items or keyboard shortcuts. That would avoid accidentally requiring every checkbox in dialog boxes to be covered.
Group continuing to talk about toolbar definition. Missed a couple items in the scribing as they refine.
<Greg> The risk of combining all the existing SC into a single SC is that, for example, a UA would fail the entirety if it fails to provide "reset", even if it provides wonderful, fully configurable toolbars.
JA: What confused me was the talk of the nested menus.
JR: What I was saying that if your user interface was so simple that you have no toolbars, I was trying to say you didn't need them. But if you had things hidden then you would need toolbars.
GL: Menus in today's GUI environment are all nested then.
KP: What makes the original idea hard????????
<Greg> It's not hard if the app is designed to be scriptable, with separation of function from UI, but it would be prohibitively difficult if the app was designed with no abstraction layer.
GL: Word was designed with this idea in mind from the ground up. If this isn't done, then things are almost impossible.
GL goes over various aspects of toolbars and what we might expect.
This is in reference to fully configurable.
<Greg> Potentially problematic example is if app distinguishes between status bar where things are displayed vs. toolbar where input takes place. Would we expect the app to let the user move things between the two?
JR: There/me anyone else willing
to scribe, I'm just not getting it today.
... I think I'm OK with a customizable toolbar as long as you don't have to have everything. Gives example of not having to have a report bad web site from Mozilla.
<Greg> Discussion of whether or not configurability is as important as providing a toolbar at all.
Greg, Jan and Kim agree to work on this area further.
JA: Greg this is one you and
... This was on the board from the F2F.
... We have a guideline that says User Agent can do different things with images e.g. turn them off/on.
<Jan> ACTION: JR to With Greg and Kim to bring forward new toolbar SC wording. [recorded in http://www.w3.org/2012/06/21-ua-minutes.html#action01]
<trackbot> Created ACTION-740 - With Greg and Kim to bring forward new toolbar SC wording. [on Jan Richards - due 2012-06-28].
JA: Question came up with
... This won't be recognized as an image.
... We then said recognized images?
GL: The question is then for
those SC we have on images, should we try and make them apply
... Maybe we need a task to go over all SC to identify which will apply to non-html items like svg, math ml and such.
<Greg> Perhaps we should make a pass over all the SC identifying which ones might cause complications with non-HTML formats such as SVG, MathML, etc.
<Greg> Specifically when SC are written with HTML in mind and it might not be clear if and how it applies to other web technologies. E.g. does the requirement to let the user turn off images apply to SVG?
<jeanne> jeanne: I think that's a good idea, but its separate from the current issue of turning off images.
<jeanne> Kim: in related resources, there is info on 1.2.1 - configure default rendering addresses this.
GL: We are not able to completely ignore this area.
<Greg> Benefits of being able to turn off images include but are not limited to: (a) helping users avoid distraction; (b) increasing the amount of information that can be displayed at one time, including for people who do not make use of the images due to visual impairments, people who want to reduce the amount of scrolling, people who need to keep information on the screen due to short-term memory...
<Greg> ...issues; (c) avoiding pain caused by high visual contrast; etc.
JA: I'm lost. JS has a concern
that turning off SVG could turn off more accessible
... The original concern was that we needed to do something about SVG?
Group is going to table this discussion
<Zakim> jeanne, you wanted to say that there are people working on accessibility of SVG and SVG does have content beyond alt text.
<Jan> 3.2.X Text Entry Undo (Minimum): The user can undo text entry actions that have not undergone content processing. (Level A)
<Jan> Note: Content processing can refer to server-side or client-side processing.
<Jan> 3.2.Y Settings Change Confirmation: If the user agent provides mechanisms for changing its user interface settings, then those mechanisms can reverse the setting changes, or the user agent requires user confirmation to proceed. (Level A)
<Jan> 3.2.Z Text Entry Undo (Enhanced): The user can undo a sequence of unprocessed text entry actions by character (or short character strings). (Level AA)
<Jan> Note: Content processing can refer to server-side or client-side processing.
JR reads his text.
<Greg> For the first, what is processing? Spell-checking?
<Greg> If spell-checking is a form of processing, then it would negate the requirement to undo text entry.
JR: This is meant for the rich
internet application where user input is grabbed immediately
and the user agent has no idea that this has happened.
... In those cases the user agent wouldn't be able to undo.
Group talking about example of Googledocs where you can undo.
Group talks further about who process the text and who's responsibility this is.
<Greg> Jan believes Google Docs is a UA, while Kelly believes it is not; we should come back to that.
<Jan> The link above is relevant to user agent-authoring tool intersection.
<Greg> Re "3.2.Y Settings Change Confirmation", the SC should allow the UA to let the user turn off confirmation.
<KimPatch> 3.2.Y Settings Change Confirmation: If the user agent provides mechanisms for changing its user interface settings, it either allows the user to reverse the setting changes, or requires user confirmation to proceed. (Level A)
<KimPatch> 3.2.Y Settings Change Confirmation: If the user agent provides mechanisms for changing its user interface settings, it either allows the user to reverse the setting changes, or requires user confirmation to proceed. The user agent also includes a mechanism to let the user turn off confirmation. (Level A)
<Greg> What are examples of UI settings that can't be reversed?
<Jan> 3.2.Y Settings Change Confirmation: If the user agent provides mechanisms for changing its user interface settings, it either allows the user to reverse the setting changes, or the user can require user confirmation to proceed. (Level A)
<JAllan> gl: if we can't come up with real examples, then we should remove it.
<JAllan> kim: should keep this. idiot proofing
<Greg> Would for example turning off the option for screen reader compatibility count as non-reversible, given that the user who relies on a screen reader would presumably not be able to turn it back on by themselves?
<JAllan> jr: useful example, but not what I meant. i meant in any way they user could not reverse the setting
<JAllan> sh: a while ago, I wrote what it means to be a UA, app, plugin, extensions.
<JAllan> js: all that is in the top of the document.
<jeanne> jeanne: it's in the intro of the Implementing document.
<JAllan> sh: don't want jan to duplicate effort
<JAllan> jr: should have said recognized instead of processed with in 3.2.x,y,z
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/nexted/nested/ Found Scribe: kford Inferring ScribeNick: kford Default Present: Jim_Allan, kford, Jeanne, sharper, Greg_Lowney, Kim_Patch Present: jim kelly jan greg kim simon jeanne Regrets: mark wayne Found Date: 21 Jun 2012 Guessing minutes URL: http://www.w3.org/2012/06/21-ua-minutes.html People with action items: jr WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]