Re: Fw: ISSUE-201: Aligning the two change proposals

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

Received on Thursday, 12 July 2012 16:30:51 UTC