You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Matt Cooper <ma...@gmail.com> on 2007/11/15 21:50:37 UTC
[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
Re: [Trinidad] Adding additional accessibility features to skinning
Posted by Matt Cooper <ma...@gmail.com>.
Thank you Andy
On Tue, Apr 1, 2008 at 9:59 AM, Andy Schwartz <an...@gmail.com> 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
Posted by Andy Schwartz <an...@gmail.com>.
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
Posted by Andy Schwartz <an...@gmail.com>.
On Thu, Feb 14, 2008 at 3:24 PM, Jeanne Waldman
<je...@oracle.com> 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
Posted by Jeanne Waldman <je...@oracle.com>.
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
> <andy.g.schwartz@gmail.com <ma...@gmail.com>> 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
>
>
Re: [Trinidad] Adding additional accessibility features to skinning
Posted by Matt Cooper <ma...@gmail.com>.
Sounds good to me. Thank you Andy! :)
On Thu, Feb 14, 2008 at 10:50 AM, Andy Schwartz <an...@gmail.com>
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
>
Re: [Trinidad] Adding additional accessibility features to skinning
Posted by Andy Schwartz <an...@gmail.com>.
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
Re: [Trinidad] Adding additional accessibility features to skinning
Posted by Matt Cooper <ma...@gmail.com>.
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 <je...@oracle.com> 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 <je...@oracle.com>
> 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
Posted by Jeanne Waldman <je...@oracle.com>.
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 <je...@oracle.com> 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
Posted by Matt Cooper <ma...@gmail.com>.
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 <je...@oracle.com> 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
Posted by Jeanne Waldman <je...@oracle.com>.
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
>