[community] An odd Chrome issue with ALT attributes, with implications for accessibility audits and AT
Harnum, Alan
aharnum at ocadu.ca
Wed Apr 5 18:12:10 UTC 2017
Hi Ambrose - thanks, the comments on historical behaviour are useful.
While I haven't tested on older versions of Chrome, we began to see issues
with Chrome and VoiceOver around January of this year, as described in the
bug report (VoiceOver behaves as though no ALT tag exists) - hence my
feeling this extends outside the Inspector context.
I don't personally recall the Inspector behaviour around the ALT attribute
prior to investigating this issue due to the VoiceOver problems, but IMO
it's incorrect behaviour to render the attribute in this way per the HTML5
spec. I'll wait and see what reply the Chromium team says in reply - it is
possible that what's actually going on is a recently introduced issue
somewhere between Chrome, the OS X accessibility API and VoiceOver.
On 2017-04-05, 1:20 PM, "community on behalf of Ambrose Li"
<community-bounces at lists.idrc.ocadu.ca on behalf of
al12si at student.ocadu.ca> wrote:
>On Wed, 2017-04-05 at 13:11 -0400, Ambrose Li wrote:
>> I don't remember ever seeing Chrome
>> not do this
>
>BTW, I've always assumed this was just an artefact of the Inspector. Is
>the Inspector guaranteed to produce an accurate representation of the
>DOM, or is there an independent way to verify that this is a real issue
>and not an Inspector bug?
>
>--
>Ambrose Li <al12si at student.ocadu.ca>
>http://port.ambroseli.ca
>
>"Any organization which designs a system... will inevitably produce a
> design whose structure is a copy of the organization's communication
> structure." -- Conway's Law
>
>
>________________________________________
>Inclusive Design Community (community at lists.idrc.ocadu.ca)
>To manage your subscription, please visit:
>http://lists.idrc.ocadu.ca/mailman/listinfo/community
More information about the community
mailing list