This sounds good.
I prefer accessibility-profile rather than user-profile because that
sounds too generic.
In this example:
@accessibility-profile high-contrast, low-vision {
/* high-contrast/low-vision styles here */
}
did you mean?
@accessibility-profile high-contrast, large-fonts {
/* high-contrast/large-fonts styles here */
}
Matt Cooper wrote:
Sounds good to me. Thank you Andy! :)
On Thu, Feb 14, 2008 at 10:50 AM, Andy Schwartz
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Gang -
I am hoping to pick this up where Matt left off and see if I can
provide a solution. There are two problems that I am hoping to
address:
1. High contrast content: Skin styles or icons may need to be tweaked
for users who require high contrast-friendly content. In some cases
it may also be necessary to tweak the rendered HTML content itself (as
opposed to just tweaking styles/icons), eg. add affordances to the UI
to assist high contrast users.
2. Low vision content: The issue here is that for users with low
vision it would be nice to both bump up the default font size to a
more reasonable value (eg. "medium" instead of "x-small" on IE), and
also avoid sizing text smaller than some reasonable minimum (eg.
anything smaller than the default font size gets cranked up to the
default font size). There may also be cases where it may be useful to
tweak rendered content to provide content which is more friendly to
users who want to scale up the font size.
Matt has already provided a basic outline of the solution. Refining
that a bit, I think we want to do the following:
- Add a new RequestContext.AccessibilityProfile API which provides
access to finer grained accessibility preferences (ie. finer-grained
than the current accessibility "mode").
- Provide access to the AccessibilityProfile via a new
RequestContext.getAccessibilityProfile() API.
- Expose a new <accessibility-profile> configuration parameter in
trinidad-config.xml.
- Enhance skinning to support a new "@accessibility-profile"
constraint.
The AccessibilityProfile API would initially support the two
preferences described above. In terms of APIs, note that we should
avoid referring to specific disabilities directly, but rather use
names which refer to the functionality that we are providing. For
example, we want to avoid using the term "low vision" in our API.
Instead of "low vision" we want something that says "I don't want the
normal default/small fonts" - I was thinking we could call this
preference something like "large fonts". (I believe there is some
precendent for this sort of terminology - checking with our
accessibility experts on that.)
If we go this route, we could have a couple of boolean properties
hanging off of the AccessibilityProfile, eg:
public static class AccessibilityProfile
{
public boolean isHighContrast();
public boolean isLargeFonts();
}
Alternatively, if people would prefer to have room to expand, we could
make these return enumerations instead of booleans, though I see these
properties as being either on or off - ie. I don't see the need for
low contrast, or small fonts options, but I am open to other opinions.
The trinidad-config API would be a simple list of preferences. For
example, to enable high contrast support:
<accessibility-profile>high-contrast</accessibility-profile>
Or to enable both high contrast and large fonts:
<accessibility-profile>high-contrast
large-fonts</accessibility-profile>
Note that typically this value will be EL-bound to a user-provided
preference (like <accessibility-mode>).
Finally, on the skinning side, we would need to support customizations
along the lines of:
@accessibility-profile high-contrast {
/* high-contrast styles here */
}
Or, for styles that apply in either the high contrast or the large
font case:
@accessibility-profile high-contrast, low-vision {
/* high-contrast/low-vision styles here */
}
One high-level question about the API... While our current
requirements our focused on accessibility-specific issues, this
mechanism could be used for general-purposes user preferences (not
limited to accessibility). As such, we could go with a more general
name - eg. replace "accessibility" with "user" in all of the APIs
above (UserProfile, <user-profile>, @user-profile).
Thoughts?
Andy
