jQuery UI provides developers with effects, interactions, low-elvel 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/collaps icons, etc. should have title attr's at the least).

Widgets should provide hooks to enable developers to customize both behaviorally and presentation-ally. 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).