W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2014

Minutes: User Agent Telecon 6 Mar 2014

From: Jim Allan <jimallan@tsbvi.edu>
Date: Thu, 6 Mar 2014 13:34:54 -0600
Message-ID: <CA+=z1Wmg5my1GZNntnpL8xD5b=RW3Zu_5MwfFgZ32-Wkmpg=wg@mail.gmail.com>
To: WAI-ua <w3c-wai-ua@w3.org>
from: http://www.w3.org/2014/03/06-ua-minutes.html
User Agent Accessibility Guidelines Working Group Teleconference 06 Mar 2014

See also: IRC log  http://www.w3.org/2014/03/06-ua-irc
<http://www.w3.org/2014/03/06-ua-irc>
Attendees
PresentJim_Allan, Greg_Lowney, Jan, Kim_Patch, KellyRegretsjeanneChairJimAllan,
KellyFordScribeallanj
Contents

   - Topics <http://www.w3.org/2014/03/06-ua-minutes.html#agenda>
      1. OP06 "important
elements"<http://www.w3.org/2014/03/06-ua-minutes.html#item01>
      2. MS03 1.4.1 Separation between browsers and
OS<http://www.w3.org/2014/03/06-ua-minutes.html#item02>
   - Summary of Action
Items<http://www.w3.org/2014/03/06-ua-minutes.html#ActionSummary>

------------------------------

<trackbot> Date: 06 March 2014

http://www.w3.org/WAI/UA/2014/LCcomments.html
OP06 "important elements"

<scribe> scribe: allanj

Guideline 2.3 "important elements" Since important elements have been left
at the discretion of the user (and will vary from user to user, and from
web page to web page) ... It will be quite the task for the user agent to
determine from the user which elements he/she thinks is important and have
the proper facilities to navigate directly to it. Can make the criteria of
'important elements'...

scribe: more objective or easily definable?

jr: we meant to leave it to the UA developer as to the definition of
"important elements"

gl: Glossary: important elements are up to the UA

<Greg> Definition of important elements

<Greg> Elements determined as important by the user to facilitate the
user's navigation of the content. UAAG 2.0 intentionally does not identify
which important elements must be navigable because this will vary by user
needs and technologies being used.

<Greg> 2.5.3 Allow Elements to be Configured for Structural Navigation: The
user can configure a set of important elements (including element type) for
structured navigation and hierarchical/outline view. (Level AAA)

<Jan> important elements: Elements determined as important for users by the
user agent to facilitate the user's navigation of the content. UAAG 2.0
intentionally does not identify which important elements must be navigable
because this will vary by user needs and technologies being used.

<Greg> The definition says the user defines the set of important elements,
but the SC saying the ability to define set is only AAA.

gl: 2.3.1 navigate to important elements (AA), but not defined by user
(2.5.3 AAA)

<Jan> important elements: Elements determined as important for users by the
user agent to facilitate the user's navigation of the content. UAAG 2.0
intentionally does not identify which important elements must be navigable
because this will vary depending on the web technology.

gl: html does not define 'important elements'

<Jan> important elements: Elements determined as important for users by the
user agent to facilitate the user's navigation of the content. UAAG 2.0
intentionally does not identify which important elements must be navigable
because this will vary depending on the user agent design and the web
technology.

<Greg> Editorial rewrite of Jan's: "Elements that the user agent identifies
as important for facilitating the user's navigation of the content."

<kford> Rewrite is good to me.

<Jan> important elements: Elements that the user agent identifies as
important for facilitating the user's navigation of the content. UAAG 2.0
intentionally does not identify which important elements must be navigable
because this will vary depending on the user agent design and the web
technology.

ja: 2.5.3 allows user to choose any element

jr: no...choose from the important element list provided by the UA

ja: thats not clear in the SC

gl: could add to the intent
... to comply with 2.3.1 the UA provides the user the ability to navigate
by at least one element (h1)

ja: suggest removing 2.5.3 because no one will do it.

gl: hopes mouseless browsing would add heading nav in addition to link
navigation.

jr: wonders if with heading and table navigation (2.5.2) and enabled
elements (2.3.3) thinks we have important elements covered.
... perhaps can eliminate 2.3.1 (it is so basic, UA could provide 1 choice)
and 2.5.3

kp: OK with removing 2.3.1.

gl: 1.9.1 outline view of important elements.

jr: allowing users to choose which elements could get difficult for the UA

kp: want to keep 2.5.3.

jr: what is the work 2.5.3 is doing.
... want something in the notes for 1.9.1 that outline views are more
usable when they are configurable.

