Child pages
  • Case Study: Management and Sharing of Personal Accessibility Needs and Preferences
Skip to end of metadata
Go to start of metadata

Case Study: Management and Sharing of Personal Accessibility Needs and Preferences


By and large, purveyors of online services and resources have fallen short in accommodating the accessibility requirements of many of the people they want to serve. The problem is challenging but its urgency  is undeniable. This case study suggests that UMA could address one of the core challenges: Providing users the ability to express personal accessibility needs and preferences and to control the release of subsets of that information so that online services can tailor themselves accordingly.

Problem Scenario

Madeline, a compute science graduate student at the University of Southern North Dakota (USND), is frustrated by the fact that online eTexts used in her modal logic class are effectively inaccessible to her for two reasons. She has color blindness that renders many of the figures in the text indecipherable and she lacks the fine motor control that would allow her to easily click check boxes and radio buttons used in some of the end-of-chapter quizzes.  The publisher,, is well-intentioned, and has taken a decision to address accessibility issues in their next edition, but they are at a loss as to how to programmatically and appropriately configure the user interface to meet the varied needs and preferences of their intended reader population. editors are aware of the relevant standard, ISO/IEC 24751 parts 1-3, "Individualized adaptability and accessibility in e-learning, education and training". The data structures defined in that standard are expressive enough to capture the specifics of Madeline's needs and preferences as well as those of a broad constellation of other accessibility challenges. However, they can't see how to elicit this information in any practical way–The naive notion of asking a series of need and preference questions at the time a user accesses their online resources was quickly rejected.

Meanwhile, the Accessibility Program at USND has pioneered the use of self-assessment tools that allow students like Madeline to define in a structured way the full range of needs and preferences with regard to online services and resources.  They, too, know of ISO/IEC 24751, and the output of the self-assessment tool is an information set conformant with that standard. They even have learning management systems that support the IMS Access4All V 3.0 specification that complements and supports ISO/IEC 24751.

It seems that most of the pieces are in place, but what is lacking is a way for Madeline to selectively convey that information to the online provider. Madeline is also hearing impaired, but that fact is not relevant to the modal logic eText, and she would rather not release information like that since it is irrelevant to the particular transaction at hand.  All parties want to do the right thing, yet the problem remains unsolved.

Proposed Improvements

UMA provides some crucial missing pieces of the puzzle.  UNSD could stand up (or work with an externally hosted) UMA Resource server (RS) and Authorization Server (AS). With appropriate user interfaces, this would allow faculty, staff and students to manage not only their Access4All information itself but also to manage the policies around to whom, and under what conditions, specific subsets of that information are released. In addition, The USND Accessibility Program has worked with the Shibboleth/SAML team to add an attribute to assertions that the SAML Identity Provider issues when users access a SAML-protected resource. This attribute, access4allSet, carries a URL that points to that user's access4all information set on the USND-provided AM.  If the Service Provider/Relying Party at is UMA-ready, the eText service can initiate an UMA protocol conversation to obtain appropriately controlled access to the user's accessibility needs and preferences. Once this is all in place, Madeline could finally take full advantage of the modal logic eText as originally envisioned.

Solution Scenario


Solution Flow

This scenario uses classic UMA. See the swimlane diagrams for details.

Developing Demonstration Solutions


  • No labels