See also: IRC log
<trackbot> Date: 17 November 2011
<scribe> scribe: jallan
<kford> Survey results:
<kford> http://www.w3.org/2002/09/wbs/36791/20111115/results
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?
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
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].
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).
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?
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
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: jallan Inferring ScribeNick: JAllan Present: kim jim kelly wayne simon greg Mark (IRC) Regrets: Jan Jeanne Found Date: 17 Nov 2011 Guessing minutes URL: http://www.w3.org/2011/11/17-ua-minutes.html People with action items: jeanne kford[End of scribe.perl diagnostic output]