W3C home > Mailing lists > Public > public-html@w3.org > July 2012

Re: ISSUE-201: Aligning the two change proposals

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Thu, 5 Jul 2012 23:24:05 +0100
Message-ID: <CA+ri+VmZ0Ej1JNS7s+NBmwq66AaVX81YBHBmqLE5MoPckLE=wQ@mail.gmail.com>
To: "Edward O'Connor" <eoconnor@apple.com>
Cc: public-html@w3.org
hi Ted,

what is the source of the note? Is it in your CP?

>Is there something unclear about this note?

the note says:
"if the control has a corresponding region,
then that hit region's bounding circumference could be used to determine
what area of the display to magnify."

How is the region associated with the control since the region can have no
properties added which define a relationship between them?

It is unclear from your CP why the ability to add ARIA roles is needed or
desirable

If the unbacked regions are to not to be objects that can have defined
states and properties, then  why not have all hit regions not associated
with an element  simply have a platform accessibility API role=group  and a
label, which would do away with the need to support ARIA on the lightweight
objects?
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.


regards
SteveF











On 5 July 2012 22:12, Edward O'Connor <eoconnor@apple.com> wrote:

> Hi Steve,
>
> You wrote:
>
> > Your CP defines 'lightweight' hit regions without:
> > a) the ability to make them focusable
>
> Is there something unclear about this note?
>
> "Thus, for instance, a user agent on a touch-screen device could provide
> haptic feedback when the user croses over a hit region's bounding
> circumference, and then read the hit region's label to the user.
> Similarly, a desktop user agent with a virtual accessibility focus
> separate from the keyboard input focus could allow the user to navigate
> through the hit regions, using the virtual DOM tree described above to
> enable hierarchical navigation. When an interactive control inside the
> canvas element is focused, if the control has a corresponding region,
> then that hit region's bounding circumference could be used to determine
> what area of the display to magnify."
>
> > b) the ability to add accessibility states and properties that are
> >    associated with interactive objects. Only providing the ability to
> >    add a role to lightweight regions means the the usable ARIA roles
> >    is limited to a subset of non widget roles, and even then those
> >    roles usefulness ir constrained as they cannot have ANY states and
> >    properties assigned.
>
> Right; if you need to assign states or properties, just use an element.
>
> Paul asked:
>
> > Can we get an estimate of when you will be able to answer these
> > questions?
>
> Right now! :)
>
>
> Thanks,
> 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
Received on Thursday, 5 July 2012 22:25:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:33 UTC