gl: 2.3.1 is redundant to 2.3.3 and 2.5.2
... what else might 2.3.1 used for... what elements?

jr: 2.3.3 is navigate to and activate - separate actions for enabled
elements
... 2.5.2 is nav by headings and tables, 1.9.1 is outline view of important
elements

kf: this is a bit confusing.
... end goal direct nav and activate enabled elements

kp: need to nav to and nav + activate in one step

kf: want default behavior of whatever UA does.

kp: the user doesn't know what the UA will do when something gets focus.
... mouseless browsing is nav+activate

kf: tabbing gives focus with out activation.

<scribe> *ACTION:* Jan with create a proposal for 1.9.1, 2.3.1, 2.3.3,
2.5.2, 2.5.3 with definition for 'important elements" [recorded in
http://www.w3.org/2014/03/06-ua-minutes.html#action01]

<trackbot> Created ACTION-956 - With create a proposal for 1.9.1, 2.3.1,
2.3.3, 2.5.2, 2.5.3 with definition for 'important elements" [on Jan
Richards - due 2014-03-13].

gl: Word is a UA that allow granular navigation move forward 3 graphics, or
up 2 sections, etc. so it is possible to do this type of navigation

close item 1

open item 2

2.3.2 Present Direct Commands from Rendered Content: The user can have any
recognized direct commands in rendered content (e.g. accesskey, landmark)
be presented with their associated elements (e.g. Alt+R to reply to a web
email). (Level AA)

comment: based on intent of 2.3.2 However, if we are to have proper
documentation of the accessibility functionality (Guideline 3.3) then,
presumably, there it will be made discoverable. Users will just need to go
through the documentation to discover all relevant controls.

ja: this is a misunderstanding, we are talking about Rendered content, not
UI content

The UA can not have documentation for Author supplied Direct Commands
(accesskey)

