Introduction. What's Personal Web Accessibility?

• Modelling the particular accessibility requirements of the end-user
  • Disabilities
  • Assistive technologies in use
  • Delivery context: access device features and constraints
• From an (automatic) accessibility evaluation point of view it entails...
  • Profiling the accessibility features of the user
  • User-tailored evaluation reports
  • Metrics inferred from reports (also user-tailored)
• An accessibility metric can be...
  • Absolute number of errors
  • Failure-rates
  • More accurate metrics which consider guideline impact (priorities) or type of guideline (automatically or semiautomatically evaluated)

Why we need Personal Web Accessibility

• Development of websites for specific audiences
  • Seems that goes against "Universal Design" paradigm
  • Alternative way to obtain "Universal Design"
  • ∪ personal_accessibility_profiles ⊆ all interaction environments
• Personalized Information Retrieval. Some authors suggest that annotating/sorting search results according to their accessibility improves user experience
• Adaptive Navigation Support to enhance user's orientation. Some authors state that,
  • Visually impaired users need to be warned of obstacles due to their high reliance on environmental cues
  • The detection and notification of barriers improves their orientation
  • Evaluate [on the fly] linked pages in a web document to obtain an accessibility score in order to provide:
  • Local Guidance
    • Adaptive sorting: providing a list of the most accessible links in a page
    • Local orientation support: annotation of all links in a page with their accessibility score
  • Global Guidance. It is possible, knowing the user's objective to give "the most accessible path"

Which are the current limitations for carrying out personal accessibility evaluations [automatically]?

• Grouping general accessibility guidelines (WCAG, Section 508, MWBP...) by their impact on particular user groups seems to be a solution
• Several problems arise with regard to automatic evaluations and metrics based thereon:
  • Some guidelines contain not solved references to the user's delivery context
  • E.g.: MWBP recommend not to use pictures which are wider than width the screen
  
  
  • Some guidelines are incomplete
  • E.g.: WCAG 12.1 and 12.2 identify accessibility problems related to frames. AT versioning issues are not considered.
  
  
  • Users' individual needs are not well covered in group guidelines
  • Group guidelines capture typical needs. E.g. individual needs may deviate from them
  
  
  • Multiple group membership is not supported by evaluation tools
  • E.g.: a mobility impaired user interacting with a handheld devices

How to address the problem

• If we want to carry out user-tailored web accessibility evaluations efficiently/automatically we have to consider:
  • The dependencies of accessibility guidelines in regard of assistive technologies
  • Access device features. Hardware and software constraints
  • Multiple group membership → multiple guideline-set support
• Such information is put automatically in a user profile used as input of the evaluation engine
• Objective: evaluation of web pages against the guidelines that impact on the user's interaction environment
• We propose a framework to automatically evaluate these features jointly with traditional accessibility issues:
  1. A module for access device features detection to create preliminary user profiles [stereotypes]
  2. A common vocabulary for user profiling. Modularity, interoperability
  3. Repository of machine-understandable guideline sets
  4. A component for guidelines instantiation
  5. Web accessibility evaluation engine
  6. A component to infer metrics from evaluation reports
• As a result we obtain personalized evaluation reports and metrics

Access Environment Features Detector

• Retrieve information regarding user's access device
  • screen size, keyboard type, pointing device support, etc.
  • image format, scripting, hypertext support, etc.
• Detect installed Assistive Technologies such as screen readers or Braille displays
  • Query the System Registry or its equivalent in Unix systems
  • Implies the maintenance of a database containing information with regard to Assistive Technologies (ATs)
  • When a match is found information about ATs is obtained from both sources (DB and Registry)

A vocabulary for user profiling

• Personal accessibility profile: information detected by the Access Environment Features Detector regarding delivery context and ATs
• Implemented in Composite Capabilities/Preference Profiles CC/PP W3C standard for modelling user profiles based on Semantic Web (RDF)
• Correctly extended it can be useful to model user's disabilities
• In order to enhance its expresiveness it is encouraged its extension. (Reuse of existing vocabularies is strongly encouraged)
• Evaluation of coverage and expressiveness of CC/PP by analyzing some accessibility guideline-sets(*) in respect of:
  • Assistive technologies → Guideline incompleteness or guideline dependency
  • Access device → Unsolved references to the delivery context

