-
Notifications
You must be signed in to change notification settings - Fork 7
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
Comments
This is way over my head, but I have in the past used a |
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"):
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. |
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. AccessibilityBy 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. FlexibilityBy 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. |
I'll work on putting together some tests for this! |
Here are some tests specifically for icon fonts: |
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: 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): 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. |
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: 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:
|
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. |
Alright, I finally got around to running these tests (it is a wild Saturday night): (@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, 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 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 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. |
Alright, sorry for the self-promotion, but I ended up writing a lengthy blog post exploring this issue: Here's a summary of the findings from that post: Case Study: SVG LogosBasically, I wanted to explore two things:
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 FontsSecond (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 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 So, altogether: |
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):
I think that should capture all of the research in this post. Definitely let me know if you have any suggestions/criticisms/concerns/etc! |
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 |
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:
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:
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:
The
a
andspan
elements in this case serve as hooks for GitHub's icon font. If you wanted, though, you could easily have something like the following: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 emptyspan
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!
The text was updated successfully, but these errors were encountered: