- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Fri, 13 Jul 2012 07:40:49 -0500
- To: Charles Pritchard <chuck@jumis.com>
- Cc: "Edward O'Connor" <eoconnor@apple.com>, Steve Faulkner <faulkner.steve@gmail.com>, Maciej Stachowiak <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, "public-html@w3.org" <public-html@w3.org>, Sam Ruby <rubys@intertwingly.net>, franko@microsoft.com
- Message-ID: <OFE780C408.4D52B9E5-ON86257A3A.0045705F-86257A3A.0045A80C@us.ibm.com>
Well, not to put a ruffle on things but I also think that the lightweight
object concept is a bit immature.
Would people consider moving them to html.next along with the other full
SVG path work that people agree that we move? This way the concept could be
developed more.
Rich
Rich Schwerdtfeger
From: Charles Pritchard <chuck@jumis.com>
To: Steve Faulkner <faulkner.steve@gmail.com>,
Cc: Maciej Stachowiak <mjs@apple.com>, Paul Cotton
<Paul.Cotton@microsoft.com>, Sam Ruby <rubys@intertwingly.net>,
"public-html@w3.org" <public-html@w3.org>, "Edward O'Connor"
<eoconnor@apple.com>
Date: 07/12/2012 01:22 PM
Subject: Re: ISSUE-201: Aligning the two change proposals
I object to adding lightweight nodes at this time. Like the Path object
proposal, they're completely unnecessary in solving the outstanding issues
needed for Canvas to progress to a full recommendation.
The Path object proposal requires further input and interfacing with the
SVG2 WG in relation to scope. The lightweight nodes proposal requires
further interfacing with the Web Components contributors, especially in
relationship to DOM events, focus and accessibility.
Both sections are useful, but unnecessary at this point. Neither have been
discussed openly with the technology platforms whose semantics they adopt.
I'm happy to see that work happen, I'm happy to start work on it
immediately. But I don't want it blocking or otherwise harming our work
from the Canvas working group to push the Canvas spec along with HTML5.
-Charles
On Jul 12, 2012, at 3:53 AM, Steve Faulkner <faulkner.steve@gmail.com>
wrote:
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
Attachments
- image/gif attachment: graycol.gif
Received on Friday, 13 July 2012 12:42:36 UTC