Hacker News Reader

Comment by madeofpalk | Hacker News Reader

I don't think there's anything wrong with assuming people are running a graphical browser.

We're at the point where, depending on your exact industry/usecase, earlier IE versions are less than 1% for a lot of 'mainstream' sites. The amount of people who aren't able to render a custom web font, let alone a non-graphical browser, would be in the extreme minority.

IMHO, that is not a use case that's not worth worrying about.

View on HN

Well, of course there are those who are weird, like Mr. Stallman:

> I generally do not connect to web sites from my own machine, aside from a few sites I have some special relationship with. I usually fetch web pages from other sites by sending mail to a program (see git://git.gnu.org /womb/hacks.git) that fetches them, much like wget, and then mails them back to me. Then I look at them using a web browser, unless it is easy to see the text in the HTML page directly. I usually try lynx first, then a graphical browser if the page needs it (using konqueror, which won't fetch from other sites in such a situation).

https://stallman.org/stallman-computing.html

But there are other groups of people for which this is relevant: Blind or otherwise visually impaired people depending on screen readers or similar. Those don't have a good choice and abusing text there makes the experience unbearable.

I received an accessibility report for a website made by a big reputable accessibility agency, and they had no problem with us using Font Awesome. It's ignored by screen readers, unless you put a title attribute, which you can do if the icon is more than decorative.

That said, I use NoScript with 'Forbid Font-Face' enabled, so a lot of the time I see squiggles instead of icons. But that's my choice, and I'm almost certainly in the minority, so I'm not angry about sites that use fonts instead. SVG probably will come to replace font icons, but for now, they've been really helpful for a lot of small sites.

Stallman isn't a group of people though, he's one very very extreme case that frankly doesn't matter in the big picture of web accessibility and it probably isn't going to hurt anyone if he can't see every bit of your site as perfectly as everyone else.

I don't understand this.

Most icon fonts use PUA codepoints to avoid issues with screen readers. If you're not going to use icon fonts, what are you going to use? Images? CSS Backgrounds? Inline SVGs?

Screen readers can't read any of them. Thankfully there are ways to make all of these accessible, with things like ARIA attributes.

We can use SVG images/sprites with an alt="" attribute.

While that is probably 'better' how in practice does it matter. SVG (esp with sprints) vs icon font are basically the same. Both are ways of embedding multiple vector images in one resource that you attribute meaning to using `title` attributes. In practice they will behave pretty much exactly the same.

There are still some issues with that – for example, it's easier to change attributes like text colour when using an icon font, something that becomes substantially more awkward with SVG. This is appropriate for things like buttons and other elements with hover effects.

Just inherit the colour, in the spritesheet use:

  fill: currentColor;

Same with stroke. Works great.

If you must use a magic font, why not use ligatures to replace words?

Somehow most web developers care a lot more about the ~3% of users that use IE 10 or lower than about the ~4% of users that are legally blind and can't use a graphical browser.

I can only hope that his is mostly ignorance.

> Somehow most web developers care a lot more about the ~3% of users that use IE 10 or lower than about the ~4% of users that are legally blind and can't use a graphical browser.

It's only correct to infer that web developers care less if the cost of supporting either is the same.

(Also many legally blind people use graphical browsers; legally blind is not the same as "unable to see anything").

I readily confess I don't know many legally blind users, but the handful I do know all use graphical browsers with screen readers.

Is that not typical?

(That said, if you're using webfonts for icons you should be using the unicode Private Use Area.)

Well there's also the fact that 100% of those 3% are definitely online loading website while the same can't be said for the 4% legally blind.

I tend to disregard the entire <7% (assuming overlap).

I like the idea of making a commitment to accessibility, simplicity, and universality.

I don't like these things, so I'll try to make a stand and not use it. Of course, I only have that luxury because I don't make websites for a living.

> "<svg> may not work for people like me who disable javascript. It introduces potential security issues"

SVG works for me with JS disabled (using Firefox on OS-X). Do you have any pointers on when/why SVG wouldn't work without JS?

I looked into it further and I think I'm mostly wrong about <svg>. You can embed javascript into it, but if you don't, then as far as I can tell it works fine for me. Sorry!

That makes sense…and I think that's where the potential security vulnerability comes into play - if you allow untrusted users to upload SVGs, then they could potentially be uploading javascript to your site, offering a vector for XSS. As far as I can tell, adding your own SVGs to your site doesn't open up any novel security issues.

svg is no more accessible or simple than an icon font.

You have the same resources and APIs (can you call HTML attributes an 'API'?) available to make the usage of icon fonts friendly for screen readers.

SVG is considered more accessible because it's an image, not text. 'f' doesn't mean aeroplane (even though it looks like an aeroplane in a 2010-style graphical font) but img alt="plane" does.

That's an argument for not using an icon font which remaps normal characters but the most common ones use private-use characters which are ignored by screen readers. In which case are these not equally accessible?

    <i class="fa fa-globe" aria-label="Picture of a globe"></i>
    <img svg="globe.svg" alt="Picture of a globe">

Accessibility is more about process and testing than any particular technology since they all can be done poorly.

Apologies if this is a massively ignorant question, but isn't the <i> tag an inline text span? In which case, isn't it wrong to have it be empty?

    The i element represents a span of text offset from its
    surrounding content without conveying any extra emphasis or
    importance, and for which the conventional typographic
    presentation is italic text; for example, a taxonomic
    designation, a technical term, an idiomatic phrase from
    another language, a thought, or a ship name.

http://www.w3.org/TR/html-markup/i.html

Using it without text strikes me as a hack, and one that is hostile to usability, among other problems. I understand why it would work, but it's abusing the technology as far as I can tell.

Since I've seen this in at least two comments now, can somebody explain to me why it's not considered an anti-pattern in 2016?

[edit: formatting]

I would agree with that – it's a convention which the FontAwesome project uses for reasons I haven't looked into (I'm assuming not wanting to type 6 more characters).

I use <span> on all of my projects.

Yes but shouldn't a <span> also always have content? Am I missing something here?

There's nothing that requires it to have content, no. Absent other styles, an empty <span> would be invisible and have no effect though.

It has text content, merely inserted by CSS `content` instead of living in the HTML itself.

Your mailbox icon 'ſ' will be read aloud as 'latin small letter long s' or 'esss' if you're lucky.

But I can't really tell if you're actually saying that the ability for web pages to be read aloud coherently is 'a use case that's not worth worrying about'.

Attributes can be added to make screen readers ignore certain html elements like icons for exactly this reason.

    <i class="fa fa-pizza" aria-hidden="true"></i>

This is a good point. There is additionally ligatures used by the Google material icons. These let you put an actual textual representation of the icon and only replace it with an icon if the browser supports it: http://google.github.io/material-design-icons/

Why FA insists on abusing the Italics tag (repurposing it as "Icon") instead of leveraging the appropriate <span> is...specious at best.

The <i> tag in modern HTML does not mean "italics", though the examples given to illustrate its new semantics are all things conventionally set in italics.

"The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought, or a ship name in Western texts." [0]

Its use for text-as-icon is arguably, despite obviously not being a use classically set in italics, within the defined semantics of the <i> tag.

EDIT: Though FAs use isn't actually text-as-icon, it uses empty tag as an icon. That's not consistent with the semantics of the tag.

[0] https://html.spec.whatwg.org/multipage/semantics.html#the-i-...

<i> is not the "Italics tag":

In earlier versions of the HTML specification, the <i> tag was merely a presentational element used to display text in italics, much like the <b> tag was used to display text in bold letters. This is no longer true, as these tags now define semantics rather than typographic appearance.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/i

You can use whatever <element> you want with FA. It's the class names that are important.

Or, y'know, one could just use an image instead of abusing HTML:

    <img src="pizza.png" alt="" />

Except that would require multiple web requests unless you were using an image sprite. Font Awesome and Glyphicons solve this by using a font file or sprite.

I do wish they didn't overwrite the traditional <i> tag, but I guess we're supposed to be using <em> for semantic HTML.

> Except that would require multiple web requests unless you were using an image sprite.

So … it can be made to work with a single request then.

Yup, and Glyphicons does that.

Unless you need to think about accessibility, which is a usecase many need to deal with.

Reply on news.ycombinator.com