(*) WCAG 1.0, MWBP 1.0, IBM Accessibility Guidelines, Web Design Guidelines for Elderly Users, IMS Guidelines for Developing Accessible Learning Applications

A vocabulary for user profiling II. Dependencies with Assistive technologies

In the evolution over the years, ATs have addressed new accessibility issues. Strict control version is necessary since several guidelines are dependent on different versions. Dependencies are grouped in two categories:

• Negative dependencies. Even if guidelines are fulfilled some versions of ATs may not convey web content adequately
• Positive dependencies represent "until user agents..." statements in WCAG 1.0

In addition, it is necessary to infer the disability of the user from the used ATs. CC/PP files are extended with the following concepts:

• Assistive Technology, <access:ATtype>screen reader</access:ATtype>
• Assistive Technology Product, <access:ATname>Jaws</access:ATname>
• version, <access:version>3.0</access:version>
• user, <access:user>blind</access:user>

A vocabulary for user profiling III. Dependencies with Delivery Context

• Apart from traditional web content accessibility, access device features have to be considered in the evaluation process
  • Physical limitations of handheld displays cause accessibility problems
  • Limited computing resources cause a lack of mark-up languages, scripting, image format support, etc.
• Mobile Web Best Practices (MWBP) aim at addressing these issues. They determine the concepts to be introduced in the personal accessibility profile
• Some concepts and vocabulary words are borrowed from UAProf (User Agent Profile) by the Open Mobile Alliance

Some examples:

A repository of machine-understandable guideline sets

• Guidelines are implemented in XML
  • Flexibility
  • Machine-undertandable
• After studying the state-of-art accessibility guidelines we developed the Uniform Guidelines Language (UGL)
• UGL is capable of implementing guidelines regardless of the abstraction level, access device, interaction environment, or any combination thereof
• Guidelines are stored in an XML repository
• Due to the complexity of UGL a management system has been developed
• Representation of guidelines in UGL (an excerp). "If value of NAME attribute in element INPUT is equals to "go" an alternative description is required"

<label>INPUT</label>
<analysis_type>check attribute</analysis_type>
<related_attribute>
	<atb>NAME</atb>
	<analysis_type>value</analysis_type>
	<analysis_type>check attribute</analysis_type>
	<content test = "=">go</content>
	<related_attribute>
		<atb>ALT</atb>
		<analysis_type>compulsory</analysis_type>
	</related_attribute>
</related_attribute>

Enhancing UGL with information regarding ATs and Delivery Context

The identified dependencies are dealt in different ways:

• Depencencies with ATs versions
  • Negative dependencies: an error will be reported if there is a negative dependency
  • Positive dependencies: guidelines will not be added to the final set if a positive dependency is found

  <label>IFRAME</label>
  <analysis_type>checkAT</analysis_type>
  <related_AT>
  	<AT type"access:ATname">Jaws</AT type>
  	<analysis_type>value</analysis_type>
  	<analysis_type>check attribute</analysis_type>
  	<content type="access:version" dep="+">4.51</content>
  </related_AT>
  

Enhancing UGL with information regarding ATs and Delivery Context II

• Delivery Context dependencies. The system cannot foresee access device features until the time of evaluation
• slots are introduced into guidelines in order to represent any value
• The value of the slot will be found in the personal accessibility profile
• They have the same vocabulary name so matching is quite straightforward

<label>IMG</label>
<analysis_type>check attribute</analysis_type>
<related_attribute>
	<atb>WIDTH</atb>
	<analysis_type>value</analysis_type>	
	<content test=">" type="prf:ScreenSize"/>
</related_attribute>

Guidelines Instantiator (GI)

