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

Re: ISSUE-201: Aligning the two change proposals

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




graycol.gif
(image/gif attachment: graycol.gif)

Received on Friday, 13 July 2012 12:42:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 13 July 2012 12:42:36 GMT