Re: How do assistive technologies handle icon fonts?

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

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 <


>> 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)?


Received on Tuesday, 1 December 2015 16:44:43 UTC