Minutes 06 Dec 2012 - User Agent Accessibility Guidelines Working Group Teleconference

W3C
- DRAFT -
User Agent Accessibility Guidelines Working Group Teleconference
06 Dec 2012

IRC log  - http://www.w3.org/2012/12/06-ua-irc
HTML log - http://www.w3.org/2012/12/06-ua-minutes.html


[NEW] ACTION: Jeanne to update document with new SC for 2.8.1 and
examples from Kim's proposals emails of 4 December
http://lists.w3.org/Archives/Public/w3c-wai-ua/2012OctDec/0042.html
[recorded in http://www.w3.org/2012/12/06-ua-minutes.html#action01]

Attendees
Present
    Jeanne, Greg_Lowney, Jim_Allan, Jan, sharper, Kim_Patch, +1.425.883.aaaa
Regrets
Chair
    JimAllan, KellyFord
Scribe
    Harper_Simon

Contents

    Topics
        wrapping up levels
        Scheduling a F2F
        Getting to Last Call -
        Explanation of Levels
    Summary of Action Items

<trackbot> Date: 06 December 2012

<JAllan> Conformance, definition of Levels, Action Items (nothing after
2012) all must be completed by Dec 20, clean up @@

<jeanne> http://www.w3.org/WAI/UA/2012/ED-UAAG20-20121206/

sorry

audio problems

<JAllan> So we at the W3C WAI Research and Development Working Group have

<JAllan> conducted a mobile symposium which is now moving to a W3C Note.
As part

<JAllan> of this we have a section for a Road Map of Future Mobile
Accessibility.

<JAllan> We would like to invite you all to contribute to our
discussions on just

<JAllan> what the Road Map is / should be; which we have arranged for
14:30 GMT

<JAllan> on 12th December 2012 for 1 hour.

<scribe> scribe: Harper_Simon

<scribe> ScribeNick: sharper
wrapping up levels

JA: Reprising rationale for levels discussion. Orig goal to reduce the
number of level A criteria - ended up increasing.
... Now time to move on - trying to make a perfect document 'perfect is
the enemy of the good' [I love that quote!]
... Idea to go to Last Call in Jan - but now we need to extend to match
reality and not aspiration.

JR: How far did we get through...

JA: to 2.3.4...

JR: not looked through others to see if I have any concerns - makes
sense to wrap this up - but i'll whiz through myself and check I'm happy

JA: please all read - any issues send to the list

RESOLUTION: Move on - any queries to the list
Scheduling a F2F

JA: Could we deal with comments in a F2F at CSUN or SSW

<JAllan> SXSW March 8-12 2012

JR: I'd like SXSW

KF: Approval to go to CSUN

JA: any opinions on F2F Venue?

<JAllan> what about Web4All conference in Rio at the beginning of May

General discussion re venues

RESOLUTION: Will keep discussing venues.
Getting to Last Call -

JA: what do we have to have done.

JS: last call is our way of saying we think the document is done. An
opportunity for people to discuss patents etc
... all other steps are about public comments and feedback.

JA: dont have to have test suites done?

JS: We start writing test suite at last call - then go to candidate
recommendation

GL: are we supposed to be confident that there are implementations for
everything?

JS: we say done, then comments, the candidate rec, call for test
implementations and that they work
... have to have 2 implementations per SC, and therefore have a test suite
... the proposed rec, then rec.
... we don't worry much about Prop Rec
... before CR we need to have a good idea of implementations - we can
declare SCs at risk if unsure - then we can remove items if imps don't
exist means they can be removed without a time penalty.

KP: seeing apps implemented that have things that fulfil SCs - would be
great to have a wiki to start to pile examples on.

GL: we have one on the wiki now

KP: makes it easier to add this now - explosion of useful stuff in terms
of mobile

JA: wiki off our home page
... and questions?
... deal with any outstanding @@ in doc
... review doc - have most IERs done - 2 left
... these are via JR proposals - new 2.3.x and 2.8.1 created another 2.8
<- KP wrote examples
... additional don't have intents

KP: new intent is there for 2.8.1 - talking about it last time

JA: flag this on foresnics

JS: to flag this for Tuesday
... these aren't the new ones - clarification is occuring

KP: elaborates

>From Minutes from the 15th

<KimPatch> New SC:

<KimPatch> 2.8.1 Customize display of controls representing user
interface commands,

<KimPatch> functions, and extensions: The user can customize which user
agent

<KimPatch> commands, functions, and extensions are displayed within the
user agent's

<KimPatch> user interface as follows: (AA)

<KimPatch> (a) Show: The user can choose to display any controls, which
can include

<KimPatch> user installed extensions, available within the user agent
user interface.

<KimPatch> It is acceptable to limit the total number of controls that
are displayed

<KimPatch> onscreen.

<KimPatch> (b) Simplify: The user can simplify the default user
interface by choosing

<KimPatch> to display only commands essential for basic operation (e.g.
by hiding

<KimPatch> some control).

<KimPatch> (c) Reposition: The user can choose to reposition individual
controls

<KimPatch> within containers (e.g. Toolbars or tool palettes), as well
as reposition

<KimPatch> the containers themselves to facilitate physical access (e.g.
To minimize

<KimPatch> hand travel on touch screens, or to facilitate preferred hand
access on

<KimPatch> handheld mobile devices).

<KimPatch> (d) Assign Activation Keystrokes or Gestures: The user can
choose to view,

<KimPatch> assign or change default keystrokes or gestures used to
activate controls.

<KimPatch> (e) Reset: The user has the option to reset the containers
and controls

<Greg> Mark's email is at
http://lists.w3.org/Archives/Public/w3c-wai-ua/2012OctDec/0035.html

<KimPatch> available to their original configuration.

JA: Action Items need doing

<jeanne> ACTION: Jeanne to update document with new SC for 2.8.1 and
examples from Kim's proposals emails of 4 December
http://lists.w3.org/Archives/Public/w3c-wai-ua/2012OctDec/0042.html
[recorded in http://www.w3.org/2012/12/06-ua-minutes.html#action01]

<trackbot> Created ACTION-779 - Update document with new SC for 2.8.1
and examples from Kim's proposals emails of 4 December
http://lists.w3.org/Archives/Public/w3c-wai-ua/2012OctDec/0042.html [on
Jeanne F Spellman - due 2012-12-13].

RESOLUTION: the 2 IERs will be done in forensics

JA: will bash Action items after 2011
... 17 open
... can we all review and close

<JAllan> open actions - http://www.w3.org/WAI/UA/tracker/actions/open

RESOLUTION: All close actions at
http://www.w3.org/WAI/UA/tracker/actions/open?sort=due

<JAllan> http://www.w3.org/WAI/UA/work/wiki/Main_Page

JA-JS: need to finish conformance section, and the explaination of the
levels
Explanation of Levels

<jeanne> The UAAG 2.0 levels are designed to complement the levels of
WCAG 2.0, A, AA, and AAA, where Level A provides remedies to the most
severe accessibility problems for people with disabilities, and
therefore is the highest priority for user agent developers.

<jeanne> These levels are designed to allow companies to get the most
out of developer hours by addressing the low hanging fruit first: Level
A addresses serious user problems that draw a reasonable amount of

<jeanne> developer time. Level AA addresses user problems that improve
the experience of people with disabilities and may take more developer
time to implement. Level AAA is reserved for user problems that may be
more specialized or are challenging to implement.

<jeanne> If a user finds 10 different actions he performs frequently
cognitively

<jeanne> difficult, physically difficult or very time-consuming, he may be

<jeanne> overwhelmed. However, if eight of those actions require a
reasonable

<jeanne> amount of developer time for corporations to enable in a better
way,

<jeanne> fixing those eight may allow the user to handle the extra
difficulty on

<jeanne> the other two. This is not ideal, but it is practical.

<jeanne> At the same time, if a company has a policy to dedicate a
percentage of developer time to accessibility and this is not enough
time to address everything, it is practical to complete as much as
possible before the and work on some longer-term items iteratively to
further improve the accessibility of the browser over time.

<jeanne> Level A Success criteria address accessibility problems that
block people

<jeanne> with disabilities from interacting with the interface or
content and are

<jeanne> technically feasible for the vendor to implement

<jeanne> Level AA success criteria provide accessibility solutions to
people with

<jeanne> diverse disabilities and are feasible to implement.

<jeanne> Level AAA success criteria address accessibility for specific
groups of

<jeanne> people with disabilities and are challenging to implement.

http://en.wikipedia.org/wiki/MoSCoW_Method

General discussions on the explanation

discussion around terms 'ubiquitous' and 'block' - and time taken is
also a block

<jeanne> Level A Success criteria address accessibility problems that
block people with disabilities from interacting with the interface or
content; and are technically feasible for the vendor to implement; or
are sufficiently common that they are ubiquitous and expected.

I like that one Jeanne!

<Greg> Level A Success criteria are technically feasible for the vendor
to implement, and either (a) address accessibility problems that block
people with disabilities from interacting with the interface or content,
or (b) address accessibility problems and the solutions are sufficiently
common that they are ubiquitous and expected.

<Greg> Level A Success criteria are technically feasible for the vendor
to implement, and either (a) address accessibility problems that block
people with disabilities from interacting with the interface or content,
or (b) address accessibility problems and the solutions are either
sufficiently common that they are ubiquitous and expected or trivially
easy to implement.

<Greg> Per Jeanne's suggestion to take out "trivially":

<Greg> Level A Success criteria are technically feasible for the vendor
to implement, and either (a) address accessibility problems that block
people with disabilities from interacting with the interface or content,
or (b) address accessibility problems and the solutions are either
sufficiently common that they are ubiquitous and expected or easy to
implement.

<Greg> Level A Success criteria are technically feasible for the vendor
to implement, and either (a) address accessibility problems that block
people with disabilities from interacting with the interface or content,
or (b) address accessibility problems and the solutions are either
sufficiently common that they are ubiquitous and expected, or easy to
implement.

<Greg> (That's with comma inserted before final "or")

<KimPatch> Level A Success criteria are technically feasible for the
vendor to implement, and either (a) address accessibility problems that
block people with disabilities from interacting with the interface or
content, or (b) address accessibility problems and the solutions are
either sufficiently common that they are ubiquitous and expected or are
easy to implement.

<Greg> Level A is expected to be feasible *in all cases*, whereas Level
AA and AAA may not be feasible in all cases.

<Greg> Feasible is not the same as possible; if something can be done
but would be prohibitively expensive, it is possible but not feasible.

<Greg> We expect every user agent to achieve Level A conformance, and
believe most user agents should be able to achieve Level AA and
encourage them to do so. Level AAA success criteria are often going
beyond expectations, but should be considered during the design process.

RESOLUTION: JA to place create the text taking these variations into
account.
Summary of Action Items
[NEW] ACTION: Jeanne to update document with new SC for 2.8.1 and
examples from Kim's proposals emails of 4 December
http://lists.w3.org/Archives/Public/w3c-wai-ua/2012OctDec/0042.html
[recorded in http://www.w3.org/2012/12/06-ua-minutes.html#action01]
 
[End of minutes]

Received on Thursday, 6 December 2012 19:35:27 UTC