Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Task marked complete
Section
Column
width80%
Panel
bgColor#f6f6f6
titleBGColor#333333
borderStylesolid
titleTabbed containers
borderColor#cccccc
titleColorwhite

Purpose: This document provides usage and guidance on typography, links, headings, images, and more.

Category: Typography, content

Related jiras:

JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverKuali: Jira
serverIdbe3acfec-fcc2-335b-8051-b2b053a39956
keyUXI-402

Process Phase:

  •  UXI JIRA Created (insert link above)
  •  Component Specification draft complete
  •  UXI code review complete
  •  Reconcile with UIM and KRAD existing designs
  •  Conduct user testing (if needed)
  •  Routed for review with Kuali UX Working Group and UX/KRAD Working Group
  •  Reviewed with KAI
  •  Rice JIRA Created (in KULRICE Project)
  •  KRAD Implementation complete
  •  Component released (insert rice release version below)

Version: 1.0

 


Description

Typography makes up a key aspect of using the web or online applications. The content you read, how it's laid out, the contrast between fore and background, clarity between what's a link and what's not - all of this are things to consider when creating content. In short, typography is as important, if not more important, than the actual content.

Typography is made up of:

  • Headings
  • Paragraphs
  • Lists
  • Links
  • Images
  • Forms
    • Fieldsets
    • Legends
    • Labels
    • Inputs, Selects, Textareas
  • Buttons
  • Icons
Deck of Cards
idcomponent_details
startHiddenfalse
Card
idabout-elements
defaulttrue
labelAbout the elements

About the elements

Headings

Headings (<h1>, <h2>, <h3>, <h4>, <h5>, and <h6>) are important, and do the following to your interface:

  • Allow users to skim your content as they summarize what's below them
  • Provide better SEO by allowing search engines to show document structure
  • Provide structure and hierarchy
  • Allow easy navigation to screen readers

Paragraphs

This would be considered the main text style for your interface. Wrapped in <p> tags, paragraphs typically follow headings and provide context. A good rule of thumb for paragraph font sizing is to keep your font between 13px and 16px. Anything smaller than 13px and it becomes too small for users with vision impairments and aging eyes. Anything larger encroaches on heading font size and might add confusion. Browsers, without any CSS customizations, typically default to 16px.

Allow for ample breathing room between paragraphs and lines for increased readability.

Lists

Lists, both unordered and ordered, are used as line-item type of summaries. They are very versatile and when done correctly, can add a great deal of accessibility to your interface. Ordered lists contain items that flow linearly in an ordered fashion (1, 2, 3 and so on), whereas unordered lists don't have any specific order.

It's not uncommon these days to have navigational menus use lists for their structure. Screen readers will understand the number of items in the list and will announce the item of the total number providing additional semantic meaning.

Links are probably the Internet. They're what make the web, the web. As such, links should be treated with the importance that they are. Links should be clearly indicated (i.e., don't make links look like normal body copy or paragraph text). Additionally, don't make something look like a link that isn't a link as this also adds to confusion.

Images

Images are used to provide supplemental context to headings and paragraphs. It is important to note that images should not be used as the sole means of conveying information. If an image is used, there should be accompanying text that can be announced that describes the image. Additionally, alt attributes should be used in all cases except where the image is purely decorational.

Forms

Forms allow users to interact with an interface. In Kuali applications, they allow users to create and manipulate data and get work done. Ergo, they're pretty important. Forms are also one of the (needlessly) more problematic areas on the web for accessibility and usability. With so many visual customization options it's easy to "over-design" forms. As with all web elements, forms should be designed and developed with accessibility in mind.

FIeldsets

This widely underused but extremely powerful element allows developers to group like fields in forms. Beyond visual grouping (which is in itself optional) they provide semantic meaning to screen readers and structurally grouping like fields. The next element - the legend - helps provide context to the fieldset-grouped fields and so fieldsets should never be used without an accompanying legend element.

Legends

Legends are the first element found in fieldsets and provide a label for the grouped fields. For example, when dealing with a group of checkboxes, one might put them inside a fieldset with a legend being something like, "Choose your favorite fruits". When screen readers read this, rather than hearing a bunch of random fruits/checkboxes, they'll have context.

Labels

Labels are crucial to form accessibility and usability. Without labels, screen readers - and therefore users - would have no idea what a form field is for. One label should always accompany one form field. This is not to say that the label must always be visually present. In some cases it might be best to hide the label off-screen (i.e., absolutely positioned, not hidden).

Inputs, Select, Textareas

Forms would hardly be forms without form fields. These include text, textarea, select, checkboxes, radio buttons, and a whole slew of new input types, such as range, toggles, and more. Each input should have an accompanying label identifying what the form field is looking for.

One very, very important note regarding form fields: designers often like to hide or change the focus ring that is default to browsers. This makes it extremely difficult, if not impossible, for visually impaired or keyboard-only users to identify their location on the page. UXI advises not disabling or altering these focus rings.

Buttons

Please see the Buttons component specification for more information.

Icons

Please see the Iconography component specification for more information.

Card
idtype-recommendations
labelTypography recommendations

Typography recommendations

Headings

