W3C home > Mailing lists > Public > public-html-a11y@w3.org > September 2010

[Bug 10497] What happens to role of <img alt="non-empty"> inside a <figure role="img">?

From: <bugzilla@jessica.w3.org>
Date: Tue, 07 Sep 2010 21:59:57 +0000
To: public-html-a11y@w3.org
Message-Id: <E1Ot6Cr-0001HJ-1L@jessica.w3.org>

--- Comment #4 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>  2010-09-07 21:59:56 ---
(In reply to comment #3)
> (In reply to comment #1)

> Your logic is based on lack of understanding of users with disabilities and
> assistive technology.
> Many users of screen readers are not "non-visual" they may have limited vision
> or they may have cognitive impairments, removing role information from images
> does a disservice to these users and reduces the accessibility of content for
> them.

Regardless of his logic, this bug was filed with the assumption that the
default for an <img> without an emtpy @alt="", would be role="img". And, I now
know the answer to my question - it gets some kind of presentation role.



Thus, the 1st result of setting the role of <figure> to "img", would be that
the user agent wouldn't present the content of the <figcaption> (if any) or of
the @alt text (if any) to the AT user. 

The 2nd result would be that, in order provide a caption, one would have to use
aria-labelledby to point to the <figcaption> and/or the <img> element.

Effectively, to add role="img" without simultaneously adding a non-empty
aria-labelledby, would be equal to placing an <img> with no @alt attribute into
the document: the element would be presented to the user as an image. However,
they would not receive any alternative text for the image.

So, then the next queston becomes: Should a conformance check consider <element
role="img">, without any label identified via and aria-* attribute, a bug?  I
think yes.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Tuesday, 7 September 2010 21:59:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:44 UTC