Re: [Trinidad] Adding additional accessibility features to skinning
Gang - Just a heads up that I finally managed to get around to submitting a patch for TRINIDAD-822. The solution is pretty much along the lines that we discussed in this email thread. I did decide to go with enum properties on the AccessibilityProfile API rather than booleans, though I cheated a bit by adding boolean-based convenience methods. If you are curious about the details of the implementation, feel free to have a peek at the patch! Andy
Re: [Trinidad] Adding additional accessibility features to skinning
Thank you Andy On Tue, Apr 1, 2008 at 9:59 AM, Andy Schwartz [EMAIL PROTECTED] wrote: Gang - Just a heads up that I finally managed to get around to submitting a patch for TRINIDAD-822. The solution is pretty much along the lines that we discussed in this email thread. I did decide to go with enum properties on the AccessibilityProfile API rather than booleans, though I cheated a bit by adding boolean-based convenience methods. If you are curious about the details of the implementation, feel free to have a peek at the patch! Andy
Re: [Trinidad] Adding additional accessibility features to skinning
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-profilehigh-contrast/accessibility-profile
Or to enable both high contrast and large fonts:
accessibility-profilehigh-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
Re: [Trinidad] Adding additional accessibility features to skinning
Sounds good to me. Thank you Andy! :)
On Thu, Feb 14, 2008 at 10:50 AM, Andy Schwartz [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-profilehigh-contrast/accessibility-profile
Or to enable both high contrast and large fonts:
accessibility-profilehigh-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
Re: [Trinidad] Adding additional accessibility features to skinning
On Thu, Feb 14, 2008 at 3:24 PM, Jeanne Waldman
[EMAIL PROTECTED] wrote:
This sounds good.
I prefer accessibility-profile rather than user-profile because that
sounds too generic.
Sure, I'll go with accessibility rather than user unless I hear
any strong objections.
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 */
D'oh! Yep, that's right.
Thanks Jeanne!
Andy
Re: [Trinidad] Adding additional accessibility features to skinning
Okay, we'll skip them for now and can reconsider later if people start
asking for it.
On Nov 27, 2007 2:54 PM, Jeanne Waldman [EMAIL PROTECTED] wrote:
I don't know off the top of my head, but you can test this with the
@agent style.
If the base skin has @agent ie {.foo {some css properties}} and the
extending skin has .foo not inside the @agent block, for ie, does this
style get overridden?
It is probably the case that they do get overwritten, in which case, I
see your point, but we don't do that same thing for the other @rules.
It makes the skin more complicated as well.
Matt Cooper wrote:
Hi Jeanne,
The any-* types are for users that do not require specific
consideration. It is useful because then someone could define some
styles without worry of negatively impacting users with special needs.
In particular, it is most useful for people that extend skins. If
you are making a skin from scratch you can just use the defaults but
if you don't want to override the painstakingly crafted styles for
special needs users then any-* would give you this power.
Is there another mechanism that exists today that would provide you this
power?
Thank you,
Matt
On Nov 19, 2007 3:58 PM, Jeanne Waldman [EMAIL PROTECTED]
wrote:
Hi Matt,
I don't understand how any-* works. It seems like this is the 'default'
which means there is no @accessibility-policy needed around the block
of
css.
I don't understand your example of how this is useful. Can you
elaborate?
Thanks,
- Jeanne
Matt Cooper wrote:
I've logged an improvement request for the following issue:
https://issues.apache.org/jira/browse/TRINIDAD-822
Before I start working on this, I wanted to gather feedback from you
all.
Thank you,
Matt
Re: [Trinidad] Adding additional accessibility features to skinning
I don't know off the top of my head, but you can test this with the
@agent style.
If the base skin has @agent ie {.foo {some css properties}} and the
extending skin has .foo not inside the @agent block, for ie, does this
style get overridden?
It is probably the case that they do get overwritten, in which case, I
see your point, but we don't do that same thing for the other @rules.
It makes the skin more complicated as well.
Matt Cooper wrote:
Hi Jeanne,
The any-* types are for users that do not require specific
consideration. It is useful because then someone could define some
styles without worry of negatively impacting users with special needs.
In particular, it is most useful for people that extend skins. If
you are making a skin from scratch you can just use the defaults but
if you don't want to override the painstakingly crafted styles for
special needs users then any-* would give you this power.
Is there another mechanism that exists today that would provide you this power?
Thank you,
Matt
On Nov 19, 2007 3:58 PM, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi Matt,
I don't understand how any-* works. It seems like this is the 'default'
which means there is no @accessibility-policy needed around the block of
css.
I don't understand your example of how this is useful. Can you elaborate?
Thanks,
- Jeanne
Matt Cooper wrote:
I've logged an improvement request for the following issue:
https://issues.apache.org/jira/browse/TRINIDAD-822
Before I start working on this, I wanted to gather feedback from you all.
Thank you,
Matt
Re: [Trinidad] Adding additional accessibility features to skinning
Hi Jeanne, The any-* types are for users that do not require specific consideration. It is useful because then someone could define some styles without worry of negatively impacting users with special needs. In particular, it is most useful for people that extend skins. If you are making a skin from scratch you can just use the defaults but if you don't want to override the painstakingly crafted styles for special needs users then any-* would give you this power. Is there another mechanism that exists today that would provide you this power? Thank you, Matt On Nov 19, 2007 3:58 PM, Jeanne Waldman [EMAIL PROTECTED] wrote: Hi Matt, I don't understand how any-* works. It seems like this is the 'default' which means there is no @accessibility-policy needed around the block of css. I don't understand your example of how this is useful. Can you elaborate? Thanks, - Jeanne Matt Cooper wrote: I've logged an improvement request for the following issue: https://issues.apache.org/jira/browse/TRINIDAD-822 Before I start working on this, I wanted to gather feedback from you all. Thank you, Matt
Re: [Trinidad] Adding additional accessibility features to skinning
Hi Matt, I don't understand how any-* works. It seems like this is the 'default' which means there is no @accessibility-policy needed around the block of css. I don't understand your example of how this is useful. Can you elaborate? Thanks, - Jeanne Matt Cooper wrote: I've logged an improvement request for the following issue: https://issues.apache.org/jira/browse/TRINIDAD-822 Before I start working on this, I wanted to gather feedback from you all. Thank you, Matt
[Trinidad] Adding additional accessibility features to skinning
I've logged an improvement request for the following issue: https://issues.apache.org/jira/browse/TRINIDAD-822 Before I start working on this, I wanted to gather feedback from you all. Thank you, Matt
