This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on any information on this page.
See Codex, the design system for Wikimedia instead.
Information about use of color, icons and other kinds of visual coding needs to be outlined here.
In general, there are six key aspects to a usable system, each with unique methods of measurement.
- Easy for new users to learn how to use. Learnability can be measured by observing how quickly a user can complete a task for the first time. If users are unable to complete the task, the system may be considered unlearnable. This aspect is critical for novice users.
- Easy for new users to remember how to use. Memorability can be measured by observing how quickly a user can complete a task for the first and comparing that with how quickly the user can complete the same task afterward. If the time required to complete the task does not decrease after continued use, the system may be considered unmemorable. This aspect is critical for infrequent users.
- Fast to use. Efficiency can be measured by observing how quickly a user can complete a task after learning it. If the time required to complete the task is unacceptable for the user's productivity needs or attention span the system may be considered inefficient. This aspect is critical for expert users.
- Difficult to use improperly. Failure resistance can be measured by observing frequency of user error while performing a task. If user error is observed to be common, the system may be considered prone to failure.
- Easy to recover from improper use. How forgiving a system is can be measured by observing how frequently user errors are recovered from. If unrecoverable user errors are found the system may be considered unforgiving. Users' ability to learn how to recover from an error is also a factor in the perception of the system being unforgiving.
- Enjoyable to use. Satisfaction can be measured by observing a users's willingness to repeat a task. If users are uninterested or unwilling to repeat a task, the system may be considered unsatisfying to use.
- Accessibility guide for developers has specific instructions instead of these generalities
The W3C has a comprehensive set of Web Content Accessibility Guidelines (WCAG). These guidelines, which help users with a variety of impairments participate on the internet, would ideally be conformed to whenever possible.
- Provide equivalent alternatives to auditory and visual content.
- Don't rely on color alone.
- Use markup and style sheets and do so properly.
- Clarify natural language usage
- Create tables that transform gracefully.
- Ensure that pages featuring new technologies transform gracefully.
- Ensure user control of time-sensitive content changes.
- Ensure direct accessibility of embedded user interfaces.
- Design for device-independence.
- Use interim solutions.
- Use W3C technologies and guidelines.
- Provide context and orientation information.
- Provide clear navigation mechanisms.
- Ensure that documents are clear and simple.
The W3C has a Web Accessibility Initiative (WAI), which is a continuation of the guidelines set forth in the WCAG. Accessibility for Rich Internet Applications (ARIA) describes a set of best practices and defines a set of embeddable markup "hints" which can be added to web applications to facilitate their use by interactive screen-reading software.
MediaWiki user interfaces are used on many kinds of computers by a diverse range of users, some with special needs, and all speaking a variety of languages. Special considerations must be taken into account when designing user interfaces which will support this scale of user diversity.
- Text scale
- User interfaces should allow text to scale up to 200% or down to 50% of its original size. Although many modern browsers default to scaling web-pages using a zoom technique, most still support scaling only text. Using "em" measurements in style sheets can ensure that user interface elements can scale together with text size changes where appropriate.
- Text flow
- User interfaces should allow for text to flow correctly in any language. Many languages exhibit extremely different text lengths for any given text written in English. Avoid using static widths combined with static heights, even if they are being set in "em" units; allow the browser's text-flow to determine either the width or height of a text container. Testing with a variety of extreme cases such as German, which is typically more lengthy and Chinese which is typically more brief, will help identify problem areas.
- Keyboard-only access
- Critical functionality should always be accessible via keyboard.
- Progressive enhancement
- User interfaces that take advantage of client-side scripting and styling should retain critical functionality with scripting and styling disabled.
- Right-to-Left language support
- User interfaces should allow for easy transition to right-to-left languages (e.g., Hebrew or Arabic).
- Support for the visually impaired
- In addition to text sizing, user interfaces should support the visually impaired in the following ways:
- Support screen-reader technology (e.g., correct use of “label” tags)
- Support/Control for the various types of color-blindness (protanopia, etc.)