A.K.A.
Symbol
Examples


Examples of Glyph Font Icons on Buttons with Labels


Problem
The system needs to present a way for the user to access commonly used functions like saving work, printing, emailing, etc., yet space on the interface is too limited to permit buttons containing text.
Solution
Display a small graphic (an icon) that looks clickable and communicates the meaning of the feature functionality with the image itself.
How to Use
Use when…
Conditions for using an icon — All of the following conditions should be present to warrant using a functional icon
- Space is too limited to permit a text-based interaction element (e.g. button or link).
- The feature functionality is common enough to be recognizable in icon form.
- The feature functionality is based on a single concept (e.g. save, print, email, etc.).
- The proposed location for the icon is a location in the interface where the user would expect access to the feature functionality to exist.
Don’t use when…
Do not use an icon if all of the above conditions cannot be met.
Interaction Acceptance Criteria
Common Defaults
Basic Display – Functional Icon defaults should adhere to the following parameters:- The icon should be visually recognizable as a relatively small, high contrast, graphic element.
- The icon may be monochromatic or full color depending on context (see Conditional Defaults).
- The icon may or may not have an associated label depending on context (see Conditional Defaults). The icon may be an image or a glyph font depending on context (see Conditional Defaults).
- The icon's size will vary depending on context (see Conditional Defaults).
- The icon should always be a directly selectable (clickable) object and should never be only engaged on mouseover.
- The icon will always be coded to either be hidden to screen readers or present a text equivalent of its meaning to screen readers depending on context (see Conditional Defaults and Accessibility Requirements).
- The icon's selection interaction will yield a different interaction type depending on context (see Conditional Defaults).
Conditional Defaults
Common Conditions
Condition – IF the icon being used is a glyph font and has no associated label:- The actually icon text character must be hidden to screen readers.
- IF the glyph font icon appears with no associated label, a text equivalent specific to its contextual meaning must be supplied in a neighboring span tag.
- The icon should be within proximity to the label by no more than 10 pixels. The actually icon text character must be hidden to screen readers.
- The icon link must be hidden from screen readers.
- A text equivalent specific to its contextual meaning should not be present.
- The icon image should not present a containing blue box.
- The icon image must include the "alt" attribute with text specific to its contextual meaning.
- The icon image should not present a containing blue box.
- The icon image must include the "alt" attribute with its value blank (alt="").
Conditions Specific to Feature Level Design (The parameters of this condition must be defined in the feature level design)
Condition – IF the icon is associated with the product name:- The associated product icon should precede the product name.
- The icon will display in the appropriate colors for product branding.
- The icon image must include the "alt" attribute with its value blank (alt="").
- The icon size will be determined by feature level requirements.
- The icon placement will be determined by feature level requirements.
Interaction Behavior
IF the user clicks on the icon:- The functionality associated with the icon is executed.
- The functionality associated with the icon is executed.
Rationale
User Perception and Recognition
The Premise of Visual Recognition — The use of icons is predicated on the idea that the concepts represented by the icon will be interchangeably understandable to the user as if they had encountered the same concept represented expressed in text. This means that the icon is only successful if the label is not necessary for understanding. It also means that users should be able to understand its meaning without having to remember it from the last time the discovered its meaning through usage. User interface elements should always follow the primary heuristic of recognition rather than recall.
Conceptual Expression Limitations — The essential requirement of a functional icon is its ability communicate the nature of the feature functionality based on the graphic alone, without any supporting text. Given that the available space functional icons is almost always small (commonly 16 x 16 pixels), icon graphics are very limited in the number of concepts they can present. The most successful icons only express a single concept, commonly in verb form (e.g. save, print, email). As additional concepts are added (e.g. Save as website), the ability for the icon to effectively communicate the functionality quickly diminishes. To illustrate this point, consider the following set of icons representing documents, appearing here in order from simple to complex:
Document — This icon represents the single concept of “a document.” The image is easily recognizable as a document, instantaneously communicating the expected result of clicking on it: Opening a document.
Word Document — This icon represents two concepts: It’s a document and one from Microsoft Word. The image is somewhat recognizable as a document as it is partially obscured by the “Word” concept. Recognition of the meaning of this object is partially dependent on repeated usage.
Word Web Document — This icon represents three concepts: It’s a document, it’s a Word document, and one that is a Web based document. At 16 x 16 pixels, the three image elements of the document, the “W” (for Word), and the globe (for the Web) are barely recognizable. Only the “W” stands out as the top most element. Recognition of the meaning of this object is almost entirely dependent on repeated usage, and only within the context of those user who use Microsoft Word.
Word Web Document with Embedded Images — This icon represents for concepts: It’s a document, it’s a Word document, one that is a Web based document with images embedded, not referenced. At 16 x 16 pixels, the icon cannot even display all four concepts as images. The image of the document is present, though completely obscured. The globe (for the Web) is entirely missing. The picture frame, representing embedded images, is not visible enough to be recognizable. For most Word users, this image represents little more than a “Word something” and is entirely dependent on repeated usage or a explanatory label.
The Role of Perception — As human beings, only about 1/1000 of 1% of visual information survives our short term memories. When make up the difference with information from other sources:
· We remember most what interests us most.
· If multiple interpretations are possible, we first assume an image to be the one which is most familiar to us, especially images that carry archetypal meanings.
· We fill in visual gaps to perceive a familiar object, even if it wasn’t intended.
· We are influenced by what our sub conscience interprets and infers.
· We interpret meaning of images, especially simple ones, based on the context in which they appear.
If these aspects of human perception are not taken into account, an icon is far more likely to fail than succeed it communicating it’s meaning.
The Influence of Archetypal Images — In Jungian psychology, an inherited pattern of thought or symbolic imagery derived from the past collective experience and present in the individual unconscious. Consider the following image:
Even in black, this simple graphic will always communicate the sun on the horizon, perhaps even the more complex concept of “a new day.” Such powerful archetypal images must be taken into account when creating an icon. As much as you may try to frame the icon as being something else, the archetype will always win.
The Influence of Context — The context in which an icon appears can greatly influence perception. Consider the following icon:
In a hospital hallway, this icon would most likely be perceived as meaning Restaurant or Cafe. On a restaurant menu, it would more likely be perceived as Beverages. In a grocery store, the icon would probably be perceived as Coffee, unless that store is an a country that primarily drinks tea, in which case, Tea would be the first interpretation. The same contextual limitations come into play in an interface. Icons may easily carry different meanings in a tool bar than they would on the page.
The Influence of Other Icons — An icon appearing by itself can carry a different meaning than when it appears adjacent to other icons. Consider how the airplane icon below changes in meaning when placed next to other icons:
The airplane icon changes its perceived meaning when it is placed next to other related icons, even another version of itself.
The Influence of Established Common Computer Interfaces — Some icons are so ubiquitous in common user interfaces, their established meaning simply cannot be changed. This also means that the concept represented by that icon cannot be communicated with any other icon other than the established icon. One of the most glaring examples of this phenomenon is the icon used for Save, as in saving a document:
The image represented in this icon is a three and half inch floppy disk, a method of saving files that is so outdated and obsolete, that many users of a younger generation would not recognize it. Yet, it is so ubiquitously used in user interfaces to mean Save, designers dare not use any other icon in its place, nor should they dare using the icon to represent any other functionality than Save.
Usability and User Research
Microsoft Recognizes That Labels Work Better Than Icons:
What follows is an article from a former Microsoft Program Manager who witnessed usability testing on Microsoft Outlook. In the article, he reports on the significance of the findings regarding the toolbar icons.
My first experience in Office was working as an intern program manager on Outlook 98. During that summer I learned one of the key usability lessons that carried over into the DNA of the Ribbon: the importance of labels.
Different fixes were tried: new icons, rearrangement of the icons, positioning icons under the menus from which the commands came from. In the end, one change caused a total turnaround: labeling the important toolbar buttons. Almost immediately, the toolbars were a big hit and everyone at all skill levels starting using them.

