- From: Jim Allan <jimallan@tsbvi.edu>
- Date: Thu, 17 Nov 2011 13:43:39 -0600
- To: WAI-ua <w3c-wai-ua@w3.org>
- Message-ID: <CA+=z1WmaXGKR7rpM4eTpR-JEbsR6PY88-M+7sO6bQ_rXLJf0Jg@mail.gmail.com>
from: http://www.w3.org/2011/11/17-ua-minutes.htmlUser Agent Accessibility
Guidelines Working Group Teleconference 17 Nov 2011
See also: IRC log <http://www.w3.org/2011/11/17-ua-irc>
http://www.w3.org/2011/11/17-ua-irc
Attendees
Present kim, jim, kelly, wayne, simon, greg, Mark, (IRC) Regrets Jan,
Jeanne Chair KellyFord, JimAllan Scribe jallan
Contents
- Topics <http://www.w3.org/2011/11/17-ua-minutes.html#agenda>
1. Survey
http://www.w3.org/2002/09/wbs/36791/20111115/<http://www.w3.org/2011/11/17-ua-minutes.html#item01>
2. 2.4.1 Find <http://www.w3.org/2011/11/17-ua-minutes.html#item02>
3. 2.4.2 Find
direction<http://www.w3.org/2011/11/17-ua-minutes.html#item03>
4. 2.4.3 Match Found<http://www.w3.org/2011/11/17-ua-minutes.html#item04>
5. 2.4.4 Alert on No
Match<http://www.w3.org/2011/11/17-ua-minutes.html#item05>
6. Assign owners for SC needing attention
http://lists.w3.org/Archives/Public/w3c-wai-ua/2011OctDec/0071.html<http://www.w3.org/2011/11/17-ua-minutes.html#item06>
7. UA mobile <http://www.w3.org/2011/11/17-ua-minutes.html#item07>
- Summary of Action
Items<http://www.w3.org/2011/11/17-ua-minutes.html#ActionSummary>
Summary of Action Items*[NEW]* *ACTION:* jeanne to add 2.4.1 "The user can
perform a search within rendered content (e.g. not hidden with a style),
including rendered text alternatives and rendered *generated* content, for
any sequence of *printing* characters from the document character set.
(Level A) [recorded in http://www.w3.org/2011/11/17-ua-minutes.html#action01
]
*[NEW]* *ACTION:* jeanne to add 2.4.2 Find Direction: The user can search
forward or backward in rendered content. (Level A) to document [recorded in
http://www.w3.org/2011/11/17-ua-minutes.html#action03]
*[NEW]* *ACTION:* jeanne to add 2.4.3 Match Found: When a search operation
produces a match, the matched content is highlighted, the viewport is
scrolled if necessary so that the matched content is within its visible
area, and the user can search from the location of the match. (Level A)
[recorded in http://www.w3.org/2011/11/17-ua-minutes.html#action04]
*[NEW]* *ACTION:* jeanne to add 2.4.4 Alert on Wrap or No Match: The user
can be notified when there is no match. The user can be notified when the
search continues from the beginning or end of content. [recorded in
http://www.w3.org/2011/11/17-ua-minutes.html#action05]
*[NEW]* *ACTION:* kford look at intent for 2.4.1 on find and ensure it
clearly states goal to allow the user to find whatever the user agent is
displaying e.g. covers the case where you have chosen alternatives.
[recorded in http://www.w3.org/2011/11/17-ua-minutes.html#action02]
------------------------------
<trackbot> Date: 17 November 2011
<scribe> scribe: jallan
Survey http://www.w3.org/2002/09/wbs/36791/20111115/
<kford> Survey results:
<kford> http://www.w3.org/2002/09/wbs/36791/20111115/results
2.4.1 Find
http://www.w3.org/2002/09/wbs/36791/20111115/results#xq1
kf: reviewing results
gl: leaning toward AA because of search for alternative content
kf: gregs point about searching for text alternatives. what are thoughts
<Wayne> yes
sh: alternatives need to be searchable. I think information would be lost
gl: if person who is blind, we have an sc to have alternative content
rendered, so when they search it would show up in search. there is a work
around
sh: shouldn't make a difference.
kim: should be an A.
gl: every UA should be able to search for alt text
sh: even tho alt is rendered in audio viewport, should be searchable
kf: so if you configure UA to show alt instead of alternatives, then search
should find the alt.
<Greg> One option is to clarify that 2.4.1 includes "rendered
content...including *rendered* text alternatives", another is to make it
explicitly "rendered content...including text alternatives that may or may
not be rendered in the current view".
<KimPatch> I like what Kelly said -- user selected alternatives
sh: if an audio only browser, then what can be searched. content is only
rendered when spoken.
kp: would 'user selectable alternatives' work
sh: if a standard audio browsers, then the user would not have to select
anything, and search should find it.
<Greg> I'm afraid of "user selected alternatives" because it implies the UA
lets the user select from, say, a mulitselect list of all the different
types of supported text alternatives, which seems unwieldy.
kf: we have other sc about the cascade to reveal other content then it
would be searchable
<mth> Is title attribute text included in search? Is css inserted text? Are
items in a list box?
kf: this should not be confusing and doesnt imply multiselect, it would
depend on rendering modaltity and other user settings.
<mth> Is text in nonselected (non active) folder tabs widgets?
<Greg> "The user can perform a search within rendered content (e.g. not
hidden with a style), including rendered text alternatives and rendered
alternative content, for any sequence of characters from the document
character set. (Level A)"
kf: so this gets really complicated.
<Greg> "The user can perform a search within rendered content (e.g. not
hidden with a style), including rendered text alternatives and rendered
alternative content, for any sequence of *printing* characters from the
document character set. (Level A)"
<Greg> "The user can perform a search within rendered content (e.g. not
hidden with a style), including rendered text alternatives and rendered
*generated* content, for any sequence of *printing* characters from the
document character set. (Level A)"
<mth> Okay, not hidden in settle. What about collapsed detail elements?
<kford> I don't thik collapsed items should show up in a find at level A.
<mth> C /settle/style/
<kford> I think all the hidden, and other variations should be in the level
aa.
gl: "hidden" is css 'hidden', collapsed content,
kf: if you can experience it without interaction then find should find it
on level A
<mth> I wonder about the details element. Behavior determined by ua I
think, not style. Could be advantageous to search complex pages containing
details without manually expanding each. See that as A.
kf: if you have to interact, click, expand, etc, mouse over, then search
should find and AA
<kford> In response to Mark, I don't think a user agent has to not do this
but requirment at level a doesn't have to be there.
<Greg> As above: "The user can perform a search within rendered content
(e.g. not hidden with a style), including rendered text alternatives and
rendered *generated* content, for any sequence of *printing* characters
from the document character set. (Level A)"
ja: kelly's interaction model covers Simon's concerns
kf: use this wording then beef up intent.
gl: printing characters - not including tab, newline non-breaking spaces
kf: printing characters is confusing
kelly: can live with greg wording
<Greg> Per Mark's comment, I think that having the ability t o expand all
of the DETAILS elements would be very useful, and would remove the need to
specifically address DETAILS in the Search SC.
+1
<Wayne> +1
kf: any objections?
<KimPatch> +1
wd: when you turn on text alternatives, do you have option to turn off in
the same session.
ja: yes, kelly - yes
<mth> +1
<Greg> +1
sh: +1
<scribe> *ACTION:* jeanne to add 2.4.1 "The user can perform a search
within rendered content (e.g. not hidden with a style), including rendered
text alternatives and rendered *generated* content, for any sequence of
*printing* characters from the document character set. (Level A) [recorded
in http://www.w3.org/2011/11/17-ua-minutes.html#action01]
<trackbot> Created ACTION-663 - Add 2.4.1 "The user can perform a search
within rendered content (e.g. not hidden with a style), including rendered
text alternatives and rendered *generated* content, for any sequence of
*printing* characters from the document character set. (Level A) [on Jeanne
F Spellman - due 2011-11-24].
<kford> *ACTION:* kford look at intent for 2.4.1 on find and ensure it
clearly states goal to allow the user to find whatever the user agent is
displaying e.g. covers the case where you have chosen alternatives.
[recorded in http://www.w3.org/2011/11/17-ua-minutes.html#action02]
<trackbot> Created ACTION-664 - Look at intent for 2.4.1 on find and ensure
it clearly states goal to allow the user to find whatever the user agent is
displaying e.g. covers the case where you have chosen alternatives. [on
Kelly Ford - due 2011-11-24].
<Greg> Kelly does not want to add an SC about expanding collapsed trees,
outlines, or details elements, nor does he want to search the hidden
portions in the basic search SC.
kp: should we have a wiki to capture these ideas.
kf: yes we should
... already have a wiki, just create a new page
<mth> Should I be the one to add the details issue to the wiki?
2.4.2 Find direction
http://www.w3.org/2002/09/wbs/36791/20111115/results#xq2
wiki page: uaag 3 http://www.w3.org/WAI/UA/work/wiki/Thoughts_for_UAAG_3
<Greg> Recommendation: 2.4.2 Find Direction: The user can search forward or
backward in rendered content. (Level A)
<Wayne> +1
+1
kp: +1
sh: +1
kf: objections?
<scribe> *ACTION:* jeanne to add 2.4.2 Find Direction: The user can search
forward or backward in rendered content. (Level A) to document [recorded in
http://www.w3.org/2011/11/17-ua-minutes.html#action03]
<trackbot> Created ACTION-665 - Add 2.4.2 Find Direction: The user can
search forward or backward in rendered content. (Level A) to document [on
Jeanne F Spellman - due 2011-11-24].
<mth> +1
2.4.3 Match Found
http://www.w3.org/2002/09/wbs/36791/20111115/results#xq3
wd: we don't have anything about what you can do when you find something
gl: don't want to be too prescriptive.
wd: acrobat - in reflow mode, find, takes you out of reflow, highlites
text, if back to reflow, then taken to where you were previously. find is
useless
gl: 2 proposed rewordings
2.4.3 Match Found: When a search operation produces a match, the matched
content is highlighted and presented within the visible area of the
viewport. The user can search from the location of the match. (Level A)
Or
2.4.3 Match Found: When a search operation produces a match, the matched
content is highlighted, the viewport is scrolled if necessary so that the
matched content is within its visible area, and the user can search from
the location of the match. (Level A)
kf: like second one better
ja: notification.
<Greg> The notification is that the match is highlighted and scrolled into
view, and the fact you don't get the "not found" message required by the
other SC.
<scribe> *ACTION:* jeanne to add 2.4.3 Match Found: When a search operation
produces a match, the matched content is highlighted, the viewport is
scrolled if necessary so that the matched content is within its visible
area, and the user can search from the location of the match. (Level A)
[recorded in http://www.w3.org/2011/11/17-ua-minutes.html#action04]
<trackbot> Created ACTION-666 - Add 2.4.3 Match Found: When a search
operation produces a match, the matched content is highlighted, the
viewport is scrolled if necessary so that the matched content is within its
visible area, and the user can search from the location of the match.
(Level A) [on Jeanne F Spellman - due 2011-11-24].
2.4.4 Alert on No Match
http://www.w3.org/2002/09/wbs/36791/20111115/results#xq4
<mth> Like the second one but concerned about audio browsers and the use of
"visible" area.
rewordings
2.4.4 Notification at End of Find: The user can be notified when a search
reaches the upper or lower extent of the search range, regardless of
whether the search will continue beyond that range or from the other
extent. (Level A)
2.4.4 The user is notified when there is no match and when starting the
search over from the beginning of content. (Level A)
discussion of wordings
wd: add 'in the direction of the search'
kp: what about wrapping. need to clear
... starting search over - from top of content
gl: starting search over - returning to the dialog box
kf: make simple. User is notified if no match
gl: no, because some will just wrap to the top without informing user, and
they get confused.
kp: if in middle of doc and search, assume searching from point of regard.
but search may find stuff above. confusing
<Wayne> The user is notified when the beginning or end of contend is
reached without finding a match.
kf: user is notified of no more or when continuing from begining or end of
content
... are we combining 2 things.
<Greg> The user *can be* notified when a search reaches the beginning or
end of the search range, regardless of whether the search will continue or
wrap.
first user notified when no match.
next search from top or bottom
<Greg> The user can be notified when a search reaches the beginning or end
of the content or selection, regardless of whether the search will continue
or wrap.
kf: alert on continuing searching
<Greg> 2.4.4 Notification at End of Find: The user can be notified when a
search reaches the beginning or end of the content or selection, regardless
of whether the search will continue or wrap.
<Greg> "Notification After Find"?
Notifications for Find
kf: we have Match Found, need Match Not Found
... Match Not Found: The user is notified when there is no match.
<KimPatch> Alert on no match and wrap: The user is notified when there is
no match. The user is notified when the search continues from the beginning
or end of content. (Level A)
<Greg> Here was mine again: 2.4.4 Notification at End of Find: The user can
be notified when a search reaches the beginning or end of the content or
selection, regardless of whether the search will continue or wrap.
ja: +1 to Kims wording
<Greg> 2.4.4 No Match: The user can be notified when a search reaches the
beginning or end of the content being searched, regardless of whether the
search will continue or wrap.
wd: how to we define search. in 2.4.2 is direction included. entire file,
or from current point down
... could add definition to .2.4.2
<mth> +1 to Kim's
user can define a search forward or backward to beginning or end of
document from current focus point.
wd: looking for word, in a direction, and an interval in the document
... need to introduce concept of interval or range. current point down
kp: getting complicated/ sometimes want to search till I find it, sometimes
only search in a directions.
... fine with eithers language.
kf: +1 to kim's wording
gl: is should be can be
... need word "search" in sc. Match does not imply search
kf: like kim's better
2.4.4 No Match: The user is notified when there is no match. The user is
notified when the search continues from the beginning or end of content.
2.4.4 Alert on Wrap or No Match: The user is notified when there is no
match. The user is notified when the search continues from the beginning or
end of content.
<Greg> The reason I don't want to say "is notified" is that I don't want to
forbid the user agent from providing a user option to turn off the
notification.
<Greg> But we want to make it clear that the choice is the user's, not the
user agent's.
<sharper> +1 for Kim
2.4.4 Alert on Wrap or No Match: The user can be notified when there is no
match. The user can be notified when the search continues from the
beginning or end of content.
<Wayne> Kim +1
<KimPatch> Alert on Wrap or No Match: The user the user can be notified
when there is no match. The user can be notified when the search continues
from the beginning or end of content. (Level A)
<Greg> "User can get notified" implies the user choice whereas "user can be
notified" could be read as user agent choice.
<scribe> *ACTION:* jeanne to add 2.4.4 Alert on Wrap or No Match: The user
can be notified when there is no match. The user can be notified when the
search continues from the beginning or end of content. [recorded in
http://www.w3.org/2011/11/17-ua-minutes.html#action05]
<trackbot> Created ACTION-667 - Add 2.4.4 Alert on Wrap or No Match: The
user can be notified when there is no match. The user can be notified when
the search continues from the beginning or end of content. [on Jeanne F
Spellman - due 2011-11-24].
<mth> The user has the option to receive notifications...
<Greg> Beginning or end of "content being searched" would be better than
just "content", covering cases where the search is not to the end of the
document (e.g. search within a section or selection).
Assign owners for SC needing attention
http://lists.w3.org/Archives/Public/w3c-wai-ua/2011OctDec/0071.html
kf: speak up if you want a particular item to write on
kp: mapping IOS gestures to a single page - Assistive Touch - a11y options
on iPhone
<kford> Article on assistive touch
http://pogue.blogs.nytimes.com/2011/11/10/apples-assistivetouch-helps-the-disabled-use-a-smartphone/
kf: it is exactly what we are talking about, remapping commands to a
different input method.
kp: make every thing work with single touch, and change shortcuts. user
defined gestures.
<mth> Does anyone know if apple has research evidence for design of
assistive touch?
UA mobile
http://www.w3.org/WAI/UA/work/wiki/Applying_UAAG_to_Mobile_Phones
W3 and WAI are wanting something from UAWG
kp: modality independent interface
<mth> Modality independence of core UAAG level A controls
UAWG in next 2 weeks clean up wiki to more fully express how UA does or
does not address mobile
kp: good exercise to use jim's example and see what applies
sh: we defined diffeent levels of UA, desktop, plugins, extensions, web
based. there should be some drop down to the OS level. we need to think
about this for levels of conformity. Platform, application, etc.
kf: concern is that there is a need for some guidance, if UAWG and others
do not provide others may just create
<mth> +1 to Kelly
wd: there are barriers
kf: need to explain the implications of not complying with UAAG
<kford> Mark, In answer to your question on assistive touch, I don't know.
<mth> For a mobile device can a great a11y user experience be created that
is not in compliance with UAAG?
kf: we have an action to add to document. If you have objections, get
support, write to list
<kford> Survey stopped at no match, pick up from there.
pick up at 2.4.5
kf: please look at SC list to review. Please review the proposals on the
list. Please review on Web Mobile wiki
all happy thanksgiving
<mth> Bye
[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, 17 November 2011 19:45:56 UTC