Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • Calibri for headings, with Arial as a fallback
  • Arial for everything else.


Deck of Cards
labelAbout the elements

About the elements


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


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. We recommend 15px, which is the same size as this paragraph.

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


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 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 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.


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 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 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.


Please see the Buttons component specification for more information.


Please see the Iconography component specification for more information.

labelTypography recommendations

Typography recommendations


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.


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.


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.


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.


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.



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"


When using a legend, we advise...

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


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.


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.


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.


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.


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

labelAccessibility Considerations

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

Accessibility Resources

W3 HTML Validator
WebAim WAVE 

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.