Minutes: 07 Apr 2011 UAWG telecon

from http://www.w3.org/2011/04/07-ua-minutes.html
User Agent Accessibility Guidelines Working Group Teleconference
07 Apr 2011

See also: IRC log http://www.w3.org/2011/04/07-ua-irc
Attendees

Present
    Greg, Kim, Jeanne, Simon, Jim, Mark, Jan
Regrets
    kelly
Chair
    JimAllan
Scribe
    jallan

Contents

    Topics
        Survey http://www.w3.org/2002/09/wbs/36791/20110405/results
        2.7.2 Access Relationships
    Summary of Action Items

<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.>>
Survey http://www.w3.org/2002/09/wbs/36791/20110405/results

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].
2.7.2 Access Relationships

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
Summary of Action Items
[NEW] 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]
[NEW] 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]
[NEW] 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]
[NEW] 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]

[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, 7 April 2011 18:52:40 UTC