Warning:
This wiki has been archived and is now read-only.

Personalization

From UWA
Jump to: navigation, search

Introduction

Like device adaptation, there is a need to personalize the Web for individuals. In the case of accessibility, we have gone as far as we can with a one size fits all strategy. The web is becoming much more complex. Authors are creating sites which make use of complex visualizations such as maps, rich internet application component such as sliders and spreadsheets, and mashups created from varying web resources exposed through public service APIs. Adding further complexity the web content we see may be impacted by the situation we are operating in - a noisy room, poor lighting, or limited mobility.

These issues produce extensive accessibility issues.

  • In the case of a mashup we don't know if the source is accessible
  • We may need an equivalent alternative for an inaccessible mashup resource
  • For someone who is blind we may need a text alternative for a complex visualization such as directions vs. a map.
  • We may need to simplify the user experience for someone with a learning disability

Fixing these accessibility issues can also create business opportunity by addressing

  • People walking away from an online transaction because they get lost along the way
  • People are unable to access information on a mobile device due to a situational impairment
  • People have accessing online training may get confused because of an array of impairments
  • People may not want others to know they have a disability and hide it by not using an assistive technology

Preliminary Work

The IMS Global Learning consortium did the first work on personalization called Access For All which ultimately became two ISO SC36 specifications called Personal Needs and Preferences (PNP) and Access For All Digital Resource Description (DRD). One of the projects which was the basis for Access For All's design was Web-4-All Canada. In this scenario, a user would use a smart card to access a library's personal computer kiosk and configure the system to meet their needs. The resulting preferences were inclusive of all preferences to configure everything from assistive technologies to be used, system settings, and content adaptations. The Ubiquitous Web Appliction Working will be working in collaboration with members of the IMS Global Learning Consortium Accessibility Working Group, ISO 36, and EU For All , and other organizations like the Open Mobile Alliance to make this a reality.

Roadmap for Integrating into the Broader web

Bringing personalization to the broader web requires us to address a number of issues:

IMS/ISO Access For All Analysis - Separation of server and Client Preferences

This analysis was based on the current IMS GLC specification in development for Access For All version 2 which is intended to harmonize with ISO plus provide some additional features.

Some general comments and questions:

  • screen enhancement - We should eliminate personal style sheet. Personal style sheets will not work for today's content and will, in many cases, break usability. Andy Heath agreed.
  • Should we keep usage. Why not just say required? Major companies are going to either satisfy something or they are not. Perhaps we should consider the decision what to do with satisfied content as a policy for the IT provider.
  • Should magnification be a user agent function? Firefox 3, Opera, and IE7 support full magnification of content. Safari supports text magnification (ctrl+/- on Windows).

Here is the start of the break down between client and server of user preferences:

  • Screen Enhancement
    • Client and Server
      • font face
      • font size
      • foreground color
      • background color
      • highlight color
      • invert color choice
    • Client only
      • cursor size
      • cursor color
      • cursor trails
  • Text Reading and Highlighting
    • Client and Server
      • speech rate
      • pitch
      • highlight
  • speech component (not sure where this is
    • Client Only
      • volume
  • Structural layout
    • Client and server
      • content density
  • Components shown
    • Client Only
      • Window layout
  • Braille, Tactile
    • Client only unless we can prove it is needed on the server. Major IT providers will not do anything special for Braille.
  • Visual Alerts
    • Client only. This seem to be targeted at the OS. We have no vehicle for triggering system sounds in web content except via WAI-ARIA. WAI-ARIA allows you to define alert and alertdialog roles. There activation could force a system sound which triggers visual alerts in Windows. This could be a user agent setting.
  • Control
    • Client and server
      • keyboard enhancements
      • prediction
      • structural navigation (potentially).
      • input control (all keyboard or all mouse navigation)
    • Client Only
      • onscreen keyboard
      • alternative keyboard
      • mouse emulation
      • alternative pointing
  • Keyboard Enhancement, onscreen keyboard, alternative keyboard, mouse emulation, alternative pointing, voice recognition, coded input, Structural Navigation, (Sticky, Repeat, Slow, Debounce keys), Point and Click, Point and Dwell, Automatic Scanning, Inverse Scanning, Directed Scanning, Code Selection, Resizeable Keys, Relative Pointing, Dwell Select, Command and Control, Code termination, Switch assignment, - Client only
  • Prediction, Content - Client and Server
  • Adaptation Preference
    • Client and Server
      • original access mode
      • representation form
      • language
      • education level
    • client only
      • reading rate
Retrieved from "https://www.w3.org/2007/uwa/wiki/index.php?title=Personalization&oldid=265"