- From: Joanmarie Diggs <jdiggs@igalia.com>
- Date: Tue, 1 Dec 2015 11:42:24 -0500
- To: Michiel Bijl <michiel@agosto.nl>, Phill Jenkins <pjenkins@us.ibm.com>
- Cc: Web Accessibility Initiative Interest Group <w3c-wai-ig@w3.org>, Ja Eun Ku <jku@illinois.edu>
Hi Michiel. Thanks for the include! More inline. On 12/01/2015 05:22 AM, Michiel Bijl wrote: > While I agree these issues should be addressed by Browser/AT vendors, > there should also be a way to make this accessible today. If the goal is to hide the symbol, aria-hidden should do nicely. If instead the goal is to expose the symbol and have ATs present it, I would suggest a combination of a name and role: <a href="#book-hotel"> <i class="fa fa-bed" aria-label="bed" role="img"></i> Book a hotel </a> The use of aria-label will cause the accessible to stop being an unnamed text object and start being, well, a named text object. :) That might be sufficient for some ATs. It's not at least for Orca (and possibly other ATs) due to caret navigation. More specifically, without the role being added, what (at least) Orca sees is an object with a text role which implements the accessible text interface. If you give Orca a text object, Orca will assume it is caret-navigable and allow the user to arrow up to what happens to be a private-use character. I suppose I could add logic to Orca to the effect of: If it's a text object, and the context of that text object are private-use characters, ignore the role and ignore the text. But that's a heuristic hack. And one that potentially would have to be implemented by multiple ATs. And authors would still need to provide a name if you wanted something like "bed" presented. I don't see that as an ideal solution. If, on the other hand, you use a role turning that text object into a non-text object (has role image, does not implement the accessible text interface), you eliminate the caret-navigation issue entirely. And I'm pretty sure that ATs would not have to do anything to support that. Furthermore I would argue that for all intents and purposes, that bed *is* an image. So why not expose it as such? Hi Phill. >> On 01 Dec 2015, at 07:45, Phill Jenkins <pjenkins@us.ibm.com [...] >> Placing, and expecially placing the burden on the bazillion web >> developers to constannly develop workarounds and half baked hacks, >> instead of lobbying and driving the relative small number of AT >> developers, is an inefficient and loosing battle this group seems to >> fall into over and over in my opinion. I agree with you about the problem of the bazillions. But I think the solution is to make it really easy for all those authors to do the right and fully-baked thing. Because the only advantage that I can see of having the ATs deal with this on behalf of everyone is that the half-baked hacks are done by a handful, rather than by a bazillion. The disadvantage is that those half-baked AT hacks are in danger of being (mis)applied to bazillions of pages; not just those with fontawesome. And as Charles stated in his reply: As the name suggests, *private* use is a way to enable internal systems to add codepoints that they don't find in a standard, if they really need them. Giving these codepoints agreed names would destroy their ability to be used in that way. I was hoping that fontawesome could just JavaScript it into the RightThing(tm) so as to not put a burden on authors. But a quick glance at their site ("No JavaScript Required") just blew that hope away. Could this problem be solved by having the fontawesome people add documentation suggesting authors do something like I indicated in my example above (role + name)? --joanie
Received on Tuesday, 1 December 2015 16:44:43 UTC