[
https://issues.apache.org/jira/browse/TRINIDAD-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584192#action_12584192
]
Andy Schwartz commented on TRINIDAD-822:
----------------------------------------
The patch adds several new APIs:
- The AccessibilityProfile API provides access to accessibility preferences at
runtime.
- getAccessibilityProfile() methods have been added to RenderingContext,
RequestContext.
- trinidad-config.xml now supports an <accessibility-profile> configuration
element. This is a whitespace-separated list of accessibility profile options.
Currently the two available options are "high-contrast" and "large-fonts".
Typically this will just be an EL binding (like accessibility-mode).
- Skins now support @accessibility-profile rule, which allows "high-contrast"
and "large-fonts" as values.
Note that the AccessibilityProfile API currently exposes two properties:
1. Color contrast: This property indicates whether the user prefers high
contrast vs. default contrast content.
2. Font size: This property indicates whether the user prefers "large" fonts
vs. the default fonts.
Each of these properties are defined as enumerations, allowing for future
expansion.
Also added an "accdemo" skin, and an accessibilityPofileDemo.jspx page for
testing/demonstrating this new functionality.
> Add additional 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
> Attachments: TRINIDAD-822-1.2.x.patch
>
>
> 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.
