• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

View
 

Vision and Goals

This version was saved 15 years, 10 months ago View current version     Page history
Saved by Ca-Phun Ung
on November 20, 2008 at 11:16:34 pm
 

jQuery UI provides developers with effects, interactions, low-level UI utilities and flexible, fuller-featured widgets that make use of these UI utilities to form common UI patterns.  We aim to provide a comprehensive set of accessible widgets and utilities in a jQuery-style, event-driven architecture (find something, manipulate it).

 

Since we're developing non-native HTML controls, widgets should be built in such a way that users on browsers and devices that are unable to support Javascript can still interact with the website or application. Most of the current set of UI widgets follow the best practice of progressive enhancement and we're working to extend that pattern to widgets that don't. In most cases, advanced components can be generated from HTML primitives (i.e. slider from select menu, radio set, or text input), and as the UI library paired with the most popular javascript library in the world, we should lead by example in this area. Any UI widget that sits within the flow of a form should be able to store data using semantic HTML elements so the form can be submitted or serialized normally.

 

Widgets should also be accessible to JS-capable users who have disabilities such as blindness or deafness (should we ever venture into the arena of audio/video integration, for instance). We attempt to make components accessible through the use of semantic HTML elements within components and following the guidelines specified in the WAI-ARIA spec. Any image-based actions within widgets should provide text equivalents (close icons, expand/collapse icons, etc. should have title attributes at the least).

 

Widgets should provide hooks to enable developers to customize both behavioral and presentational aspects. Transition animations should be optional and customizable. Class names used on internal elements should be meaningful to jQuery UI users and enable styling either through ThemeRoller or hand-written CSS (or hopefully both). jQuery UI components should follow the unobtrusive practices put forth by jQuery itself, and should attempt to be forward-looking in its attempts to normalize across browsers and devices (test for features/bugs, not browser sniffing).

Comments (0)

You don't have permission to comment on this page.