Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Image/Icon Replacement #31

Closed
loganfranken opened this issue May 29, 2015 · 13 comments
Closed

Image/Icon Replacement #31

loganfranken opened this issue May 29, 2015 · 13 comments

Comments

@loganfranken
Copy link
Contributor

I would like to explore the technique of image replacement and whether or not we should provide recommendations regarding the practice in the Web Guide.

For anyone who isn't familiar, image replacement is the technique of replacing a text element with an image.

This is a pretty old CSS technique that was introduced to address an issue like the following:

Let's say you want to use a banner image as the title of your website. So you go ahead and do this:

<h1><img src="images/header.png" alt="Web Standards Guide" /></h1>

This works visually but it's not semantic and it's unclear for those using assistive technologies: the img isn't the title of your website, "Web Standards Guide" is. The fact that it's an image is just an implementation detail specific to your current design.

Instead, you want this:

<h1>Web Standards Guide</h1>

And you just want some method of shoehorning the image in there. The most popular technique is the "Phark method," where you shove the text content off screen with a text-indent set to -9999px and then put the image in the background.

There's even newer methods for this like the Kellum method and the HTML5 Boilerplate method.

CSS Tricks did an awesome tongue-in-cheek "museum" of image replacement techniques.

With the rise of SVG and icon fonts, though, there's been less emphasis on replacing text content with actual bitmap images and the discussion around image replacement seems to have dropped out altogether.

As an example, the image replacement utility class in HTML5 Boilerplate (.ir) was removed completely (see: h5bp/html5-boilerplate#1475).

I don't really understand why, though, as the same principles would seem to apply in a SVG/icon font world.

For example, the GitHub logo next to the search bar above is implemented as follows:

<a class="header-logo-invertocat" href="https://github.com/" aria-label="Homepage">
  <span class="mega-octicon octicon-mark-github"></span>
</a>

The a and span elements in this case serve as hooks for GitHub's icon font. If you wanted, though, you could easily have something like the following:

<a class="header-logo-invertocat" href="https://github.com/" aria-label="Homepage">
  <span class="mega-octicon octicon-mark-github">Homepage</span>
</a>

And just push the "Homepage" text out of the way and insert the icon font using a pseudo element, recreating an image replacement-like technique (see demo).

From GitHub's example above, though, the assumption is that accessibility issues should be covered by the use of aria-label. This doesn't address the concern that having an empty span isn't very semantic as a homepage link, but I could see that argument getting shot down as overly pedantic.

So, anyway, I want to explore whether or not image replacement techniques are still relevant, specifically in regards to icon fonts/SVG/etc. Would love to hear any thoughts and opinions on the matter!

@garster
Copy link
Member

garster commented May 29, 2015

This is way over my head, but I have in the past used a <h1> , then used CSS to make it a block then set a background image in the <h1>. I did keep the text in the header shown, just moved it around. This was no way related to accessibility, just a cool trick. And now that I look very much like your codepen demo . As far as "Standard", I would no idea what to recommend.

@tenken
Copy link
Contributor

tenken commented May 29, 2015

In this context what are the pro's and con's to having a semantic homepage link?

And if I reword that question -- my general understanding if pushing semantics on the web stems in part from AT consumption but also (after googling "semantic web"):

The Semantic Web is an extension of the Web through standards by the World Wide Web Consortium (W3C). The standards promote common data formats and exchange protocols on the Web, most fundamentally the Resource Description Framework (RDF).

Which I take to mean "other computers may read this data" such as microformats for vcard info. I have never come across a site or service that actually does this for webpage content ... outside of maybe like Skype phone numbers, and Google PageRank -- but thats not sharing the data in terms or re-purposing it for clients in my opinion.

Alright, I can think of 1 further example. Sharing biblio information and consuming a feed of author publications (but again thats not on say my Index page as apart of my homepage -- so again I say why care so much about the semantics of markup in every context, the data would be on it's own feed page) ...

I guess my point and question -- is that some are viewing semantics as black and white. But I think there is a spectrum for semantics and markup. I think HTML5/CSS3+ is moving to a point where vector graphics, layouts, web fonts are allowing us to deprecate older techniques such as this when used solely to provide nicer UX or visual design elements to endusers.

@loganfranken
Copy link
Contributor Author

Hey @tenken: I agree with you that it's definitely a spectrum.

As far as the pro/cons of semantics, I usually push for semantics for two reasons:

1. Accessibility

By starting with a text-only baseline it's easier to ensure that the page will be accessible to screenreaders and other assistive technologies (instead of working backwards from an icon font, image, canvas, SVG etc. and making sure it's accessible).

This also is true for search engine crawlers: starting with text, you know crawlers can parse it (rather than putting in additional effort to make sure they can).

2. Flexibility

By starting with text, you aren't tying the specifics of a website's visual representation into the markup of the page: thus, if you decide to swap out your icon font, image, canvas, SVG with something else, you can do this without modifying the markup.

In other words, this second point ensures you maintain a separation of concerns.

However, I'll admit that I think it's getting harder and harder to find support for this separation of concerns, especially with frameworks like React that are blurring the edges.

@loganfranken
Copy link
Contributor Author

I'll work on putting together some tests for this!

@loganfranken
Copy link
Contributor Author

Here are some tests specifically for icon fonts:
http://loganfranken.github.io/web-standards-testing/icon-font-replacement/index.html

@tenken
Copy link
Contributor

tenken commented Jul 6, 2015

I haven't had much coffee yet. But, 1 of the concerns my co-workers have regarding this is that for example campus fonts for UCSB logos are Minion and Fruteger. So some of the designers on campus prefer to see these fonts used in Logos for websites.

We even use 1 of them now on the webguide, as an image:
http://webguide.ucsb.edu/ucsb-graphic-identity/

So while I can see the merits of AT readability and accessibility -- I also see concerns of maintaining graphic identity while using these techniques because I believe for example a version of Minion is not available unless your department has access to a non-free font embedding service (as opposed to say Google Fonts free fronts):
https://typekit.com/fonts/minion-pro

So while all your points are accurate there may be client and identity proponents wthin a project that may be against this type of technique for aesthetic reasons.

@loganfranken
Copy link
Contributor Author

Hey @tenken:

Sorry, I might have made this confusing: regarding your example, that's actually the perfect case of when image replacement should be used; you could create a a logo image using Minion/Frutiger and then use image replacement to replace a text-only version with that logo.

For example, the web guide uses this right now for the header image:
http://www.ucsb.edu/webguide/

The actual HTML is as follows:

<h1><a href=".">UC Santa Barbara Web Standards</a></h1>

With the following CSS to perform the image replacement:

h1 a {
  background-image: url(../images/header.png);
  float: left;
  height: 88px;
  width: 290px;
}

h1 a {
  background-color: transparent;
  background-repeat: no-repeat;
  border: 0;
  direction: ltr;
  display: block;
  text-align: left;
  text-indent: -999em;
  overflow: hidden;
}

So the idea is that image replacement allows you to (1) maintain graphic identity and (2) accessibility.

I created this specific issue to explore two areas:

  1. Whether or not we should provide image replacement recommendations within the web guide
  2. Whether or not image replacement-style techniques are still applicable with icon fonts/SVG icons

@ericmayes
Copy link
Collaborator

One other problem with image replacement is that CSS background images disappear when a high contrast theme is enabled within Windows. It brings up the case in which a site logo should actually be rendered inline, and without an h1 surrounding it. Its another older way of thinking, but something that is still relevant. This article (from 2010) brings up some good points about image replacement and logos

http://csswizardry.com/2010/10/your-logo-is-an-image-not-a-h1/

I notice newly released sites such as simplyaccessible.com using this approach of an inline image for the main logo with no surrounding H1. It seems like an icon font would be an even better option if possible, coupled with an ARIA label or pushing the text out of the way as suggested by @loganfranken. I've asked the head of simplyaccessible.com his thoughts on the matter via Twitter. He is the accessibility expert UCOP hired to create trainings for all of the UC. Hopefully we will get some of his insight on the icon font part of this question.

@loganfranken
Copy link
Contributor Author

Alright, I finally got around to running these tests (it is a wild Saturday night):
http://loganfranken.github.io/web-standards-testing/icon-font-replacement/results.html

(@ericmayes, if you get a chance, would you mind checking them out in Voiceover too? Totally understand if you're too busy, though!)

As expected from our exploits in #30, title and aria-label worked just as well as having the text within the element itself.

And the example without any text (an approach promoted on the example pages for both Font Awesome and Twitter Bootstrap) was, of course, completely silent.

All of this is to say that, for the benefit of screen readers, you need to at least provide an aria-label attribute on the element that houses the icon unless there is accompanying text that explains the purpose of the icon.

In other words, this:

<a href="#" class="fa fa-bars"></a>

Should at the very least be this:

<a href="#" class="fa fa-bars" aria-label="Menu"></a>

Since the former example leaves screen reader users with nothing.

The next question is whether or not there is value in using an image replacement-style technique to have this:

<a href="#" class="fa fa-bars">Menu</a>

This would mean that the link is now being used "properly" instead of introducing aria-label to handle behavior that was already handled by a regular old link in the first place. This also has the additional benefits of (1) upholding the separation of concerns between HTML and CSS, (2) providing you more control over the element from CSS, and (3) handling non-CSS situations (as @ericmayes referenced).

Obviously, I'm for the icon replacement angle, but it's a hard sell these days: arguing for the "proper" use of elements is pretty academic and separation of concerns is kind of going out the window in this brave new world of declarative markup and JavaScript-heavy client-side frameworks.

I'll think a little more about it, but would love to hear all of your thoughts too.

@loganfranken
Copy link
Contributor Author

Alright, sorry for the self-promotion, but I ended up writing a lengthy blog post exploring this issue:
http://www.loganfranken.com/blog/1244/do-we-still-need-image-replacement/

Here's a summary of the findings from that post:

Case Study: SVG Logos

Basically, I wanted to explore two things:

  • Does the age-old image replacement technique still have any value?
  • If so, does it have value specifically with the use of SVG?

To do that, I cooked up some test cases.

I discovered that using image replacement still has a slight edge over just straight embedding the image.

This is because the following...

<h1 class="image-replacement image-replacement-png">Website Name</h1>
<h1 class="image-replacement image-replacement-svg">Website Name</h1>

...get read by screen readers as "Header, Level 1, Website Name." While the following...

<h1><img src="logo.png" alt="Website Name" /></h1>
<h1><img src="logo.svg" alt="Website Name" /></h1>

...get read by screen readers as "Header, Level 1, Graphic, Website Name."

Given this slight usability improvement for screen readers and the fact that image replacement upholds the separation of concerns between HTML and CSS, I found image replacement still has value, including with SVG.

Case Study: Icon Fonts

Second (this is a reiteration of the findings above), I wanted to see whether or not image replacement-style techniques should be used with icon fonts.

Again, I cooked up some test cases:

<!-- Standard Link -->
<a href="#">Menu</a>

<!-- Standard Phark Image Replacement -->
<a href="#" class="image-replacement">Menu</a>

<!-- Standard Font Icon with Accompanying Text -->
<a href="#"><i class="fa fa-bars"></i> Menu</a>

<!-- Standard Font Icon -->
<a href="#" class="fa fa-bars"></a>

<!-- Font Icon With aria-label -->
<a href="#" class="fa fa-bars" aria-label="Menu"></a>

<!-- Font Icon With title -->
<a href="#" class="fa fa-bars" title="Menu"></a>

<!-- Font Icon Using Replacement -->
<a href="#" class="icon menu-icon">Menu</a>

All of these, except for "Standard Font Icon," got read by the screen readers as "Menu."

If it comes down to title versus aria-label, we already found that aria-label is preferred in #30.

I personally like controlling these icons through CSS, so I prefer using image replacement-style techniques to swap out the text with icon fonts, but I think it's hard selling this to people since aria-label does the job here.

So, altogether: aria-label should be used with icon fonts that have no accompanying text.

@loganfranken
Copy link
Contributor Author

As far as the Web Standards Guide, I would like to add the following to the wiki (with a possible section in the actual guide in the future):

  • Explanation of image replacement techniques
  • Explanation of how to use font icons in an accessible way

I think that should capture all of the research in this post.

Definitely let me know if you have any suggestions/criticisms/concerns/etc!

@loganfranken
Copy link
Contributor Author

Taking a closer look (i.e. not being an idiot and looking in the right places), I found that both Twitter Bootstrap and Zurb Foundation include aria-label examples for icon fonts without supplemental text.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants