myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Cooper (JIRA)" <...@myfaces.apache.org>
Subject [jira] Created: (TRINIDAD-822) Add additonal accessibility features to skinning
Date Thu, 15 Nov 2007 20:39:43 GMT
Add additonal accessibility features to skinning
------------------------------------------------

                 Key: TRINIDAD-822
                 URL: https://issues.apache.org/jira/browse/TRINIDAD-822
             Project: MyFaces Trinidad
          Issue Type: Improvement
          Components: Skinning
    Affects Versions: 1.0.5-core, 1.2.4-core
            Reporter: Matt Cooper
            Assignee: Matt Cooper


It is important to be able to define skin settings based on accessibility policies such as:

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


Mime
View raw message