- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Thu, 12 Jul 2012 11:21:14 -0500
- To: faulkner.steve@gmail.com
- Cc: public-html@w3.org, public-html-a11y@w3.org
- Message-ID: <OF6684890B.58DA6EDB-ON86257A39.005893B6-86257A39.0059D5FA@us.ibm.com>
Steve,
So, here are some issues modifications and decisions we need to make:
1. List of roles. I believe the solution to this issue is we need to modify
the spec., per the change proposal to say something like:
Use of the following roles (I need to look at Steve's list in detail) will
have restricted functionality for authors in their ability to support the
full ARIA spec., specifically all aria global states and properties will
not be supported with the exception of aria-label. Also, the following ARIA
regions roles (this includes the landmarks) will not support the
aria-expanded property as these lightweight objects are static. Should the
author require the additional states and properties to support
accessibility the author will need to use fallback content in canvas to
produce an accessible solution.
2. Are these roles going to be made keyboard accessible. If not we need to
say something.
3. If we are going to support keyboard accessibility recommend including
the link role.
4. I would include the img role. However we will not be able to provide for
a long descriptions because we don't allow relationships. This needs to be
mentioned in the restrictions.
5. We will need an API extension that allows a test tool to walk the
combined DOM and lightweight objects tree so that an accessibility test
tool may walk the combined DOM and lightweight objects hierarchy. We do not
want test tools to overload JavaScript API to do this. This also provides
additional benefits for web application developers.
6. I would exclude role="application"
Rich
Rich Schwerdtfeger
From: Richard Schwerdtfeger/Austin/IBM@IBMUS
To: public-html@w3.org,
Date: 07/12/2012 10:31 AM
Subject: Fw: ISSUE-201: Aligning the two change proposals
See my comments on Steve's proposal.
Rich Schwerdtfeger
----- Forwarded by Richard Schwerdtfeger/Austin/IBM on 07/12/2012 10:12 AM
-----
From: Richard Schwerdtfeger/Austin/IBM@IBMUS
To: Steve Faulkner <faulkner.steve@gmail.com>, janina@rednote.net,
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
Date: 07/12/2012 10:09 AM
Subject: Re: Fwd: ISSUE-201: Aligning the two change proposals
Steve,
The roles you list exclude global most global states and properties:
http://www.w3.org/WAI/PF/aria/states_and_properties#global_states
Regions also support the expanded states:
http://www.w3.org/WAI/PF/aria/roles#region
So, the list of roles provided will not meet ARIA specs. without ensuring
that the applicable.
Rich
Rich Schwerdtfeger
Inactive hide details for Steve Faulkner ---07/12/2012 09:00:13
AM------------- Forwarded message ---------- From: Steve FaulknSteve
Faulkner ---07/12/2012 09:00:13 AM------------- Forwarded message
---------- From: Steve Faulkner <faulkner.steve@gmail.com>
From: Steve Faulkner <faulkner.steve@gmail.com>
To: HTML Accessibility Task Force <public-html-a11y@w3.org>,
Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS
Date: 07/12/2012 09:00 AM
Subject: Fwd: ISSUE-201: Aligning the two change proposals
---------- Forwarded message ----------
From: Steve Faulkner <faulkner.steve@gmail.com>
Date: 12 July 2012 11:53
Subject: Re: ISSUE-201: Aligning the two change proposals
To: Maciej Stachowiak <mjs@apple.com>
Cc: Paul Cotton <Paul.Cotton@microsoft.com>, Sam Ruby <
rubys@intertwingly.net>, public-html@w3.org, Edward O'Connor <
eoconnor@apple.com>
I over estimated the time it would take me to produce a CP based on Ted's
current CP
here it is:
http://www.w3.org/html/wg/wiki/ChangeProposals/hitregions
Note Ted's proposal remains unchanged excpet for the addition of the
following:
1. in the section:
Additional rationale for addHitRegion and the Path object (
http://www.w3.org/html/wg/wiki/ChangeProposals/hitregions)
ADDED start
As the 'lightweight objects which simply provide a label and a
WAI-ARIA role' are not focusable and cannot have author assigned
states and properties, the allowed ARIA roles should be limited to a
subset of the non interactive ARIA roles that do not require or
benefit from the addition of states and properties.
For example, A region with role=button could not be considered
accessible unless it is able to receive focus. Or a role=checkbox has
a required state of aria-checked, and must be able to recieve focus
for device indepedent operation, so it makes not sense to allow such
roles on lightweight objects.
ADDED end
2 in the section
Details (http://www.w3.org/html/wg/wiki/ChangeProposals/hitregions#Details)
Naturally changes to the proposed text, of an editorial nature, are at the
discretion of the editor.
ADDED start
In addition define the ARIA roles that many be assigned to unbacked hit
regions:
ARIA role restrictions for unbacked hit regions
Unbacked hit regions cannot be focusable and cannot have the necessary
states and properties assigned to adequately convey the semantics of
interactive controls. Author may assign the following roles using the
addHitRegion() > role() method.For all interactive controls associate a hit
region with an HTML element using the addHitRegion() > control() method.
subset of document structure roles
article
group
note
region
separator
landmark roles
application
banner
complementary
contentinfo
form
main
navigation
search
ADDED end
On 11 July 2012 22:09, Maciej Stachowiak <mjs@apple.com> wrote:
Can you offer a date by which you could have a new CP ready?
- Maciej
On Jul 11, 2012, at 5:35 AM, Steve Faulkner <faulkner.steve@gmail.com
> wrote:
Hi chairs,
As we don't appear to be able to reach consensus on the
'unbacked regions' aspect of ted's proposal.
Wondering if it makes sense for me to start work on a CP?
regards
SteveF
On 6 July 2012 08:16, Steve Faulkner <faulkner.steve@gmail.com>
wrote:
Hi Ted,
thank you for persevering.
you wrote:
"Each hit region has an associated control, which is
either an element or
an unbacked region description. You pass in the control
when you call
addHitRegion()."
reading
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#hit-regions
to clarify, regions only have a control when they have an
associated element. so unbacked regions don't have a
control right?
As unbacked regions cannt be focusable and cannot have
additional author defined properties it does not make any
sense for ARIA roles that are for interactive objects.
If the list of roles allowed on unbacked regions is
constrained to those that make sense, then I could live
with the rest of the concept.
So I suggest either the list of roles that can be used or
the list of roles that cannot be used be defined so no
one is under any illusion that unbacked regions can make
representations of controls, for example a button,
accessible.
Below is a suggested list of allowed ARIA roles:
subset of document structure roles
article
group
note
region
separator
landmark roles
application
banner
complementary
contentinfo
form
main
navigation
search
Is this something you are amenable to adding to your CP?
reegards
Stevef
On 6 July 2012 00:02, Edward O'Connor <eoconnor@apple.com
> wrote:
Hi Steve,
You wrote:
> what is the source of the note? Is it in your CP?
It's from r7029, which is one of the revisions my
CP aims to restore to
the W3C version of the spec.
> How is the region associated with the control
since the region can
> have no properties added which define a
relationship between them?
Each hit region has an associated control, which is
either an element or
an unbacked region description. You pass in the
control when you call
addHitRegion(). Is this unclear in the spec text?
> Soon as an author wants to go beyond simple
grouping objects, they can
> no longer use the lightweight objects anyway as
no relationship
> properties can be added to the lightweight
objects.
We should make the easy things easy and the hard
things possible.
Allowing hit regions to be associated with either
unbacked region
descriptions or elements allows for this: if you
have a complex thing
which requires WAI-ARIA states and properties to
describe, use an
element. If not, use an unbacked region
description.
HTH,
Ted
--
with regards
Steve Faulkner
Technical Director - TPG
www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives
- dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar -
www.paciellogroup.com/resources/wat-ie-about.html
--
with regards
Steve Faulkner
Technical Director - TPG
www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar -
www.paciellogroup.com/resources/wat-ie-about.html
--
with regards
Steve Faulkner
Technical Director - TPG
www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar -
www.paciellogroup.com/resources/wat-ie-about.html
--
with regards
Steve Faulkner
Technical Director - TPG
www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar -
www.paciellogroup.com/resources/wat-ie-about.html
Attachments
- image/gif attachment: graycol.gif
Received on Thursday, 12 July 2012 16:30:51 UTC