Re: Element.getComputedRole()

I have collected various threads and bugs on this and related here:
http://discourse.specifiction.org/t/dom-apis-to-expose-accessible-role-states-properties/693

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>

On 14 November 2014 at 22:38, James Craig <jcraig@apple.com> wrote:

> Element.role will be the reflected string value:
>
> for <h1 role="fake">
>
> el.role -> read/write string "fake"
> el.computedRole -> readonly string "heading"
>
>
> On Nov 14, 2014, at 11:05 AM, Alexander Surkov <surkov.alexander@gmail.com>
> wrote:
>
> I'd say this is a11y use case since it's all about making the app
> accessible, in other words if we had no ARIA then CSS role selector would
> be rather useless. I think I like CSS role since it's nice for code
> unification, also imo that serves as rationale to have JS method for the
> role, but I still don't get why computedRole has to be on Element and why
> it prefixed by 'computed', having simple 'role' should work fine.
>
> On Tue, Nov 11, 2014 at 11:17 PM, James Craig <jcraig@apple.com> wrote:
>
>> Depends on what you call an an a11y-only use case.
>>
>> For example, a script to focus the first button (ARIA button or native)
>> in a dialog?
>>
>>
>> document.getElementBySelector(":role(dialog)")[0].getElementsBySelector(":role(button)")[0].focus();
>>
>> Or by using one selector to style all the headings:
>>
>>   *:role(heading)
>>    /* Mostly equivalent to "h1, h2, h3, h4, h5, [role=heading]" */
>>   /* but the :role() selector catch some additional headings, like <div
>> role="foo heading"> */
>>   /* and the expanded selector would mismatch some others, like <h1
>> role="none"> */
>>
>> On Nov 11, 2014, at 10:32 AM, Alexander Surkov <
>> surkov.alexander@gmail.com> wrote:
>>
>> a11y stuff in CSS is interesting idea but that shouldn't require Element
>> interface extension. Do I understand right that there are non a11y use
>> cases for a11y properties? Is it restricted to a11y role property only?
>>
>> On Mon, Nov 10, 2014 at 2:42 PM, James Craig <jcraig@apple.com> wrote:
>>
>>>
>>> > On Nov 10, 2014, at 11:08 AM, Alexander Surkov <
>>> surkov.alexander@gmail.com> wrote:
>>> >
>>> > Are there any summary of pros and cons from the discussion? I still
>>> not sure that DOM Element is a right place to host accessibility methods.
>>>
>>> The primary argument was that role is useful outside the context of
>>> accessibility. The new CSS :role() selector is one example of that.
>>>
>>>
>>>
>>
>>
>