See also: IRC log
<trackbot> Date: 03 March 2011
<mhakkinen> mark is on IRC today.
<JAllan> Hi Mark
<mhakkinen> hi jim... having to listen to a conflicting call for the next hour. will be on IRC.
<mhakkinen> sent my survey responses.
<scribe> Scribe: KFord
GL describes shuttle launch experience.
survey shows 4 accepts,
KP: I thought there might be more
users. Low vision if you are going back and forth. Same reason
for people with hand problems.
... You don't want to go magnify one part of the screen and
then go magnify another. Users with cognitive concenrs too.
<jeanne> Kim +1
JA: Anyone have issues with adding these users?
No issues heard.
JA: Reads concern expressed by PL.
Clarification: is the "online" part of "online document processor" on purpose? To me, that would suggest a web application / rich text editor running inside
a browser, i.e. WCAG and ATAG territory, rather than UAAG.
JA: To me I think Patrick raises a valid point.
GL: I relize this is only an example but we should adjust to be a UAAG example.
SH: Reading this again I think I originally thought this was for web apps but now I don't.
GL: I have two things. 1. Configure position as a title isn't appropriate when you have more than this now.
JA: How about configure toolbar.
GL: There isn't much about configuring toolbars, just their content. Do we want it to apply to show/hide of toolbars.
JA looking for itmes on toolbars in general. Not finding.
<scribe> ACTION: JA to write SC on general toolbar show/hide and such. [recorded in http://www.w3.org/2011/03/03-ua-minutes.html#action01]
<trackbot> Created ACTION-513 - Write SC on general toolbar show/hide and such. [on Jim Allan - due 2011-03-10].
GL: Haven't check toolbar definition but I want to ensure our definition and SC apply to the broader definition of toolbars. For example some apps distinguish between something that is docked versus floating and separate from the main app window.
<scribe> ACTION: GL to write glossary definion for toolbar [recorded in http://www.w3.org/2011/03/03-ua-minutes.html#action02]
<trackbot> Created ACTION-514 - Write glossary definion for toolbar [on Greg Lowney - due 2011-03-10].
GL: In related resources it says WAI Aria but nothing indicates why we are sending people to ARIA.
JA: ARIA would make sense if we were talking about a web app but since we are not, yes ARIA should probably go.
SH explains why it was there, mostly hold over.
JA: Any disagreement from removing ARIA?
None heard.
JA gives further explanation to SH and asks to think about incorporating GL's concerns about the bbroader definition.
JA Looks like we all accept.
Group goes over couple issues listed in survey.
Group talks about differing uses of silver surfer.
GL brings up concerns around derfaults here.
JS: I didn't think this was that big of a deal. Restoring defaults could be a block, toolbars wouldn't be as much of a block.
<Greg> That is, we have the ability to restore all preference settings to default, and this is the only or one of a very few narrower categories of preference settings that we're giving their own reset.
JA: It seems like GL 2.5 is for
the browser itself. We put 2.8 separate because it was for
extensions, although we've now lost this concept.
... Do we need to clarify 2.5 to be applies to the things that
come by default with the browser and 2.8 is for extensions i.e.
things people add?
GL: I don't think 2.8 is completely the same as 2.5. I think it is worth while to call out that we suggest user agents let people restore toolbar defaults.
JA: Do we need a SC that calls out extensions specifically.
Group seems to say no because these are just part of the user agent.
<Greg> I do think 2.8 is not redundant to 2.5; 2.5 says the user can configure and restore preference settings, but it's up to other SC such as 2.8 to call out specific preference settings we think user agents should provide. I think it is worthwhile to call out that we recommend user agents allow users to configure toolbars, which help pointing device users (among others) just like configuring...
<Greg> ...keyboard mappings help keyboard and many AT users.
<Greg> I'd have the SC explicitly apply only to "recognized" background images. The fourth paragraph of the intent makes this clear, but it wouldn't hurt to acknowledge it in the SC itself.
<JAllan> +1 to using recognized
<Greg> Do we have examples of user agents allowing the user to replace the background image on a page? Do you think we can have them by the time we publish?
GL: Restates concenrs expressed in survey.
Group talking about replacing of backgroud images and what this means and what user agents support this or would support this.
Group going through different background image scenarios and resulting problems e.g. white on white.
<Greg> I'm not sure replacing the background image (with solid color or another image) is important enough to be Level A, since you can omit the image and it's replaced by the normal solid background color.
JA: Any objection to removing the word replaced?
None heard.
<JAllan> New wording for SC: Improve Foreground Legibility: The user can have all recognized background images shown or hidden.
<Greg> The second paragraph of Intent states "Users could have the option to have non-transparent backgrounds of a solid color of their choice drawn behind text, rather than turning off background images…." It seems clear from the wording of the SC that this would *not* be sufficient to conform, and therefore is merely a best practice that could be done _in addition to_ conforming to the SC. If so...
<Greg> ...we should make that more explicit. Did you decide not to have this be a separate SC?
Group continuing to work through GL feedback.
<Greg> The third paragraph of Intent says that "[when background images] display is turned off the user agent should give users access to any alternative content associated with them…" I'm not sure this would be useful without giving the user feedback that a background image has been hidden; without that few users would search through dialog boxes just on the off chance that the page has a...
<Greg> ...background image that has alternative content. As discussed before we do want to address the possibility of technologies allowing alternative content for background images, even though HTML doesn't yet support this, but since there are thus no implementations are we allowed to require it? Or is the compromise to just (and hopefully more clearly) recommend this as an additional best...
<Greg> ...practice that is more clearly states to not be a requirement or addressing the requirement?
<Greg> "Because background images occasionally convey important information, when their display is turned off, it is recommended that the user agent give users access to any alternative content associated with them, and either alternative content on the page or provide feedback telling the user that alternative content is available. At the time of this writing, HTML does not support alternative...
<Greg> ...content for background images, but this may be supported in other technologies or future versions."
<Greg> Finally, now that drawing solid color behind text is not part of the SC, the SC's title should be narrowed to match the SC wording, such as "Hiding background images".
<Greg> (The broader title made sense when we were going to make the SC broader.)
JA: I'll rewrite this and put it on the list.
JA brings up concerns expressed by PL in survey.
JA: Anyone unhappy with making this an or visual or audiotyr indicator?
<Greg> I think that there should be a visual indicator of paused if there's visual presence, and audio feedback if there's only audio presence (e.g. in an audio-only browser).
<Greg> I don't think it would be good for the user to go to a page, see a still image in place of a paused video, and only a small chirp indicates that there's paused media. But maybe that's just bad UI design, not important enough to discuss in the doc.
Group talking about PL concern about audio that may be played only from scrippt and where visual notification should appear.
GL: We could refine this to talk about when the user agent can recognize.
Anotyher idea around here was some frame notification like user agents do for other blocked content.
JA will go through and rewrite.
<Greg> Ideally this would apply only to cases where the user agent can recognize that the media is being played automatically on page load, such as when the page defines a background (autoplay) audio. It would not apply when scripts play media, since the user agent can't be sure it's an auto-play, and may not be able to intervene in any case.
<JAllan> 1.8.5 (former 3.10.6) Viewport History:
<JAllan> For user agents that implement a viewport history mechanism (e.g. "back" button), the user can return to any state in the viewport history, restoring the prior point of regard, input focus and selection. NOTE: This success criteria does not apply to web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data...
<JAllan> ...storage systems, or that submit user test responses. (Level A)
<JAllan> Intent:
<JAllan> Typically, when a user goes to a new page the point of regard is the top of the page. If the user returns to a previously viewed page the point of regard should be restored to its position when the user moved away from the page.
<JAllan> The intent of the note is to prevent users from
<JAllan> This will help users who may have difficulty re-orienting themselves during a browsing session. This includes some users with a memory or cognitive disability, some users with a physical disability, and some users with serial access to content or who navigate sequentially, for whom repositioning will be time-consuming.
<JAllan> note: This checkpoint only refers to a per-viewport history mechanism, not a history mechanism that is common to all viewports (e.g., of visited Web resources).
<JAllan> Examples:
<JAllan> Related Resources:
<JAllan> WCAG 3.3.4 http://www.w3.org/TR/WCAG20/#minimize-error
Group discussion exclusions.
Talking about if exclusions should exist or not.
Consensus is that probably do not need the exclusions.
GL: It seems like this isn't saying the user has to be able to back to every place but when you do allow this, you need to do all the items we've listed.
<JAllan> kelly: agree about removing exclusion, asking the UA to interpret what is happening on a page/site
<Greg> I think we can safely say that when the user agent allows the user to return to a page in the history (e.g. a "back" button) it should restore point of regard, etc., as we're not saying the user agent has to let the user go back to every page.
JA: Original 1.8.5 doesn't have the note.
<Greg> This SC is really saying two things, one is that it DOES say the user can go back to any page, which we may not want to require, and it also says that when the user does go back, point of regard etc. are restored, which I think is safe to say. Maybe those should be separate.
<Greg> It's also interesting that we nowhere require the user agent to provide a back button or history, but we say if you do, you have to let them go back to any page.
<Greg> I'd say have one SC recommending user agents provide history mechanism where user can go back to past pages, but acknowledge that there may be pages that the user should not be allowed to return due to security, etc.
<Greg> Then a second SC that says when you do let the user go back to a previous page, you should restore point of regard etc.
<Greg> Could there be user agents where a back button is not applicable or recommended, such as a media viewer?
Group talking about cases where back shouldn't be supported.
<Greg> Although if the two portions have the same level I guess they can be combined.
<JAllan> kelly: why is this an accessibility issue...having a history
<Greg> History and back buttons are an accessibility feature because (a) it reduces memory load (b) it reduces typing and navigating (e.g. re-typing URL into a address bar).
Any disagreement with SC saying we need a back button?
<Greg> Conclusion is that we'll have one SC that will both require a history mechanism, allow the user to return to past pages except where forbidden by author or security or similar requirements, and when returning to a page the point of regard etc. will be restored.
<Greg> A related question: should returning to a page via the history mechanism explicitly NOT reload the page (e.g. run initialization scripts)? If scripts are run, etc. then returning to the previous point of regard etc. may not be appropriate or possible (e.g. the script moves the focus to a particular point.)
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) Succeeded: s/must their contnet/just their content/ Found Scribe: KFord Inferring ScribeNick: kford Default Present: Jeanne, Greg, JAllan, kford, Jan, KimPatch, sharper, MarkH Present: Simon Kim Jim Jeanne Greg Kelly Jan Mark Found Date: 03 Mar 2011 Guessing minutes URL: http://www.w3.org/2011/03/03-ua-minutes.html People with action items: gl ja WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]