<scribe> *ACTION:* Jeanne to add response to OP07 - his is a
misunderstanding, we are talking about Rendered content, not UI content.
The UA can not have documentation for Author supplied Direct Commands
(accesskey) [amith as necessary] [recorded in
http://www.w3.org/2014/03/06-ua-minutes.html#action02]

<trackbot> Created ACTION-957 - Add response to op07 - his is a
misunderstanding, we are talking about rendered content, not ui content.
the ua can not have documentation for author supplied direct commands
(accesskey) [amith as necessary] [on Jeanne F Spellman - due 2014-03-13].
MS03 1.4.1 Separation between browsers and OS

comment: While it is understood that the separation between browsers
features and OS features can be blurry at times, there are functions that
are generally expected to be provided by the OS to facilitate
accessibility. We do not expect the working group to delineate the
responsibility of OS and browsers since it is contextual and fluid. But we
expect the working group to recognize such...
... separation of responsibility. For example, success criterion 1.4.1
(Text Scale, Color, Font) should be separated into two criteria--one simply
asking the browsers to follow the OS text size and such at level A and
another to provide its own options if the OS fails to provide text options
at level AA.

<Greg> The general statement is too vague to be actionable. That is, I
don't expect any disagreement on the sentiment, but rather on the details.
I disagree with this example provided: if a browser does not provide
adjustable font sizes, it is neither fully accessible nor as accessible as
users have come to expect. If the operating system does not provide the
features in any standardized way, it is...

<Greg> ...up to each application to provide them on its own, and if the
feature is useful and common enough to be expected, whether it is provided
in a consistent way or not is less important.

jr: aren't you agreeing with them. current situation. mobile allow setting
text size and color, most UAs allow font size change
... but, don't agree with creating 2 SCs

gl: UA allow following OS font and colors, or let user do their own.
... this should still be level A.

<Greg> That is, if a feature such as customizable colors is important
(which it is), the browser can be expected to provide it at Level A
regardless of whether or not it's implement at the OS level.

ja: all browsers already do this. it is up to the UA to decide to do it on
its own or use the OS

<Greg> The feature should not be relegated to Level AA just because the OS
did not provide a standardized implementation.

<Greg> If there are specific success criteria that you feel should be split
into separate levels for when the OS supports it and when it doesn't,
please enumerate these and we will try to address your concerns.

<Greg> Do we have both "follow OS colors" and "allow user to the override
them"?

<Jan> 5.1.3 Implement Accessibility Features of the Platform:

<Jan> If the user agent contains non-web-based user interfaces, then those
user interfaces follow user interface accessibility guidelines for the
platform. (Level A)

<Jan> Note: When a requirement of another specification contradicts a
requirement of UAAG 2.0, the user agent may disregard the rendering
requirement of the other specification and still satisfy this guideline.

ja: font size and color is an accessibility setting

jr: thats where you find it on android OS

Applicability note: if the OS provides the features the UA does not need to
duplicate as long as the features trickle through

<KimPatch> Suggested edit:

<KimPatch> Applicability note: if the OS provides a feature the UA does not
need to duplicate it as long as user agent supports the OS feature

<Greg> We could have an SC that explicitly said something like "For the
following presentation attributes, the user can choose which of the
following take precedence (a) user global settings specified by the
platform, or (b) author-specified settings, or (c) user-specified settings.
* Foreground and background colors..."

<Greg> That is reflecting the features already in desktop browsers (e.g.
Firefox).

jr: on mobile, platform does foreground/background (inverse color), the
applications cannot over ride
... windows phone has high contrast mode, ie for mobile will use HCM
... windows could add a user setting to ignore HCM in the UA, but expect
they would say turn off HCM.
... applicability notes are the loopholes and SC are the you musts

Applicability note: if the OS provides a feature the UA does not need to
duplicate it as long as user agent supports the OS feature

gl: conformance claim you list the OS, UA, and extensions...that's not
clear enough

jr: but MS make comment that its not clear, hence applicability note

gl: feature needs to be available regardless of the location of the feature
OS, UA, or extension and are enumerated in the conformance claim
... mean to say platform (many layers within the platform)

<Greg> A required behavior can be provided by the platform, user agent,
extensions, and potentially other layers. All are acceptable, as long as
they are enumerated in the conformance claim.

<Greg> The user agent does not need to implement every behavior itself. A
required behavior may be provided by the platform, user agent, user agent
extensions, or potentially other layers. All are acceptable, as long as
they are enumerated in the conformance claim.

<Jan> GL's wording works for me.

any objections to adding this as #6 in conformance applicability notes

+1

kp: +1

gl: +1

kelly: ?

<scribe> *ACTION:* jeanne to add "6. The user agent does not need to
implement every behavior itself. A required behavior may be provided by the
platform, user agent, user agent extensions, or potentially other layers.
All are acceptable, as long as they are enumerated in the conformance
claim." to applicability notes. [recorded in
http://www.w3.org/2014/03/06-ua-minutes.html#action03]

<trackbot> Created ACTION-958 - Add "6. the user agent does not need to
implement every behavior itself. a required behavior may be provided by the
platform, user agent, user agent extensions, or potentially other layers.
all are acceptable, as long as they are enumerated in the conformance
claim." to applicability notes. [on Jeanne F Spellman - due 2014-03-13].

<scribe> *ACTION:* jeanne add to disposition document - that we added "6.
The user agent does not need to implement every behavior itself. A required
behavior may be provided by the platform, user agent, user agent
extensions, or potentially other layers. All are acceptable, as long as
they are enumerated in the conformance claim." to document as a response to
comment MS03 [recorded in
http://www.w3.org/2014/03/06-ua-minutes.html#action04]

<trackbot> Created ACTION-959 - Add to disposition document - that we added
"6. the user agent does not need to implement every behavior itself. a
required behavior may be provided by the platform, user agent, user agent
extensions, or potentially other layers. all are acceptable, as long as
they are enumerated in the conformance claim." to document as a response to
comment ms03 [on Jeanne F Spellman - due 2014-03-13].
 Summary of Action Items *[NEW]* *ACTION:* Jan with create a proposal for
1.9.1, 2.3.1, 2.3.3, 2.5.2, 2.5.3 with definition for 'important elements"
[recorded in http://www.w3.org/2014/03/06-ua-minutes.html#action01]
*[NEW]* *ACTION:* jeanne add to disposition document - that we added "6.
The user agent does not need to implement every behavior itself. A required
behavior may be provided by the platform, user agent, user agent
extensions, or potentially other layers. All are acceptable, as long as
they are enumerated in the conformance claim." to document as a response to
comment MS03 [recorded in
http://www.w3.org/2014/03/06-ua-minutes.html#action04]
*[NEW]* *ACTION:* jeanne to add "6. The user agent does not need to
implement every behavior itself. A required behavior may be provided by the
platform, user agent, user agent extensions, or potentially other layers.
All are acceptable, as long as they are enumerated in the conformance
claim." to applicability notes. [recorded in
http://www.w3.org/2014/03/06-ua-minutes.html#action03]
*[NEW]* *ACTION:* Jeanne to add response to OP07 - his is a
misunderstanding, we are talking about Rendered content, not UI content.
The UA can not have documentation for Author supplied Direct Commands
(accesskey) [amith as necessary] [recorded in
http://www.w3.org/2014/03/06-ua-minutes.html#action02]

[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, 6 March 2014 19:35:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:45 UTC