Re: suggestions for new roles and properties in ARIA next

Hi James,

>> My thinking is that for graphical user agents its still an image, and
>> it will still need alt for that purpose. also they generally map alt
>> to the accessible name property in APIs, so why require an additional
>> aria-label that does the same thing?
>
> For the same reason that I would expect this to not work:
> <input type="button" role="text" value="Foo">
> <input type="checkbox" role="text" checked>
>
> Like alt, the value and checked attributes are specific to defined HTML roles, which have been specifically overridden here. If it's no longer an image, button, or checkbox, none of the image, button, and checkbox attributes apply anymore.

> <input type="button" role="text" value="Foo">
> <input type="checkbox" role="text" checked>

neither of these would be conforming in HTML5 for example as the
allowed roles on these inputs are severeley restricted.
but role=text would be conforming as img has no role restrictions.


besides there is a difference, in the case of alt, it is still needed
for graphical browsers, adding role=text does not change that.
so should be specified regardless of the presence of role=text.

why would we want to require that authors add a redundant aria-label
when alt does the job?

My <img src="heart.png" alt="heart" role="text" aria-label="heart"> breaks.

in this example:

<img src="heart.png" alt="heart" role="tooltip">

alt provides the accessible name in MSAA/IA2 and the above code is
conforming HTML5


> But a caption for a table or image is just the label for the table or image. The extra role wouldn't matter.

I think that distinguishing between an alt for an image which is
supposed to transparently label it and a caption which has a different
semantic meaning is useful.
I see value in AT being able to identify to users a caption as a caption.

 Both IAccessible2[1] and AT-SPI [2] have caption roles:

"ROLE_CAPTION  The object contains descriptive information, usually
textual, about another user interface element such as a table, chart,
or image."

[1]http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/
[2] http://people.gnome.org/~billh/at-spi-idl/html/namespaceAccessibility.html#a216


regards
steve

On 20 April 2011 19:05, James Craig <jcraig@apple.com> wrote:
> On Apr 20, 2011, at 3:56 AM, Steve Faulkner wrote:
>
>> Hi james,
>>
>>>> Seconded, but this example would probably need aria-label, because overriding the img role means the alt attribute is now meaningless. Agreed?
>>
>> My thinking is that for graphical user agents its still an image, and
>> it will still need alt for that purpose. also they generally map alt
>> to the accessible name property in APIs, so why require an additional
>> aria-label that does the same thing?
>
> For the same reason that I would expect this to not work:
> <input type="button" role="text" value="Foo">
> <input type="checkbox" role="text" checked>
>
> Like alt, the value and checked attributes are specific to defined HTML roles, which have been specifically overridden here. If it's no longer an image, button, or checkbox, none of the image, button, and checkbox attributes apply anymore.
>
>>> Kind of seems like you're stretching description to support the semantics of @summary and maybe @longdesc. What makes you certain this necessary?
>>
>> my thinking is that there are use cases where a developer would want
>> to provide info to AT users which is redundant for non AT users, but
>> is more a description than a name. having to place this information
>> somewhere else and then refernece via describedby can be a pain.
>
> Can you give a specific example (using real text, not lorem ipsum) of where this might be needed? I'd just like to come up with a defensible case that cannot be done another way, or one that would gain significant benefit over the alternative if done this way.
>
>>> Associated how? aria-describedby? aria-labelledby? If so, why is the role necessary? This reminds me of the label role that was previously removed from ARIA.
>>
>> I would think the relationship can be implemented in the browser
>> if a table has a child caption = accessible name
>> if a figure has a child caption = accessible name
>>
>> the usefulness of the role would be in being able to identify the
>> caption as a caption, especially for images in figure
>
> But a caption for a table or image is just the label for the table or image. The extra role wouldn't matter.
>
> This is a lot like the old label role, which may have been in the original ARIA proposal, but I couldn't find reference to in old versions of the spec. In any case, it was removed because it was deemed unnecessary. I was in the group then, but this pre-dated me taking the editor role, so I'm not sure where to look.
>
> Michael Cooper, I couldn't find a draft older than http://www.w3.org/TR/2008/WD-wai-aria-20080204/ … Also, is there a way to search old IRC meeting logs?
>
>> BTW these suggestions were only that, not particularly thought out.
>
> I understand. They are good suggestions. I'm just trying to help us consider all the implications. Thanks.
>
>



-- 
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, 21 April 2011 09:06:45 UTC