See also: IRC log
<trackbot> Date: 07 April 2011
<scribe> new editors draft 6 April link from home page
UA Wiki http://www.w3.org/WAI/UA/work/wiki/
GL 2.7 in the Wiki http://www.w3.org/WAI/UA/work/wiki/Guideline_2.7
<jeanne> http://www.w3.org/WAI/UA/2011/ED-UAAG20-20110406/
<jeanne> new Editors' Draft -- http://www.w3.org/WAI/UA/2011/ED-UAAG20-20110406/
<mhakkinen> irc for now.
quick update on Focus from Greg and Kim
propose half day meeting
start at regular time and meet later,
any conflicts on 28th
<jeanne> 12-4 Boston, 11-3 Central, 9-1 Pacific, 5-9 UK
convention for wiki: >>name, date: some comment
<Greg> <<Greg 2011-04-07: This is a sample comment.>>
topic 2.7.1 Discover navigation and activation keystrokes
gl: also working on focus, related to 2.7
<Greg> 2.3.3 Present Direct Commands in Rendered Content [former 2.1.6, before that 4.1.6, also 2.7.1, minor change] (Level A)
<Greg> [The only change to 2.1.6 was taking out the inline examples, which were already in the list of bulleted examples. 2.1.6 and 2.7.1 were highly overlapping: 2.1.6 was "2.1.6 (former 4.1.6) Present Direct Commands in Rendered Content: The user can have any recognized direct commands (e.g. accesskey) in rendered content be presented with their associated elements (e.g. "[Ctrl+t]" displayed...
<Greg> ...after a link whose accesskey value is "t", or an audio browser reading the value or label of a form control followed by "accesskey control plus t"). (Level A) ", while 2.7.1 was "2.7.1 (former 4.7.7) Discover navigation and activation keystrokes: Direct navigation and activation keystrokes are discoverable both programmatically and via perceivable labels. (Level A)". The part of 2.7.1...
<Greg> ...about programmatically belongs under Principle 4 Programmatic Access, not here.]
<Greg> The user can have any recognized direct commands (e.g. accesskey) in rendered content be presented with their associated elements (Level A)
<Greg> Intent of Success Criterion 2.1.6 (former 4.1.6):
<Greg> • Make it easy to for users to discover or be reminded of keyboard shortcuts and similar commands without leaving the context in which they're working. Easy keyboard access is especially important for people who cannot easily use a mouse.
<Greg> Examples of Success Criterion 2.1.6 (former 4.1.6):
<Greg> • "[Ctrl+t]" displayed after a link whose accesskey value is "t".
<Greg> • An audio browser reading the value or label of a form control followed by "accesskey control plus t").
<Greg> • Mnemonic letters in menu titles are shown with an underline. @@ Editors' Note: comment - applicable shortcut indicated or otherwise highlighted@@
<Greg> Related Resources for Success Criterion 2.1.6 (former 4.1.6):
<Greg> • To be written
<Greg> The actual SC buried in all that was:
<Greg> 2.3.3 Present Direct Commands in Rendered Content: The user can have any recognized direct commands (e.g. accesskey) in rendered content be presented with their associated elements (Level A)
jr: agree that 2.7.1 should be merged with 2.1.6
gl: we kept 2.17
<scribe> ACTION: GregL to write a proposal for merging 2.7.1 and 2.1.6 [recorded in http://www.w3.org/2011/04/07-ua-minutes.html#action01]
<trackbot> Sorry, couldn't find user - GregL
<scribe> ACTION: Greg to write a proposal for merging 2.7.1 and 2.1.6 [recorded in http://www.w3.org/2011/04/07-ua-minutes.html#action02]
<trackbot> Created ACTION-520 - Write a proposal for merging 2.7.1 and 2.1.6 [on Greg Lowney - due 2011-04-14].
jr: what is explicitly define relationship, html table headers seem implicit
sh: <th> seems to be explict
jr: when there are label type relationships.
with html5 and ARIA there are more explicit relationships
gl: example of explicit defined
relationships we don't want exposed
... text insertion point in text with header pages above
<scribe> scribe: jallan
<Greg> That is, can we come up with examples of explicitly defined relationships that we expect the user agent to expose somehow (in order to comply with this SC) and others that we don't intend to require?
<Greg> Examples of explicit relationships would include Labels, also headings that in a sense label all the content below them, page titles...?
<Greg> Between a link and its destination?
we are looking at 'id', child elements, others
gl: what does 'access' mean...is it expose/view or navigate
<Greg> "Access" explicitly-defined relationships doesn't make clear whether this means the user agent is required to let users view those relationships, or navigate by them, or both. (from survey)
jr: label is expicit, table header need to be exposed
gl: so if table headers are not
hidden or moved off screen, does that comply?
... screen could make headers available to user
sh: screen magnifier users may need it.
gl: user interface you envision, some keyboard command would popup a dialog box that gives the relationships to the user
sh: want some cognitive meaning from the relationship.
gl: relationship is the context of the content
<Greg> So, Simon interpreted the SC as essentially that the user agent provides a keyboard command that presents the label of the element that has the keyboard focus. Correct?
<Greg> Labeling interpreted broadly, including elements with the LabeledBy relationship, table column and row headings, etc.
gl: table headers are explicit and implicit.
ja: brings up 'headers' and 'id' for table
gl: is explicit the same as programatically determinable
<Greg> I hear general agreement that the SC is unclear as currently written, and needs to be reworked to clarify and narrow its meaning.
mh: good case for explicit exposing the relationship to the user
gl: several issues
... need to rewrite SC to make it clearer
... presentation vs navigation to relationship
... explicit - need a different term,
... could use 'recognized' or 'recognizable' in place of
explicitly defined
<Greg> So to sum up issues with the SC's current wording, we need to rephrase to (a) clear up whether it's making information perceivable vs. navigating based on it, (b) the term "explicit" could be replaced by "recognized" as we do throughout the rest of the document, (c) ...?
<Greg> (c) which types of relationships are we requiring, because documents like HTML define many, many relationships.
it seems we are talking about exposing the information to the user. the UA takes care of the navigation
<Greg> "The user can have presented to them contextual information about an element, including recognized labels" ?
<Greg> (I was going to say the element with the keyboard focus, but Simon's example of getting information by hovering makes it clear it should be broader.)
<Greg> "The user can have presented to them contextual information about an element, including recognized labels and descriptions."
<Greg> "The user can have presented to them contextual information about an element, including recognized labels, descriptions, and alternative content."
mh: could be aria-describedby or longdesc
<Greg> "The user can have contextual information about an element presented to them, including recognized labels, descriptions, and alternative content."
ja: lose the clause.
<Greg> If we were to take out the list of minimum required info ("recognized labels, descriptions, and alternative content") would we be leaving it open for a user agent to claim compliance with a pretty useless implementation, that just gave something like the line number of the element in the source code?
<Greg> I think if there's a minimum set, we should explicitly list them.
<mhakkinen> +1 to including ...
<Greg> "The user can have recognized contextual information about an element presented to them, including labels, descriptions, and alternative content."
<Greg> What about headings, as in "The user can have contextual information about an element presented to them, including recognized labels, descriptions, headings, and alternative content."
gl: use 'headings map' extension to keep track of where I am in a document
<Greg> "The user can have contextual information about an element presented to them, including recognized labels, descriptions, headings, and alternative content."
<Greg> Title of "Present context information?"
Intent
HTML controls and elements are sometimes grouped together to make up a composite control; certain elements relate to others in a recognizable manned. This is the case with Ajax widgets and with form elements. By making sure the user can be informed about these relationships means that, say, visually disabled users can better understand these relationships even if the elements are not...
scribe: adjacent on the screen or the DOM.
<Greg> Present relationships and context?
<Greg> This belongs under Principle 1 Perceivable.
HTML controls and elements are sometimes grouped together to make up a composite control; certain elements relate to others in a recognizable manner, such as realtionships with 'id' attributes and child elements.d.
<Greg> Gerald is navigating through a lengthy, complex table. He invokes a "Show element properties" command from the element's context menu, which displays a pop-up box giving the current cell's row and column headings, its row and column numbers, and the headings that provide its context in the document.
kp: anything that saves steps and provides context, making navigation easier helps
<Greg> (I once wrote a set of Word macros to do this, as requested by a blind coworker, but I suspect screen readers may routinely do this today. Still, it could be quite useful for users of screen enlargers and others.)
<jeanne> John has low vision and uses a screen magnifier to access his Browser. John is navigating through a lengthy, complex table. He invokes a "Show element properties" command from the element's context menu, which displays a pop-up box giving the current cell's row and column headings, its row and column numbers, and the headings that provide its context in the document.
HTML controls and elements are sometimes grouped together to make up a composite control; certain elements relate to others in a recognizable manner, such as relationships with 'id' attributes and child elements. This is the case with Ajax widgets and with form elements. By making sure the user can be informed about these relationships means that, say, visually disabled users can better...
scribe: understand these relationships even if the elements are not adjacent on the screen or the DOM.
<Greg> Suggest changing Guideline 1.11 Provide link information, to be Guideline 1.11 Provide element information, and add this one to it.
<Greg> It would then have two success criteria, 1.11.1 Present Link Information, and 1.11.2 Present relationships and context.
In a long document, having the nearest previous heading revealed would help users, who have some cognitive issues, orient to the document
<Greg> For the intent, could start with "Some users have difficulty perceiving, remembering, or understand the relationships between elements and their contexts."
Some users have difficulty perceiving, remembering, or understand the relationships between elements and their contexts. HTML controls and elements are sometimes grouped together to make up a composite control; certain elements relate to others in a recognizable manner, such as relationships with 'id' attributes and child elements. This is the case with Ajax widgets and with form elements....
scribe: By making sure the user can be informed about these relationships means that, say, visually disabled users can better understand these relationships even if the elements are not adjacent on the screen or the DOM.
<jeanne> ACTION: jeanne to update document to move 2.7.2 to 1.11.2 using the text in the wiki. [recorded in http://www.w3.org/2011/04/07-ua-minutes.html#action03]
<trackbot> Created ACTION-521 - Update document to move 2.7.2 to 1.11.2 using the text in the wiki. [on Jeanne F Spellman - due 2011-04-14].
<jeanne> ACTION: jeanne to update document changing the text of Guideline 1.11 as stated in wiki. [recorded in http://www.w3.org/2011/04/07-ua-minutes.html#action04]
<trackbot> Created ACTION-522 - Update document changing the text of Guideline 1.11 as stated in wiki. [on Jeanne F Spellman - due 2011-04-14].
<Greg> Tools for converting to and from Wikimedia format: https://secure.wikimedia.org/wikipedia/en/wiki/Wikipedia:Tools/Editing_tools#From_Microsoft_Word_or_OpenOffice
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/I'm on a quick call with Judy, I'll be back shortly. // Succeeded: s/loose/lose/ Found Scribe: jallan Inferring ScribeNick: JAllan Default Present: Jim, +1.425.895.aaaa, Greg, Jan, +1.617.325.aabb, Jeanne, sharper, KimPatch, Mark_Hakkinen Present: Greg Kim Jeanne Simon Jim Mark Jan WARNING: Replacing previous Regrets list. (Old list: KFord) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ kelly Regrets: kelly Found Date: 07 Apr 2011 Guessing minutes URL: http://www.w3.org/2011/04/07-ua-minutes.html People with action items: greg gregl jeanne[End of scribe.perl diagnostic output]