myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Schwartz (JIRA)" <>
Subject [jira] Updated: (TRINIDAD-822) Add additional accessibility features to skinning
Date Tue, 01 Apr 2008 15:56:24 GMT


Andy Schwartz updated TRINIDAD-822:

    Status: Patch Available  (was: Open)

> Add additional accessibility features to skinning
> -------------------------------------------------
>                 Key: TRINIDAD-822
>                 URL:
>             Project: MyFaces Trinidad
>          Issue Type: Improvement
>          Components: Skinning
>    Affects Versions: 1.0.5-core, 1.2.4-core
>            Reporter: Matt Cooper
>            Assignee: Matt Cooper
>         Attachments: TRINIDAD-822-1.2.x.patch
> It is important to be able to define skin settings based on accessibility policies such
> @accessibility-policy [low-vision, any-vision, high-contrast, any-contrast, keyboard,
mouse, touch]
> If this is added then a corresponding accessibility-policy property/object for trinidad-config.xml
would be needed.  There is an existing accessibility-mode property/object available today
so we may want to incorporate that or otherwise deprecate it if it is not possible to use
it to enumerate all of the possible combinations of the above noted policies.
> Basically people should be able to define skin properties specific to accessibility needs.
 In the past the answer was to create a separate skin for each need but it is becoming apparent
that this is not ideal.  Take this scenario for example:
> The Apache MyFaces Trinidad community has spent a lot of effort working on a skin that
meets all of the accessibility requirements of their customers.  You're a random customer
of Trinidad, working on making an app for your own organization and don't have the resources
or expertise to make a skin that meets the same needs on your own.  You are happy with most
of what the default skin provides but you really just want to make some minor color, image,
and font changes to match your organization's branding.  You really just want to extend the
provided skin and don't want to risk breaking accessibility needs.  If you change the base
styles, you'll be responsible for coming up with low-vision, high-contrast styles too.  If
you could somehow just change the styles that won't impact the special needs users then you
can make your skin extension with much less effort--the "any-contrast" and "any-vision" @accessibility-policy
would enable you to do this.  Or the inverse if some third party created a skin but you needed
to make some tweaks for high-contrast, low-vision, or touch-based entry users, etc.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message