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



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