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 <http://roles/#article>
>>    - group <http://roles/#group>
>>    - note <http://roles/#note>
>>    - region <http://roles/#region>
>>    - separator <http://roles/#separator>
>>
>> landmark roles
>> <http://roles/#application>
>>
>>    - application <http://roles/#application>
>>    - banner <http://roles/#banner>
>>    - complementary <http://roles/#complementary>
>>    - contentinfo <http://roles/#contentinfo>
>>    - form <http://roles/#form>
>>    - main <http://roles/#main>
>>    - navigation <http://roles/#navigation>
>>    - search <http://roles/#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<http://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<http://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