It’s not really any big surprise if you think about it. It’s pretty rare in the real world that we rely on iconography alone to represent ideas. Bathroom doors generally have an icon of a man and the word “Men.” Stop signs have the word “Stop” on them. On the other hand, I can recount dozens of experiences where the icon-only design of something has frustrated me. On a recent vacation, we spent probably 10 minutes trying to figure out how to turn an oven on before just giving up because we couldn’t tell what any of the icons meant. I have buttons in my car that I have no idea what they do because the icon is so cryptic. I guess I could look them up in the manual…
It’s not that icons can’t work by themselves, but that most people have a fairly limited vocabulary. Floppy disk = save. Printer = print. Play, Pause, Stop, Forward, Back all got defined by tape players from the 1980s. And, yes, if an icon is ideographic enough, it can be infused with meaning and remembered–take the “Apple” menu in Mac OS, for example. But the richness is just not there relative to human language. (Especially considering that I already know how to speak English; it’s a lot of work to learn how to speak “Iconese” on top of that.)
This is one of those areas in which Windows applications should learn from web design. Why do people find many web sites straightforward to use? One reason undoubtedly is because everything is labeled. People never need to decipher cryptic rows of 16×16 unlabeled icons in order to be successful using a web site. Yet, the unlabeled toolbar remains a staple of most Windows programs today.
Web sites do often pay for their verbosity by requiring visitors to scroll the page in order to see the entire content area. Toolbars, on the other hand, have the advantage of extreme density and more predictable layout.
The Office 12 Ribbon is designed to exploit the importance of labels in a way that doesn’t compromise the predictability of a fixed UI location at the top of the screen.
We designed a layout and scaling system to provide as many opportunities to label commands as possible–especially as screen resolutions increase. At the same time, the rich layouts of the Ribbon allow the density afforded by skipping labels on those items which work just as well as unlabeled icons (Bold, Italic, Center, etc.)
I hope the days in which rows of 16×16 unlabeled icons represent “standard UI” will soon be in the past.
(Citation)
[/expand]
A Case Study of How Icons Can Be Misconstrued
In 1995, Nielsen Norman Group tested several iterations of icons for Sun Microsystems. The finding underscore the importance of simplicity and validate many of the guidelines presented in the design pattern.
http://www.nngroup.com/articles/icon-usability-1995-sun-microsystems-website/
International Considerations
Icons Can Have Different Meaning in Different Cultures
It is very important to remember that icons can carry different meanings in different cultures. While a print icon can be cross-cultural because it’s based on the image of an actual printer, a common device in all countries, icons that depend on metaphor can easily convey an unintended meaning in a different culture. Icons that attempt to communicate carry multiple concepts (or even single concepts) based on metaphor must be evaluated across all applicable cultures to validate that the intended meaning is being communicated effectively.
Accessibility Requirements
Requirements Specific to Functional Icons
Regardless of whether the icon is a glyph font or an image, all icons presented in the interface require some level of intervention to allow the application to meet accessibility requirements.IF the icon is presented as a glyph font with no associated text-based label:
- The actual icon text character must be hidden to screen readers.
- A text equivalent specific to the icon's contextual meaning must be supplied in a neighboring span tag using the "sr-only" CSS class.
<a href="#"> <span class="icon-nav"> <span class="icon-calendar" aria-hidden="true"></span> <span class="sr-only">Calendar</span> </span> </a>In the above example:
- The "icon-nav" span creates the clickable item.
- The "icon-calendar" span supplies the visually based icon.
- The "icon-calendar" span also hides the glyph character from screen readers using the aria-hidden attribute.
- The "sr-only" span supplies the screen reader with the appropriate text to read aloud.
.sronly { position: absolute; width: 1px; height: 1px; margin: 1px; padding: 0; overflow: hidden; clip: rect(0, 0, 0, 0); border: 0; }
If the icon is presented as a glyph font WITH associated linked text:
- The actual icon text character and its associated link must be hidden to screen readers.
- A text equivalent specific to its contextual meaning should not be supplied.
<div class="icon-array"> <span class="icon-nav"> <span class="icon-selected"> <a href="#" aria-hidden="true"> <span class="icon-info" aria-hidden="true"></span> </a> <a href="#"> <span class="nav">Task Status</span> </a> </span> </span> <span class="icon-nav"> <a href="#" aria-hidden="true"> <span class="icon-calendar" aria-hidden="true"></span> </a> <a href="#"> <span class="nav">Calendar</span> </a> </span> <span class="icon-nav"> <a href="#" aria-hidden="true"> <span class="icon-attach" aria-hidden="true"></span> </a> <a href="#"> <span class="nav">Attachments</span> </a> </span> <span class="icon-nav"> <a href="#" aria-hidden="true"> <span class="icon-back-in-time" aria-hidden="true"></span> </a> <a href="#"> <span class="nav">History</span> </a> </span> <span class="icon-nav"> <a href="#" aria-hidden="true"> <span class="icon-comment" aria-hidden="true"></span> </a> <a href="#"> <span class="nav">Comments</span> </a> </span> </div>In the above example:
- The "a" tag for icon and the "a" tag for the associated text make duplicate clickable objects.
- The "a" tag for the icon and the icon itself are hidden from screen readers using the aria-hidden attribute while for sighted users, the icon is still clickable.
- The actually icon text character must be hidden to screen readers.
- A text equivalent specific to its contextual meaning should not be supplied.
<button class="btnDefault-left"> <span class="icon-angle-left" aria-hidden="true"></span> <span class="prev-next-text">Previous</span> </button>In the above example:
- The "button" tag creates the clickable object.
- The "icon-angle-left" span supplies the visually-based icon.
- The "icon-angle-left" span also hides the glyph character from screen readers using the aria-hidden attribute.
- The "prev-next-text" span presents the the text in the button that is also read aloud by the screen reader.
IF the icon is presented as an image with no associated text-based label:
- The linked image must include the "alt" attribute with the text equivalent specific to its contextual meaning.
<a href="http://www.w3.org/"> <img src="http://www.w3.org/WAI/tutorials/img/w3c-796023c4.png" alt="W3C home"> </a>In the above example:
- The "a" tag surrounding the image tag creates the clickable object.
- The "alt" attribute in the image tag supplies the alternate text that is read aloud by the screen reader.
The Image “Alt” Property Must Be Included
Because icons exist as images that initiate functionality, all functional icons must include text in the image “alt” property that informs the users as to what functionality the icon initiates.
Related Patterns
- Icon (Graphical)
Be First to Comment