 |
1EdTech Learner Information Package Accessibility for LIP Access for All Use Cases Version 1.0 Final Specification |
Copyright © 2003 1EdTech Consortium, Inc. All Rights Reserved.
The 1EdTech Logo is a trademark of 1EdTech Consortium, Inc.
Document Name: 1EdTech Learner Information Package Accessibility for LIP Access for All Use Cases
Revision: 18 June 2003
IPR and Distribution Notices
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.
1EdTech takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.
Copyright © 2003 1EdTech Consortium. All Rights Reserved.
Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.
Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: http://www.imsglobal.org/license.html.
The limited permissions granted above are perpetual and will not be revoked by 1EdTech or its successors or assigns.
THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.
Table of Contents
1. Administration Use Case
1.1 Background Information
1.2 Use Case
1.3 Transaction Analysis
1.3.1 Admin - Create New User
1.3.2 Admin - Add Accessibility Profile Template
2. Accommodation Eligibility Use Case
3. Department of Labor Use Case
3.1 Background Information
3.2 Use Case
4. NETg Use Case: Player Preferences
4.1 Background Information
4.2 Use Case
5. PEARL Use Case
5.1 Background Information
5.2 Use Case
5.3 Additional Information
6. PIVoT Use Case
6.1 Background Information
6.2 Use Case
6.3 Additional Information
7. Web-4-All Use Case
7.1 Background Information
7.2 Use Case
7.3 Additional Information
About This Document
List of Contributors
Revision History
Index
1. Administration Use Case
1.1 Background Information
In many situations, it is the responsibility of a system administrator or human resources specialist to create and sometimes modify a user's learning profile. This case describes the creation of a new learner profile focusing on initial accessibility needs. This profile is then later modified to reflect additional information.
This scenario is essentially the same one describing how a user would create their own learner profile and modify it to meet their own particular accessibility needs.
1.2 Use Case
Beth is a human resources specialist in a large university that delivers much of its education via the Internet. Once a student is accepted for enrollment, it is Beth's job to set up their initial account information. She uses a copy of a paper form submitted by the student (in this case, "Dan") which contains basic student demographic information as well as some indication of disability, if any.
Beth logs into the administration system using her user name and password. Beth is recognized as a user with administration privileges and the administration console is displayed (Admin Console). Beth does not have any disabilities, but prefers to view larger text than is typical for these applications. This is in part due to a high resolution display with a finer than normal dot pitch. While this allows more information to be displayed on the screen, it can make things hard to read, which Beth overcomes in her own accessibility preference settings.
From the Admin Console, Beth selects the Create New User option. This displays a form prompting for new user name and other demographic information. Beth enters Dan's information from the paper copy provided for him. The form is submitted and Dan is created as a new user in the Virtual Learning Environment system. A password is automatically created for Dan, which Beth takes note of.
Using the provided information, Beth notes that Dan is deaf. She then invokes the Create Accessibility Preferences function from the Admin Console. This function prompts her for Dan's user name and password, which she supplies. Beth has the choice at this point of creating a detailed set of accessibility preferences for Dan or using one of the default templates that the system provides. Since she doesn't have all that much information on Dan's preferences, she selects a template which causes alternatives to sound to be presented, should they be available for a particular piece of content. Once he receives his password information, Dan can alter his setting to reflect his preferences anytime he logs into the system.
1.3 Transaction Analysis
This analysis is intended to determine what information is collected and provided by services associated with a hypothetical Learner Profile Manager defined under the guidelines established by the 1EdTech Abstract Framework.
1.3.1 Admin - Create New User
- User logs onto the university's administration system.
- Verify that user is an administrator with appropriate access levels.
- Admin console requests LIP preferences - user has larger type preferences.
- Admin configures for larger type.
- Admin console is displayed.
- Access to Create New User function is initiated.
- Create New User form is adjusted to display in larger type.
- Create New User form is delivered to user.
- Information on new student is entered.
- Form is submitted
- New profile is created for student.
1.3.2 Admin - Add Accessibility Profile Template
- Access to Create Accessibility Preferences is initiated.
- Prompt for student name and password is formatted for larger type.
- Prompt for student name and password is displayed.
- Prompt for Create New Accessibility Preference or Use Template is formatted for larger type.
- Prompt for New or Template is displayed.
- Select Template.
- Form to select template type is formatted for larger type.
- Form to select template type is displayed.
- Select template type.
- Default accessibility preferences are added to student profile based on template selected.
This UML sequencing diagram shows the creation of a new user:
The following UML sequencing diagram illustrates the creation of a new set of accessibility preferences for a user by an administrator using a set of pre-defined accessibility templates:
templates to create a new set of accessibility preferences.
2. Accommodation Eligibility Use Case
Pat is a blind 17-year old who has relied on four accommodations during the last year:
- private room,
- having content read aloud via synthesized speech,
- refreshable Braille display, and
- extra testing time (1.25 times the regular time).
Pat's teacher submits a request for all four accommodations for the upcoming reading test, accompanied by reference to supporting documentation. A description of the request is recorded as part of the <requestForAccommodations> sub-element of the accommodation.eligibility element. This information is typed into the system. For example, for "request for accommodations," the teacher types the following.
The request for Pat for the XYZ Reading Test (3rd Edition) is: private room; having content read aloud via Brand Y screen reader; refreshable Braille display; and extra testing time (1.25 times the regular time). See case #2312 for supporting documentation.
The text entered into this <requestForAccommodations> attribute might consist of one or more of (a) a reference or pointer to the request and its supporting documentation (e.g., a case number) or (b) a description of the request, with or without supporting documentation. In this instance, the text consists of a short description of the request, plus a case number that points to the full documentation. Note that in this example, the inclusion of a case number might facilitate access to documentation supporting the request; specifications for such documentation are beyond the current scope of the 1EdTech specifications.
The accommodation needs assessor determines that the requests for a private room, refreshable Braille display, and extra time are approved and but that having the test content read aloud by a speech synthesizer is not allowed. (Note that in many instances, the accommodations needs assessor may be a representative of a group charged with making such determinations.) One factor in this decision is that the test is intended to measure decoding (the ability to form words from characters) and allowing a speech synthesizer to read aloud the test would have exempted Pat from demonstrating that skill. The use of the speech synthesizer might have been appropriate for another reading test or perhaps even for the same test for a different purpose.
The accommodation needs assessor writes a description of the authorized package of accommodations:
Pat may take the reading test in a private room using a refreshable Braille display and extra testing time (1.25 times the regular amount of time). He may not use text-to-speech technology (such as a screen reader) to have test content read to him, though he may use it (with the volume off) if it is necessary to drive the refreshable Braille display.
Note that in describing the package of accommodations, the accommodation needs assessor acknowledges that use of a refreshable Braille display might involve using a screen reader, but that if that occurs, the volume must be turned off. Finally, the accommodation needs assessor enters the date of the authorization and the date of expiration for the authorization.
3. Department of Labor Use Case
3.1 Background Information
Three mining engineering students are underground in protective clothing (overalls, gloves and goggles) in a wet, noisy mine. They are learning to manipulate a valve to control water flow in a cooling system. They need to synchronize information from a pressure gauge, from someone who is driving the machinery and from the instructional system. They are using a text/visual display, and a large joy-stick mouse to access the same instructions they used yesterday in a standard classroom/laboratory on a desktop PC. There is a pressure device attached to the computer.
The instructional system authors have created an application that students can use to record preferences for their interaction with the instructional system. This profile is available on the system and can be amended by each student, temporarily or permanently, and may exist in multiple versions, e.g., to account for long-term morning and afternoon differences.
In addition, the authors have provided a range of profiles that anticipate students' inability to use sound, vision, color, or display criteria as the context in which the instruction is being undertaken. Content is likewise made available in a range of formats (such as video, audio and text).
3.2 Use Case
The first step is for the students to set up the system for the day's lesson. One student has special needs with respect to his hearing disability. His profile states that he prefers information presented in sign language instead of audio. Another student is color-blind. Neither of these students expects to have to inform the system of these things at the time of use, and when they, as a group, are setting up the system for all three of them to use, it is important that this information is invisibly transferred to the system when they notify the system they will be working in a group. Each of these three students have a registered LIP but they will be working together so the system creates a 'group' accessibility profile that will work for all of them.
Following the group LIP, the system changes the display to large yellow on a black background, alters the controls for gross movement navigation suitable to the joy-stick, and avoids auditory output. The system finds the chosen navigation information and an appropriate text equivalent for the auditory stream. The system renders only the selected content in the selected format.
The students interact with the system to customize it for the exercise and machinery they are using. They use the joy-stick and screen sliders to indicate numerical information for data input and a screen keyboard for machinery type and model. In addition, they place the pressure probe into the water stream.
The system instructs them, providing text instructions, until the pressure builds up to a dangerous level, a condition they do not recognize. They need help. A bright light on the probe alerts them to the problem and they close down the valve and read the instructions again before repeating the exercise. The second time they manage to maintain the correct pressure levels for the required time. The system records their activity.
The students return to the standard classroom the next day, using the system again in 'group' mode to write up their experiences by annotating the activity report. Because they are now at a standard PC rather than using the joy-stick-controlled mine computer, the control settings return to normal. Both auditory and visual outputs are used to meet the needs of the hearing impaired student as well as the others in his group.
4. NETg Use Case: Player Preferences
4.1 Background Information
NETg's training software incorporates many accessibility features that a learner can manually set so that they get the appropriate learning environment for their abilities and preferences. This use case describes how the NETg software could read the appropriate information from an 1EdTech Learner Information Profile, and set the appropriate options automatically.
4.2 Use Case
Sam is a new NETg user, although he has used various forms of learning technology before, and so an 1EdTech Learner Profile exists that catalogs his preferences. Although Sam does not have a hearing disability, he finds computer audio distracting, and so prefers to use on-screen-text instead of audio. Accordingly, his Learner Profile indicates this preference, along with the rest of his display and input preferences.
When Sam opens the NETg player, he enters his username and password. The NETg player communicates the login information to the controlling LMS, and also asks the LMS if Sam has an available learner profile. The LMS locates Sam's profile, and forwards the data to the NETg player (note that whether Sam's profile is local to the LMS or located on a profile server is not relevant to the functioning of this use case).
When the NETg player receives Sam's profile, it reads through the profile, and automatically sets preferences to correspond to the preferences expressed in Sam's profile. Thus, the player automatically turns off the sound, and sets itself to use onscreen text instead, as well as automatically conforming to the rest of Sam's preferences.
5. PEARL Use Case
5.1 Background Information
The PEARL project (Practical Experimentation by Accessible Remote Learning) is an actual project that is in progress at the Open University in the UK. The project has developed a framework by which remote control of labs for science and engineering subjects can be offered to students anywhere over the WWW. One of the motivations for doing this was to promote the increased participation of disabled students in these subjects. Hence accessibility has been a priority for the project.
The project has implemented a user interface where by interfaces are generated "on the fly" from XML descriptions of all the interface elements and the type of interaction they support. They have begun to explore an extension to this approach where by as well as XML descriptions on the activity and its elements that the "interface generator" is also given an XML description of the learner and the way they prefer to use their computer. This learner description has been based on the draft 1EdTech LIP <accessForAll> element and its sub-elements.
The reason for doing this is that it then becomes possible to optimize the interface for individual users and this may take into account, as examples, assistive technology requirements or the fact they are working hands-free or using a PDA. Work is still in its early days. Further research is needed to define the "rule base" that will specify an interface given a generic description of the interface elements and a user profile.
5.2 Use Case
Jenny and Michael are both students at a large campus based university. Jenny is blind but fully mobile whereas Michael has severe motor impairments that affect both his dexterity and mobility.
Jenny goes into a central computer facility to check her schedule for the week and pick up her new assignments. She logs onto the university's VLE (virtual learning environment). As she is an established student the VLE has a store of Jenny's own LIP. The system therefore knows that she is a non-visual computer user. Therefore, all graphics are rendered as alternative text. The local PC also accesses her LIP information and activates and configures to her preferences the pre-installed screen-reader software for her.
Michael, because of his mobility problems, prefers to work from home from his specially adapted PC. He is a switch user (uses two switches to select from highlighted symbols on a virtual keyboard instead of using a standard keyboard). He logs into the VLE at the beginning of the week to check his schedule etc. by dial-up connection. Similarly the VLE accesses Michael's LIP and configures the content presentation to suit the way he uses the computer. The VLE is fully accessible and it uses the information in the LIP to determine that Michael requires keyboard shortcuts for all menu options and configures the menus on his virtual keyboards accordingly. It is also cognizant of the fact that Michael can only see the top 2/3 of his screen because his virtual keyboard occupies the lower 1/3.
One of Michael's lessons for the week is a remote lab session. Here he has to work in collaboration with other students working at their computers. This is a PEARL lab session and this application has been developed to take the information from the LIP and optimize the user interface for each user. The PEARL application also uses information about the students' hardware interrogated directly for the PC to be able to optimize the user interface each time a user accesses the remote lab facility. This information includes available screen size and pixel resolution as well as the bandwidth available across the remote link. Therefore Michael is able to participate in the lab sessions for his science course from his own home.
5.3 Additional Information
Information about the PEARL project is available from http://kmi.open.ac.uk/projects/pearl
The following UML sequence diagram illustrates one aspect of the PEARL use case:
6. PIVoT Use Case
6.1 Background Information
Mary is a physics student at MIT who is blind. Mary is registered for an introductory physics course in Classical Mechanics, which is one of the most challenging core courses required for graduation from MIT, and the one with the highest failure rates.
6.2 Use Case
After enrolling in the course, Mary learns that as a supplement to this classroom-based course, all of the professor's lectures and portions of the course textbook are available to students enrolled in the course via the web through PIVoT (Physics Interactive Video Tutor). Using streaming digital video and the Internet, PIVoT gives students access to an online textbook, FAQs, physics simulations, practice problems, and a "Personal Tutor" which is an intelligent agent that provides individualized help based on each user's navigation through the web site.
PIVoT gives students instant access to their professor through a collection of digital video clips in which the professor explains difficult concepts, demonstrates physics principles, steps through problem solutions, and answers students' most frequently asked questions (FAQs). PIVoT also offers 35 lectures by the professor via streaming media.
The first time Mary visits the PIVoT website using JAWS, a screen reading software, she logs in via an accessible log-in screen. She is then prompted to set up her user preferences. The preferences she can indicate in PIVoT include audio descriptions for recorded lectures (including equations in MathSpeak, an easy-to-learn language for articulating mathematical concepts), closed captions for recorded lectures, described textbook graphics (utilizing alt-text tags, D-links and longdesc with graphics). The preferences Mary selects will be applied to the delivery of the course material each time she logs into the PIVoT site, regardless of where she is when she logs in.
Planetary Data is the first topic Mary decides she needs additional information about to prepare for her upcoming quiz. There are 3 videos and 2 sections from a chapter in the textbook related to this topic. Since she requires audio descriptions based on her user profile, when she begins to play the first video of the professor's lecture, in addition to his lecture she hears audio descriptions of the complex equations he is drawing.
After watching the videos, Mary then begins to read the textbook sections. She hears the text portions of the textbook spoken aloud via the screen reading software that she uses. When her screen reading software encounters graphics or equations, she hears the accompanying alt-text descriptions, which describe the non-textual visual elements of the textbook.
6.3 Additional Information
Information about the PIVoT project is available from http://curricula2.mit.edu/pivot/
7. Web-4-All Use Case
7.1 Background Information
The Web-4-All project is a collaboration between the Adaptive Technology Resource Centre and the Web Accessibility Office of Industry Canada to help meet the public Internet access needs of Canadians with disabilities and literacy issues. Web-4-All combines hardware and software to quickly configure a public access computer to accommodate the special needs of a user and then reverts back to a standard setting for the next user. The needs of users may include: personalized setup of browser, choice of assistive technology and system settings at a multi-user workstation, and a portable preference set.
Challenges faced by Web-4-All included the lack of technical support at the public access centers and the need for a way to change the residual settings from one user to the next, which can then be readjusted for each use quickly and minimizing conflict between different assistive technologies.
7.2 Use Case
Mrs. Smith is 70 years old. She is slowly losing her visual acuity to the extent that she requires text to be magnified 4 times. She uses the Industry Canada Community Access Program workstation site to exchange pictures with her grandchildren, to plan her travels and research medical information about her husband's illness. Together with an assistant Mrs. Smith sets up her preferences by answering a series of functional questions. The resulting preferences are expressed as an LIP specification with accessibility extensions that is saved to a portable storage device (such as a Smart Card). Once this is done Mrs. Smith can take this portable preference to any Community Access Program workstation and cause the browser, system preferences and assistive technologies to adjust to her individual preferences. She can adjust these preferences at any time (i.e., if she forgot her corrective lenses, etc.).
Mrs. Smith takes the same portable preference set to the public access facility at her local college to take a French course offered using a major learning management system (LMS). The LMS responds to the LIP specification instance by adjusting the display of the content according to Mrs. Smith's preferences.
7.3 Additional Information
Information about the Web-4-All project is available from http://www.web4all.ca/
About This Document
| Title | 1EdTech Learner Information Package Accessibility for LIP Access for All Use Cases |
| Editor | Mark Norton |
| Team Co-Lead | Jutta Treviranus |
| Version | 1.0 |
| Version Date | 18 June 2003 |
| Status | Final Specification |
| Summary | This document presents uses cases used in the development of the 1EdTech Learner Information Package Accessibility for LIP |
| Revision Information | 18 June 2003 |
| Purpose | Defines the 1EdTech Learner Information Package - Accessibility Preferences. |
| Document Location | http://www.imsglobal.org/accessibility/acclipv1p0/imsacclip_usecasesv1p0.html |
List of Contributors
The following individuals contributed to the development of this document:
Revision History
| Version No. | Release Date | Comments |
|---|---|---|
| Public Draft 1.0 | 04 April 2003 | The Public Draft release of the Accessibility for LIP Specification. |
| Final v1.0 | 18 June 2003 | Made only minor editorial changes. |
Index
A
Abstract Framework 1
audio 1, 2, 3
B
Braille 1
E
Extension 1
I
1EdTech Specifications
Learner Information Package 1, 2, 3, 4
P
preferences 1, 2, 3, 4, 5, 6
profile manager 1
X
XML 1
1EdTech Consortium, Inc. ("1EdTech") is publishing the information contained in this 1EdTech Learner Information Package Accessibility for LIP Access for All Use Cases ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.
1EdTech makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an "As Is" and "As Available" basis.
The Specification is at all times subject to change and revision without notice.
It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.
1EdTech would appreciate receiving your comments and suggestions.
Please contact 1EdTech through our website at http://www.imsglobal.org
Please refer to Document Name: 1EdTech Learner Information Package Accessibility for LIP Access for All Use Cases Revision: 18 June 2003
