- From: James Nurthen <james.nurthen@oracle.com>
- Date: Tue, 5 Jul 2016 15:41:28 -0700
- To: public-aria@w3.org
- Message-ID: <b3c114c7-8fc8-a17c-629f-12c7c553ff41@oracle.com>
In my opinion allowing aria-roledescription="" opens up far more possibilities for author error than role="static" does. In my opinion it is moving in the wrong direction. On 7/5/2016 3:31 PM, Rich Schwerdtfeger wrote: > James, > > I agree it is a hack. This is temporary. I agree with your reasoning > for option 2 even though I understand Matt’s position as we enabling > authors with another tool to manipulate how a role is presented > verbally to the user. Yet, in the absent of a special role to handle > this case this is what we have. > > James Craig indicated we should not make this a recommended technique. > I agree but it should be a valid option for authors until we release > an alternative. > > As much as I agree with Matt’s proposal for 1 and 3 we will not reach > consensus if we choose 1 or 3 and we will be back to the stale mate we > had in the past. I don’t want to open up that can of worms again and > we need to get on with ARIA 1.1 so that we can address, frankly, much > larger issues with ARIA 2.0. > > Rich > > Rich Schwerdtfeger > > > > >> On Jul 5, 2016, at 5:09 PM, James Nurthen <james.nurthen@oracle.com >> <mailto:james.nurthen@oracle.com>> wrote: >> >> In my opinion we should have a text/static role as (as I stated >> previously). The whole aria-roledescription="" thing sounds like a >> hack. If it were not for the use cases where we need the static role >> I would favour either options (1) or (3) but due to the fact that we >> have abandoned the text/static role - with one of the major arguments >> being that we could use aria-roledescription to accomplish the same >> thing, I feel we have to go for option (2). >> >> Regards, >> >> James >> >> >> On 7/5/2016 2:50 PM, Rich Schwerdtfeger wrote: >>> … or you leave the role description off altogether and the default >>> is to do nothing (don’t change how the role is processed). >>> >>> I do agree there is a concern that authors will put themselves in a >>> position where they try to be the screen reader vendor and influence >>> the user experience. >>> >>> >>> Rich Schwerdtfeger >>> >>> >>> >>> >>>> On Jul 5, 2016, at 4:27 PM, Matt King <a11ythinker@gmail.com> wrote: >>>> >>>> I vote for option 3 in the below proposal. If option 3 is not >>>> acceptable to the group, I vote for option 1. >>>> While allowing ARIA to wipe out screen reader announcement of an >>>> element’s role with an empty roledescription makes ARIA more >>>> flexible, I think it is unnecessary flexibility that increases the >>>> risk of negative side effects and makes debugging problems more >>>> complex for authors. As a screen reader user, I already find >>>> roledescription scary enough without this added complexity. >>>> ** >>>> *Matt King* >>>> ** >>>> *From:*Matt King [mailto:a11yThinker@Gmail.com] >>>> *Sent:*Tuesday, July 5, 2016 1:53 PM >>>> *To:*ARIA Working Group <public-aria@w3.org >>>> <mailto:public-aria@w3.org>> >>>> *Subject:*ACTION-2092 - Proposal ready for review - Create a >>>> proposal for handling the role description value of “” >>>> Proposals to specify how null or empty aria-roledescription values >>>> will be handled by user agents and assistive technologies are ready >>>> for review. >>>> Following are the proposals. As I explain below, I think this >>>> exposes other ambiguities in aria-roledescription that should be >>>> plugged. >>>> In branch action2092option1[1], added the following sentence. >>>> "If the value of aria-roledescription is empty or contains only >>>> white space characters, user agents MUST treat the element as if >>>> the aria-roledescription property were not specified." >>>> In branch action2092option2[2], added the following 2 sentences. >>>> "If the value of aria-roledescription is empty or contains only >>>> white space characters, user agents SHOULD expose the value in a >>>> manner consistent with how null values are expressed in their >>>> platform accessibility API. If the value is empty or null, >>>> assistive technologies MAY render the element as if it does not >>>> have a role name." >>>> In the process of making the above branches, I noticed that there >>>> is still significant ambiguity regarding what an assistive >>>> technology should do with the roledescription. The actual intent of >>>> the property is not clear. For example, if you provide a >>>> roledescription for a region, should the assistive technology still >>>> treat the element as a region? This ambiguity also has significant >>>> impact on the meaning of the note that tells authors how to limit >>>> the use of roledescription. >>>> The issue of how authors, user agents, and assistive technologies >>>> may treat null or empty values increases the need to remove these >>>> ambiguities. So, I have also proposed an option 3, which equivalent >>>> to option 1 but also addresses these issues. I did not make a >>>> similar equivalence to option 2 because it is much less clear what >>>> the normative authoring and assistive technology guidance should be >>>> in that case. >>>> In branch action2092option3[3]: >>>> 1. Stated that user agents MUST NOT expose aria-roledescription if >>>> it is empty or whitespace (same as option 1) >>>> 2. Changed the note that contained an implied normative author >>>> SHOULD limiting use of the roledescription into a normative author >>>> SHOULD. >>>> 3. Added a normative assistive technology SHOULD statement >>>> explaining that roledescription should change only how the name of >>>> the role of an element is expressed and should not change which >>>> assistive technology functions are provided for an element. >>>> 4. (editorial) Used a list format to express the authoring and user >>>> agent requirements. >>>> [1] action2092option1 branch: >>>> http://rawgit.com/w3c/aria/action2092option1/aria/aria.html >>>> [2] action2092option2 branch: >>>> http://rawgit.com/w3c/aria/action2092option2/aria/aria.html >>>> [3] action2092option3 branch: >>>> http://rawgit.com/w3c/aria/action2092option3/aria/aria.html >>>> Matt King >>> >> >> -- >> Regards, James >> >> <oracle_sig_logo.gif> <http://www.oracle.com/> >> James Nurthen | Principal Engineer, Accessibility >> Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415 >> 987 1918 <tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com >> Oracle Corporate Architecture >> 500 Oracle Parkway | Redwood Cty, CA 94065 >> <green-for-email-sig_0.gif> <http://www.oracle.com/commitment> Oracle >> is committed to developing practices and products that help protect >> the environment >> > -- Regards, James Oracle <http://www.oracle.com> James Nurthen | Principal Engineer, Accessibility Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415 987 1918 <tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com <sip:james.nurthen@oracle.com> Oracle Corporate Architecture 500 Oracle Parkway | Redwood Cty, CA 94065 Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Received on Tuesday, 5 July 2016 22:42:04 UTC