When using headings, we advise...

  • Maintain visual size hierarchy. An h1 should be bigger than an h2 which should be bigger than an h3. For headings h4, h5, and h6, you may use visual weight to differentiate level rather than size.
  • Maintain structural order. An h1 should come first and there should ideally only be one h1 on the page. You may have any number of h2's and so on, but only after the preceding structural heading has been used.
  • Do not style normal body copy or paragraph copy to look like a heading and do not use a heading as body or paragraph copy. If large text is needed within the body or a paragraph, create a custom CSS style for it, rather than using a heading element.
  • Headings are the only element which may use the Raleway font family.

Paragraphs

When adding content and creating paragraphs, we advise...

  • Keep your font size between 13px and 16px. Anything smaller presents readability and accessibility issues. Anything larger starts to approach heading sizes which is also confusing.
  • Maintain a proper contrast ratio. Use the WAVE tool (link below) to check and ensure your body copy is meeting the required accessibility guidelines.
  • Allow adequate breathing room between paragraphs and the lines within paragraphs to aid in readability. UXI recommends a line height of 140% / 1.4em for 13px body copy and 155% / 1.55em for 16px body copy.
  • Make sure there's enough space between paragraphs to differentiate paragraphs. Don't write your styles so that the breaks between paragraphs don't indicate two separate paragraphs.

Lists

When creating unordered and ordered lists, or data lists, we advise...

  • Use unordered lists for items that don't need a particular order. Use ordered lists for items that do have a specific order.
  • Lists are great for navigation and subnavigation as they provide semantic structure and are easily navigable.

Links

When making hyperlinks, either with text, buttons, or images, we advise...

  • Make sure links look like links and that they appear distinctly different from non-link elements. Don't make non-link elements look like links, and don't link things that aren't intended to be links.
  • Links, when focused with a keyboard or hovered with a mouse cursor, should provide two (2) visual cues that the item is being focused or hovered. This may mean applying an underline and a color change. In many cases, one visual cue isn't enough, especially in ways of color which may be indistinguishable to some.
  • Make sure your links provide context in the link itself. Avoid using "click here" or "view more" because these are meaningless out of context, which is how many screen readers announce links. Be descriptive.

Images

When inserting and using images in your interface, including icons, we advise...

  • HTML5's figure and figcaption elements are very powerful and should be used when inserting images.
  • Images should not be the sole means of conveying information. If an image is present and is relevant (i.e., not purely for decoration) it should not only have an alt attribute, but it should also have some accompanying context.
  • alt text should be no more than 160 characters, but it should briefly describe the image so users who can't see the image still get a sense of what it's depicting.

Forms

Fieldset

We advise to use a fieldset when:

  • Use a fieldset when there are form fields that need to be grouped. For example, "Shipping information" and "Billing information".
  • You may have fieldset's within fieldset's for even greater structure.
  • Use fieldset's when using checkbox or radio button groups.

And when using fieldset's we advise...

  • Using a legend that is descriptive, yet short. It should describe the "stuff" in
  • Group similar fields, such as, "Personal information" and "Shipping information"

Legends

When using a legend, we advise...

  • Using a legend that's descriptive, yet short. It should summarize or describe the "stuff" in the fieldset.

Labels

When using label's, we advise...

  • Use one label for every one form field. The label's for attribute should match the form fields' id.
  • The label should clearly identify the field (i.e., "First name", "Last name", "Email address")
  • Label's must be present, but may be hidden off-screen if not wanted visually.

Input...

The most commonly found types of inputs are:

  • input type="text" brings up a normal text input box
  • input type="email" a normal text input box, but on mobile will present the "@" and ".com" shortcut keys
  • input type="tel" is a normal text input box, but on mobile will present the numbered keypad for quick telephone number entry
  • input type="search" is a normal text input box with a search icon built in

And when using them, we advise...

  • Use id's that match their respective label's for attribute.
  • Use appropriate input type for better mobile usability. Browsers that don't understand the type will ignore it and present a normal text input.
  • When using placeholder's, make sure it doesn't look like a potential value. Include "example" or "i.e.". Placeholders are not announced to screen readers so make sure the label clearly describes the field and what is to go into the field.

Select

When using select menus, we advise...

  • Use id's that match their respective label's for attribute.
  • Since select menus aren't as visually configurable as inputs, if using a plugin to replace it, make sure the plugin is accessible. It should have the same functionality as a non-replaced (standard) select menu and all options and values should be announced clearly.
  • Don't use onchange events to navigate elsewhere or perform submissions. For this, use a button following the select menu.

Textarea

When using a textarea we advise...

  • Use id's that match their respective label's for attribute.
  • Make sure the textarea is at least two rows. Don't style it to look like an input.
Card
iddemos
labelDemos

Demos

View the JSFiddle for working examples of Kuali's typography and elements.

Card
idaccessibility
labelAccessibility Considerations
nextAfter0
Section

Accessibility Considerations

  • Body/Paragraph copy should be greater than or equal to 13px and less than or equal to 16px. Browser defaults to 16px.
  • Body/Paragraph contrast ratio for 13px font sized text should be at or above 4.5:1
  • Heading copy should be greater than 16px so as not to confuse it with body or paragraph copy.
  • Heading contrast ratio should be at or above 3:1.
  • Learn more at http://webaim.org/resources/contrastchecker/

Accessibility Resources

W3 HTML Validator
WebAim WAVE 

Card
idcomponent_discussion
titleResearch and Discussion
labelResearch & Discussion

Research and Discussion

Includes usability research findings and recommendations, information from the UIM discussion page, links, chapters, articles, etc that supports the design decision.