In a recent issue, [#936926-62: Update color scheme for status-based issue tables and issue link filter], the question of allowing users the option to customize UI preferences was raised. This is not the first time that this question has come up. In fact in Drupal 7 we have at least two UI options for accessibility, the ability to show row weights on table drag, and the ability to disable the Overlay.
I have been asked a number of times in the past if I think that Drupal should have an accessibility settings page, where users can configure accessibility settings. I have resisted this idea in the past, and do believe that it should be avoided if at all possible. Two downsides to this concept are that settings should be located as close to the affected UI as possible (easily discoverable), and that this could possibly become a ghetto for things we don't have the time to make work properly. These are not foregone conclusions, but do need to be considered when making decisions about how to approach this topic.
The Fluid Project does have a concept of User Interface Options (UI Options). This is a page where a variety of UI options can be configured. This is an interesting concept and in my opinion is worth discussing / exploring for Drupal 8.
I believe that there may be some benefit to including a UI Options module in Drupal 8. The module should be hookable, allowing any module, and perhaps theme, to register settings.
Again, I approach this issue cautiously as there are potential downsides to the concept. Nevertheless, I do think that it is an issue worthy of discussion and would like to hear what others have to say about the issue.
Comments
Let's try it
I think it's worthy enough to go into the Accessible Helper module as an experimental sub-module.
I think there are ways that it could be quite useful to allow more customization based on the user's needs.
I was reflecting a little while ago about how some people with cognitive disabilities use screen readers to help them read and navigate web pages. I can see this too for folks who might use similar technologies to read text to them in a second language if they aren't as comfortable with the written text.
Anyways, all the work we've been doing to add invisible text for screen readers may well be making it harder for users who are using AT in less traditional ways.
I'm not sure what type of customization we can allow, but it would be useful to be able to provide a site which provides more flexibility for different users.
I'm interested in hearing more about what type of customizations people would like to see. Then we'd have to find the time to write up the module!
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
I think there is merit in
I think there is merit in exploring adding a UI Options module to the Accessible Helper project. My initial thought is that a UI Options module is not for accessibility alone. It should be considered a UI preferences module, which any user may wish to access to modify the UI. Including this in the Accessible Helper project, which may be an easy way to start, would perhaps give this module an undesirable branding.
I agree that one setting may be to allow users to decide if content with the .element-invisible class is invisible, or if it is visible. Along with a variety of users with disabilities who may find this useful some developers may find it useful to modify this setting to see how their content is being rendered without having to disable all styles in their browser or to look at the document source, or use a tool like Firebug.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
Some notes on UI options
I spoke with some developers at the Fluid Project. They are interested in discussions about UI options in Drupal.
A set of rough notes on UI options can be found at http://wiki.fluidproject.org/display/fluid/Notes+from+chats+with+SMEs+on...
More notes to come next week.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
Great notes
I agree that this approach has merit for Drupal. If we want to build a UI Preferences module to cover not only accessibility but also mobile preferences and theme options (like font size or color choices) there is a lot of collaboration that will be needed. The notes you posted are a great resource.
www.pixotech.com
Site Preferences are useful counterpart
Site preferences for UI is also useful. I tried to do some of this related to accessibility in the Accessible Helper Module rewrite for D7 (see the first part of video at http://www.youtube.com/watch?v=VZkccMbt7CQ)
The idea of site preferences is that the site administrator could pick the behaviours (html5, aria, wcag X) they wanted, and other modules would defer to the site.
If user UI prefs and site UI prefs were implemented together, they would be easier to implement.
By coupling user and site preferences, a standard set of options could be selected and user prefs could override site prefs which would override default prefs.
www.johnbarclay.com
User < Site < Default Prefs
@John
I like the approach of having user prefs override site prefs which override defaults. I think that this is a good pattern to use. Since site prefs are already in the accessible helper module it is likely the best place to experiment with this concept.
Ideally once D7 is released I will have more time to brainstorm and work on this idea. Perhaps a conference call sometime in the not too distant future would be a good way for all interested to collaborate together and share more initial thoughts and ideas.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile