See also: IRC log
<trackbot> Date: 31 May 2012
<JAllan> Latest editor's draft -
<JAllan> http://www.w3.org/WAI/UA/2012/ED-UAAG20-20120524/
<kford> 1
<kford> Scribe: kford
<JAllan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0092.html
<JAllan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0091.html
JA going over research he did on this topic.
JA: My proposal was to leave 1.11.1 alone and just add the resources.
<JAllan> 1.11.1 Access Relationships: The user can access explicitly-defined relationships based on the user's position in content (e.g. show form control's label, show label's form control, show a cell's table headers). (Level A)
JA: Bottom line is that 1.11.1 has remained unchanged.
Group talking about moving 1.11.1 to level AA.
KFord: I don't want to block on tablke headers.
<Greg> The wording "based on the user's position in content" is not used elsewhere, and is somewhat vague, but not a show-stopper.
Resolved: 1.11.1 text staying the same. Level moving to AA.
<JAllan> scribe: jallan
kelly: reviews 1.11.2...its a mess. why is this needed, what is the accessibility case
kf: if we didn't have this, who would it deny access to.
<jeanne> JA: I can see the doc type from the status bar
kf: how would folks feel about deleting 1.11.2
<jeanne> KF: The browser should expose the status bar, but that is covered elsewhere
<jeanne> Greg: I'm not sure that opening a window or tab is the problem that it once was.
gl: title covered by something else. not convinced that opening in new window or tab is not as big a problem as it used to be.
<kford> Now to Kim: opening in a new window is one of the big complaints I hear.
<jeanne> ... but this SC is very different from what my users want
<kford> KFord: Kim can you clarify this.
kp: how to open content in a new window or tab
<kford> Kim: My users want to know how to opena link in a new window.
<scribe> scribe: kford
Kim: My users want to control this, if you can do that then their needs would be covered.
<JAllan> scribe: jallan
kf: kim, explain accessibility reason for having this,
kp: can't see two tabs at the same time. easy to switch or see two windows at the same time.
kf: IE and FF have settings for controlling open of links in new tabs or windows
kp: functionality is there, but it needs to be attached to the keyboard
ja: seems to be more of an education issue rather than functionality issue.
kf: control-enter opens in new tab, control-shift-enter opens in new window
kp: mouseless browsing numbers with a control to open in a new tab would work
kf: we have a SC for direct selection of links, but do we need another SC for this new functionality
kp: after checking...all functionality is there. its just education
kf: 1.11.2 should be deleted
<scribe> scribe: kford
Resolved: group deleting 1.11.2
Issue: In UAAG next address need to be able to directly activate a link and control target of the link opening i.e. new window, new tab for speech users.
<trackbot> Created ISSUE-93 - In UAAG next address need to be able to directly activate a link and control target of the link opening i.e. new window, new tab for speech users. ; please complete additional details at http://www.w3.org/WAI/UA/tracker/issues/93/edit .
<JAllan> close action-647
<trackbot> ACTION-647 Write a scoping NOTE about Guideline 4.1 closed
<JAllan> close action-467
<trackbot> ACTION-467 Revise 1.11.1 and 1.11.2 make proposal to the group closed
<scribe> ACTION: JS to delete 1.11.2 from document after group consensus. [recorded in http://www.w3.org/2012/05/31-ua-minutes.html#action01]
<trackbot> Created ACTION-734 - Delete 1.11.2 from document after group consensus. [on Jeanne F Spellman - due 2012-06-07].
<JAllan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0088.html
<jeanne> close action-467
<trackbot> ACTION-467 Revise 1.11.1 and 1.11.2 make proposal to the group closed
<Greg> Minor editorial: change "are true" to "occur" or the like.
<jeanne> close action-734 complete
<jeanne> action-734 complete
<jeanne> close action-734
<trackbot> ACTION-734 Delete 1.11.2 from document after group consensus. closed
<Greg> How about "The point of regard remains within the visible portion of the viewport, and where possible at the same location within the viewport, when any or all of the following occur..."
<Greg> The way I think of point of regard is it's whichever changed most recently: the focus location, or selection, or find results, or content at the leading edge of the viewport.
<Greg> Consider replacing "point of regard" with "area of regard" to acknowledge the fact that it's usually not just a point but a region.
<JAllan> New definition:
<JAllan> point of regard
<JAllan> The point of regard is the portion of rendered content that the user
<JAllan> is presumed to be viewing. The dimensions of the point of regard may
<JAllan> vary. For example, it may be a two-dimensional area (e.g. content
<JAllan> rendered through a two-dimensional graphical viewport), or a point
<JAllan> (e.g. a moment during an audio rendering or a cursor position in a
<JAllan> graphical rendering), or a range of text (e.g. focused text). The
<JAllan> point of regard is almost always within the viewport, but it may
<JAllan> exceed the spatial or temporal dimensions of the viewport (see the
<JAllan> definition of rendered content for more information about viewport
<JAllan> dimensions).
<JAllan> The point of regard may also refer to a particular moment in time for
<JAllan> content that changes over time (e.g. an audio-only presentation).
<JAllan> User agents may determine the point of regard in a number of ways,
<JAllan> including, based on viewport position in content, keyboard focus, and
<JAllan> selection. The stability of the point of regard is addressed by 1.8.z
<Greg> What we really mean might be closer to "Where possible, the *entire* point of regard remains within the visible portion of the viewport, and at the same location within the viewport, when any or all of the following occur..."?
<jeanne> how do we communicate these subtleties to the poor developer trying to figure out what we mean?
Group continuing to discuss this topic.
<JAllan> leading edge, selected or focused, or whatever changed last should remain in the viewport
<JAllan> 1.8.z Maintain Point of Regard: The point of regard remains at the
<JAllan> same relative location within the visible portion of the viewport when
<JAllan> any or all of the following are true:
<JAllan> (a) the viewport is resized; or
<JAllan> (b) the zoom/scale on the viewport is changed; or
<JAllan> (c) the formatting of some or all of the content changes (e.g. font or
<JAllan> text size, causing content to change height and/or rewrap).
<JAllan> UNLESS there is focused or selected content INSIDE the pre-zoomed
<JAllan> viewport, in which case the focused/selected content remains in the
<JAllan> post-zoom viewport.
<JAllan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0088.html
<Greg> "To the extent possible, the point of regard remains visible and at the same location within the viewport when the viewport is resized, content is zoomed or scaled, or formatting of content changes."
Jeanne: I like Greg's solution.
Kim: I like it as well.
<Greg> "The point of regard remains within the visible portion of the viewport, and at the same location within the viewport, when the viewport is resized, content is zoomed or scaled, or formatting of content changes." We could relegate to the IER the recommendation of what to do when viewpoint can no longer show the the entire point of regard.
<KimPatch> "To the extent possible, the point of regard remains visible and at the same location within the viewport when the viewport is resized, content is zoomed or scaled, or formatting of content changes."
<JAllan> 1.8.z Maintain Point of Regard:
<JAllan> Intent: It can be disorienting and confusing when a user changes the
<JAllan> viewport size or zooms the content and the current content shifts out
<JAllan> of the viewport causing different content on the same page to be
<JAllan> displayed in the viewport. Just as the location in audio does not
<JAllan> change when the user increases the volume, the current point of regard
<JAllan> should not change when the user changes the size of the window or
<JAllan> zooms the content.
<JAllan> Starting with the base assumption that regardless of other items that
<JAllan> may have focus, or be selected, the current viewport is that
<JAllan> information which is visible to the user within the bounds of the user
<JAllan> agent content area. When any of the SC conditions are met, the user
<JAllan> agent should maintain the same top-left (top-right for RTL) corner
<JAllan> UNLESS there is focused or selected content INSIDE the pre-zoomed
<JAllan> viewport, in which case the focused/selected content remains in the
<JAllan> post-zoom viewport. {repeated for emphasis}
<JAllan> Note: "Content" and "selected" are used because there may be cases
<JAllan> where the viewport is zooming into just part of an element (e.g. if I
<JAllan> select a few words of text that are part of a <p> and zoom in)
<JAllan> Examples of Success Criterion 1.8.z
<JAllan> -- Jorge is a low vision user. While viewing a webpage he sees a
<JAllan> picture with a caption that is too small to read. He highlights the
<JAllan> caption, then uses the browsers zoom feature to increase the size of
<JAllan> the content so he can read the caption. Through the zooming process
<JAllan> the highlighted caption remains in the viewport, allowing Jorge to
<JAllan> keep oriented on the caption and begin reading it when the appropriate
<JAllan> content size is reached.
<JAllan> Later while reading on a page, Jorge finds some text that is too large
<JAllan> to read. The beginning of the large text is at the top of the bowser
<JAllan> content area. He uses the zoom feature to make the content smaller.
<JAllan> the text is reduced to a confortable reading size and the beginning of
<JAllan> the text remains at the top of the browser window.
<JAllan> -- Melissa has a distraction disorder. She is doing research for
<JAllan> school. She scrolls the content so the relevant section heading the
<JAllan> top line of the browser. She resizes the browser so she can see her
<JAllan> notes and the browser at the same time. After resizing the browser the
<JAllan> heading is still the top line of the viewport.
<JAllan> -- Xu has a reading disability. He needs only the text on a page to be
<JAllan> larger. He is reading a page with footnotes that are too small to
<JAllan> read. Xu places the footnote at the top of the browser, and using the
<JAllan> increase font-size feature, he increases the font-size of the text on
<JAllan> the page. The footnotes stay on the top of the viewport.
<Greg> I'd add that in addition to being disorienting and confusing, the user may be forced to expend considerable time and effort finding and navigating back to the place where they were working.
<JAllan> Users may have to expend considerable time an effort to re-navigate back to their previous point of regard.
<Greg> First sentence needs editing, as it runs on now.
<Greg> It could start "User can be confused and disoriented when the area where they are working suddenly shifts outside the visible region of the viewport... In addition, the user may be forced..."
<JAllan> close Action-630
<trackbot> ACTION-630 Propose SC on maintaining point of regard when scaling the page closed
<JAllan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0080.html
<JAllan> proposed:
<JAllan> *shortcut*
<JAllan> A command that's tied to a particular UI control or application
<JAllan> function, allowing the user to navigate to or activate the control or
<JAllan> function without traversing any intervening controls. A shortcut is
<JAllan> modality independent, meaning it is accessible by any input method (e.g.
<JAllan> keyboard, mouse, speech, touch or gesture). Also see Modality
<JAllan> Independence Principle.
<JAllan> Shortcut definition*
<JAllan> *keyboard command (keyboard binding, keyboard shortcut or accelerator keys)*
<JAllan> A key or set of keys that are tied to a particular UI control or
<JAllan> application function, allowing the user to navigate to or activate the
<JAllan> control or function without traversing any intervening controls (e.g.
<JAllan> "ctrl"+"S" to save a document). It is sometimes useful to distinguish
<JAllan> keyboard commands that are associated with controls that are rendered in
<JAllan> the current context (e.g. "alt"+"D" to move focus to the address bar)
<JAllan> from those that may be able to activate program functionality that is
<JAllan> not associated with any currently rendered controls (e.g. "F1" to open
<JAllan> the Help system). Keyboard commands help users accelerate their
<JAllan> selections. Also see Shortcut.
GL: Trying to underand exactly what is meant by command.
Kim: A command is the act of communicating with a computer.
More discussion around this. Trying to get clarification.
<JAllan> scribe: jallan
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) Found Scribe: kford Inferring ScribeNick: kford Found Scribe: jallan Inferring ScribeNick: JAllan Found Scribe: kford Inferring ScribeNick: kford Found Scribe: jallan Inferring ScribeNick: JAllan Found Scribe: kford Inferring ScribeNick: kford Found Scribe: jallan Inferring ScribeNick: JAllan Scribes: kford, jallan ScribeNicks: kford, JAllan Default Present: Jeanne, kford, Jim_Allan, Greg_Lowney, Kim_Patch Present: Greg Jim Kim Jeanne WARNING: Replacing previous Regrets list. (Old list: simon, mark) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ Mark, Simon, Jan Regrets: Mark Simon Jan Found Date: 31 May 2012 Guessing minutes URL: http://www.w3.org/2012/05/31-ua-minutes.html People with action items: js WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]