• Gets the personal accessibility profile and performs two tasks
• Based on the user profile it retrieves from the repository those guidelines that have impact on the user. There are three criteria to determine whether a guideline is relevant for the user or not
  • Both user profiles and UGL store the disability of the user in the field named access:user. The GI just performs the matching
  • Using the information in profiles the GI infers if the user is accessing with a handheld device. If so MWBP are retrieved
  • Guidelines with negative dependencies are added to the last set while those with positive dependencies are not retrieved

Guidelines Instantiator II

• Completes missing specifications in the guidelines which have non solved references to the delivery context
• Partial CC/PP file

<rdf:Description rdf:about="http://sipt07.si.ehu.es/profiles/prof00001">
	<ccpp:component>
	<rdf:Description rdf:about= "http://sipt07.si.ehu.es/profiles/...>
		<prf:ScreenSize>320x160</prf:ScreenSize>
	</rdf:Description>
	</ccpp:component>

• Partial UGL guideline

<label>IMG</label>
<analysis_type>check attribute</analysis_type>
<related_attribute>
	<atb>WIDTH</atb>
	<analysis_type>value</analysis_type>
	<content test="<" type="prf:ScreenSize">320</content>
</related_attribute>

Evaluation engine and accessibility measurement

• A web page is evaluated against the ad-hoc created guideline set and the accessibility profile
• Evaluation engine independent from multiple guideline sets
• Potentially it can evaluate:
  • issues with elements, attributes and the content of hypertext documents
  • issues with Assistive Technologies
  • problems with access device features

• Exploiting user-tailored reports entails getting user-tailored metrics
  • Absolute number of errors
  • Failure-rates
  • More advanced metrics that consider error priorities, type of errors (automatic or semi-automatic)

Putting all togheter

1. AT detector retrieves data from the AT database and at the same time the Delivery Context features are also obtained
2. AT detector queries the System Registry
3. Information regarding potential user, ATs and access device is put in the extended CC/PP profile
4. Based on information of the profile the GI retrives guidelines from the repository. In addition slots in guidelines are filled in
5. A web page is evaluated against the final guidelines set
6. Accessibility Metrics are obtained from reports
7. A user agent applies to the DOM user-adaptive modifications

Case study

• In order to demonstrate the validity of the approach 4 profiles were created considering 4 interaction contexts with regard to disability, AT and access device
  • P₁: a blind user using Jaws version > 6
  • P₂: a blind user using Jaws version < 6
  • P₃: user accessing with Nokia 9210 cell phone
  • P₄: user accessing with a Blackberry 7755
• 10 home pages that received Webby Awards were evaluated

• As we had foreseen there's a noticeable difference between results obtained with different profiles specially between P₁ and P₂ versus P₃ and P₄ mainly because the former were evaluated against WCAG and the later against MWBP

Case Study. Discussion

• Difference between P₁ and P₂: better support for scripting, content refresh, updates and pop-ups of newer versions of the screen reader
• Lack of HTML support such as table rendering and display limitations makes results for P₄ worse than for P₃


• If fewer errors are reported for one profile than for the others doesn't mean that a web page is more accessible for that profile
• The requirements of some user groups are not well defined or are quite fuzzy which makes difficult automatic evaluation
• Obtained results constitute an upper bound for the accessibility level since these reports are based on automatic evaluation and manual evaluations have still to be carried out to get a more accurate rating

Future Work and Conclusions

• Deployment: encapsulate the framework in browser plug-in to provide Adaptive Navigation Support
• Every time a user accesses a web page all links will be rated according to the user profile
• Links will be labelled and ranked them by manipulating the DOM structure of the page
• However, the more links a web page has the slower the transitions will be


• Regarding the modelling of user's abilities most meaningful information can be found on ATs settings which are not always accessible
• Providing question answering dialogs or forms to obtain complimentary information. Intrusive?


• From its early onset CC/PP aimed at modelling users' preferences in order to transform content according to user's likings
• Further releases could include users' delivery context desired by users, independent of their abilities and access device