Filtered by category Accessibility, 1 - 5 of 5 Postings (all, summary)

.LRN Accessibility

Created by Olga C. Santos, last modified by Gustaf Neumann 25 Oct 2017, at 08:34 AM

From quite a long time .LRN community has been moving towards producing both accessible interfaces and services for all. Accessibility analysis on previous releases have been done such as Tristan Kalnins-Cole's under Dorian Peter's (dotLRN Director of Visual Design) supervision. This lead to the unofficial conclusion that version 2.1.3 was level A compliant.

Selva theme was designed to make easier the customization of the look and feel of .LRN, improving navigation and usability. Moreover, unlike other .LRN templates, it is strongly based on CSS. Therefore, it can be easily seen that Selva theme was a step forward in considering accessibility issues.

During the development of version 2.2.0 we have been working to assure that .LRN 2.2.0 with Selva theme is compliant at least with W3C WAI WCAG 1.0 level A. In this sense, three new categories of bugs have been created in the Bug Tracker and are being used to report problems regarding accessibility. So far, within the framework of several R&D projects in which aDeNu Research Group at UNED is involved, we have compiled several accessibility analysis performed by some of our partners (Soluziona) and research groups within UNED to translate the problems found at different development stages to .LRN/OpenACS bugs and discuss them in the .LRN IRC Tuesday meetings. "This work has led to the release of .LRN 2.2.0 as W3C WAI WCAG 1.0 level A compliant, except for LORS package (there is a strong incompatibility between the SCORM RTE and WCAG 1.0, which is to be solved with WCAG 2.0). Moreover, there may be some minor level A bugs reported found here, which are to be solved."

The planning for next version is to achieve WC3 WAI WCAG level AA and take into account, when available, specific guidelines from national regulations such as the American Section 508, UK SENDA, Australian DDA, German BITV or Italian Stanca. Our plans are to consider WCAG 2.0 as soon as they are officially released as well as other WAI documents (e.g. ATAG and UAAG).

In order to improve the accessibility quality of dotLRN, we ask you to use W3C Web Content Accessibility bug types to report any problems encountered so they are taking into account when developing.

Update for dotLRN 2.3

See Zen project and external evaluations on Educational packages [1], [2].

Information on the progress is also done in periodic dotLRN/OpenACS conferences:

Fall 2006
- Session Towards full Accessibility in LMS
Spring 2007
- Improving Accessibility, Usability, and Code Quality of .LRN and OpenACS: The .LRN Zen Project [3]
- Workshop on Experiences on Accessible eLearning Platforms

Last modified: 2017-10-25 08:34:57.234495+02

References to this Page: en:.LRN_2.3 Categories: .LRN (OpenACS.org), Accessibility (OpenACS.org)

How to contribute code that passes accessibility tests

Created by Rocael Hernández Rizzardini, last modified by Benjamin Brink 30 Jun 2017, at 06:10 AM

About this document

Status: DRAFT
Updated: 11-jun-2009

Accessibility Policy

The policy for .LRN is published at .LRN website: Accessibility Policy

Corresponding policy for OpenACS is currently being written and will be published soon.

The conformance level to be satisfied is explained in the "Accessibility Conformance Level" section of the .LRN Accessibility Policy.

The "Accessibility page" refered by the .LRN Accessibility Policy states the conformance level and its domain of aplication for each version of the software.

Web Content Accessibility Guidelines

Note: Although automatic tools, such as TAW and "Cynthia says", may be useful to help the developer/author in addressing accessibility issues by providing informative reports, they can not certify the accessibility level of a page since many things need a manual review. Also, those tools won't be able to check a page protected by user and password (they would report on the login page, the one they can actually reach).

WCAG version 2.0

Understanding WCAG 2.0: a "must read"
The guidelines
How to meet WCAG 2.0 (quick reference)
Techniques and Failures for the Success Criteria of WCAG 2.0

WCAG version 1.0

The guidelines: explain how to make Web content accessible to people with disabilities.
Checklist of checkpoints to satify for each level of conformance. Each checkpoint is followed by one or more links to techniques in the following documents:
- "Core Techniques for Web Content Accessibility Guidelines 1.0" ([WCAG10-CORE-TECHNIQUES]), which discusses the accessibility themes and general techniques that apply across technologies.
- "HTML Techniques for Web Content Accessibility Guidelines 1.0" ([WCAG10-HTML-TECHNIQUES]), which provides examples and strategies for authoring accessible Hypertext Markup Language (HTML) content.
- "CSS Techniques for Web Content Accessibility Guidelines 1.0" ([WCAG10-CSS-TECHNIQUES]), which provides examples and strategies to help authors write Cascading Style Sheets (CSS) as part of accessible content design.
Techniques: gateway to the aforementioned specific ones.

Contributing Code

Once the requirements are met, to contribute your code follow these instructions (one of the two):

How to contribute to OpenACS
Contributing code for .LRN: submit your proposal to the .LRN leadership team by:
- posting at the .LRN Q&A forum
- joining the weekly meeting on IRC (tuesday at 18:00 CET/CEST)

Resources

on-site resources

(addressing) Accessibility in .LRN and OpenACS: tutorial from the OpenACS/.LRN conference in Valencia (nov 2008), based on WCAG version 1.0.
Accessibility Guidelines for OpenACS/.LRN developers: slides from an online tutorial on may 2009, based on WCAG version 2.0.
.LRN Zen project Standards

External resources

Web Accessibility Initiative
Web Accessibility in Mind
456 Berea St: Articles and news on web standards, accessibility, and usability

If you need more information on how to address accessibility, post your questions at the forums

References to this Page: en:coding-standards-index Categories: .LRN (OpenACS.org), Coding Standards (OpenACS.org), Accessibility (OpenACS.org)

.LRN Zen Project: Standards

Created by Avni Khatri, last modified by Gustaf Neumann 22 Jun 2017, at 09:44 AM

Administration

Goal: WAI-AA compliance

Steps to Cleanup (Zenify) a Package Page

View Page in a browser and view source of page
Check Doctype
Check Title (optional)
Check for H1-Hn and make sure they are in order. If not, make them so.
Close all HTML tags
Make sure there is no inline CSS
Add an ALT attribute for IMG tags
Add a TITLE attribute for A tags as necessary
Check all user visible text and make sure it is using message keys instead of text
If page has a form, make sure it is using formbuilder
If page has data in tabular format, make sure it is using listbuilder
Run accessibility tests

Doctype

First target: Validated HTML 4.01 Strict
Code:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
Background: Choosing a DOCTYPE. Why not XHTML? See http://www.hixie.ch/advocacy/xhtml

Basic Page Requirements

Title: should be in title tag, breadcrumbs, and h1 at top of page.
1. To accomplish that, ADP pages using the <master> tag should pass the following properties.
  
  <property name="title">Page Title</property>
  <property name="context">{ { breadcrumb_url link_title } .. last_breadcrumb_element, title unless there is a good reason for it to be something else}</property>
  
  You don't need to manually build the context bar UNLESS you want to include a URL that is not part of the site map. In other words, the context for 99% of pages should just be a one element list containing the page title or other text you want as the last element of the context bar. (DAVEB)
  
  Title and context variables are set in the Tcl file so the property call looks like this
  <property name="title">@title;literal@</property>
  <property name="context">@context;literal@</property>
Use message keys instead of text. https://openacs.org/doc/i18n-convert.html

Applying new CSS and HTML clean-up

Close HTML tags (LI, P, etc.)
ID attributes must start with a letter
Styles should be in CSS (no inline styles)
Provide an ALT attribute for IMG tags (chekpoint 1.1 - priority 1 - A). The ALT text should be localized. When the image is used for layout only, set an empty string for ALT (ALT="").
Clearly identify the target of each link (A tag) by providing an TITLE attribute (checkpoint 13.1 - priority 2 - AA). The text should be meaningful and localized. More Info: https://www.nngroup.com/articles/title-attribute/

For data tables, identify row and column headers (checkpoint 5.1 - priority 1 - A). The best is to use list template when it's possible. Otherwise, make sure:

your table has a summary tag
you use <caption><thead> <tfooot><tbody> where appropriate.
you give column and row headers a scope: <thead> <th id=""> <tbody> <td headers="">

If you headers are really long you give them abbr.

<table class="list-table" cellpadding="3" cellspacing="1" summary="Data for folders">
 <thead>
  <tr class="list-header">
   <th class="list-table" id="folders_name">Name</th>
   <th class="list-table" id="folders_type">Type</th>
   <th class="list-table" id="folders_size">Size</th>
  </tr>
 </thead>
 <tbody>
  <tr class="odd">
   <td class="list-table" headers="folders_name"><a href="#">Course 2 Files</a></td>
   <td class="list-table" headers="folders_type">folder</td>
   <td class="list-table" headers="folders_size">2 items</td>
  </tr>
  <tr class="even">
   <td class="list-table" headers="folders_name"><a href="#">Course 1 Files</a></td>
   <td class="list-table" headers="folders_type">folder</td>
   <td class="list-table" headers="folders_size">2 items</td>
  </tr>
 </tbody>
</table>

Form Builder and Template

All forms will use the default form template (standard.adp) now.
1. Therefore, there is no longer a need to have the "style" attribute in the formtemplate tag. (i.e. <formtemplate id=zen style=inline>). We can get rid of this attribute on all forms that currently use it.
2. Instead, there are different CSS classes that can be applied to all forms to get the same effect of inline.adp, plainest.adp, and other form templates while actually using the zen-ified standard.adp. The form class to be used is passed in the "html" parameter of the ad_form proc.
  - Example:
    - ad_form -name "zen" -method post -html {class vertical-form}..... -form {....}
    - This will render: <form name="zen" method="post" class="vertical-form">
List of form classes available and example URLs.
- Note: Example forms are checked into the 5.3 branch. Example files are listed below.
- margin-form : This is the default form class if none is passed to the ad_form proc
  - /packages/theme-zen/doc/forms/index*
- vertical-form
  - /packages/theme-zen/doc/forms/form-vertical*
- inline-form : Replaces inline.adp
  - /packages/theme-zen/doc/forms/form-inline*
Example:
- Change:
  - <formtemplate id=zen style=inline>
- To:
  - <formtemplate id=zen>
  - And modify the tcl ad_form call to pass a class to the form, so it will be like this:
    - ad_form -name "zen" ... -html {... class inline-form}.... -form {...}
If the form you working on started out as <formtemplate id="zen">, then you probably don't need to change the formtemplate or the form class. The defaults will most likely work fine. Look at the page in a browser and see how it is rendered. If you have any questions about which formtemplate to use, ask Mark Wylie.
Fieldsets and Fieldset Legends
1. Legends need to be short, there is no line wrapping for legends
2. more fieldset and legend info coming soon
If you have to hand code a form, it should look something like this:

<form class="margin-form">
 <fieldset>
  <legend>Short Legend</legend>
  <div class="form-item-wrapper">
   <div class="form-label">
    <label for="first_name">First Name</label>
     <div class="form-required-mark">(required)</div>
   </div>
   <div class="form-widget">
    <input type="text" name="first_name" id="first_name" size="30" />
   </div>
   <div class="form-help-text">
    <img src="images/icons/info.png" alt="info" width="16" height="16" /> Some info text
   </div>
   <div class="form-error">
    <img src="images/icons/exclamation.png" alt="error" width="16" height="16" /> This field was in error
   </div>
  </div>
  <div class="form-button">
   <input type="submit" name="formbutton:submit" value="submit" />
  </div>
 </fieldset>
</form>

Using sections in ad_form

The "section" element property is not longer supported. See Web_Forms for an example of how to use sections in ad-form.

List Builder and Template

When creating a list template that contains links, provide a title attribute (with a meaningful and localized text) for each of them (checkpoint 13.1 - priority 2 - AA). Example:

template::list::create \
    -name messages \
    -html [list summary "Summary title"] \
    -caption "Optional caption" \
    -multirow messages \
    -page_size $page_size \
    -page_query_name messages_select_paginate \
    -pass_properties { moderate_p } \
    -actions $actions \
    -elements {
        subject {
            label "[_ forums.Subject]"
            link_url_col message_url
            link_html {title "[_ forums.goto_thread_subject]" class "myclass"}
        }
    }

This is also true for actions list. Example:

lappend actions [_ forums.Post_a_New_Message]\
	[export_vars -base "${base_url}message-post" { forum_id }]\
	[_ forums.Post_a_New_Message]

New Parameters

caption - optional

summary - required for AA. There is a default in place: "Data for %list_name%"

W3C Web Content Accessibility Checkpoints

Zen aims at being Level AA compliant (priority 2 checkpoints):

Tools for Checking Accessibility

Accessibility Evaluation Toolbar (Firefox):

Disable javascript: alternatives should be provided to js actions
Disable styles (CSS): to verify the render for text only browsers
Disable images: ALT texts should appear for each image
Display title attribute: a meaningful title should be provided for each link
Linearize page: tables should linearize well
Validate local HTML
Validate local CSS
Validate local accessibility
Validate package and inline (if you're using the new inline class) CSS.

Colour Contrast Analyser ( Firefox):

Use the "Luminosity Contrast Ratio" option.
For the default CSS, the page should pass at level 2
For the HC (High Contrast) CSS, the page should pass at level 3

Fangs, the Screen Reader Emulator (Firefox)

Hera (automatic and manual reports)

WebXact (if HERA is not working)

Others tips

Use Opera's View/Small Screen mode to test the handheld.css.

Important Checkpoints

WCAG - Checkpoint 3.5: Use header elements to convey document structure
and use them according to specification.
WCAG - Checkpoint 5.3: Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent. Documents with two columns or more use tables to give structure. Layers should be used, instead.

References to this Page: en:docs-dev-tutorial, en:coding-standards-index, en:dotlrn-zen-bugbash Categories: Zen Project (OpenACS.org), Coding Standards (OpenACS.org), Accessibility (OpenACS.org)

WCAG 1.0 Checkpoints

Created by Emmanuelle Raffenne, last modified by Gustaf Neumann 02 Jun 2017, at 09:06 AM

Status at 21 october 2008 (OpenACS 5.4.3 and .LRN 2.4.1)

A summary for US Section 508 is available at LINK_TO_WIKIPAGE

See Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0 for details

How to read this document

Accessibility Compliance Level

Level A means that all the priority 1 checkpoints are in state "Y" or "n/a".
Level AA means that level A has been reached + all the priority 2 checkpoints are in state "Y" or "n/a"
Level AAA means that level AA has been reached + all the priority 3 checkpoints are in state "Y" or "n/a"

Checkpoint Status

Y: 100% of the pages comply with the checkpoint or the exceptions are clearly identified and listed in the accessibility statement.
N: NOT 100% of the pages comply with the checkpoint, exceptions are NOT identified.
n/a: the situation described in the checkpoint is not applicable in ANY of the pages

OpenACS-specific Techniques for Checkpoints

Each checkpoint is identified with a number which links to the OpenACS-specific techniques to apply it.

Note: the links are dead right now, but will point to OpenACS-specific techniques to implement them.

Priority 1 checkpoints

In General (Priority 1)	Yes	No	N/A
1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.	Y
2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup.	Y
4.1 Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions).	Y
6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.	Y
6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes.			n/a
7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker.	Y
14.1 Use the clearest and simplest language appropriate for a site's content.		N e.g.: portlet
And if you use images and image maps (Priority 1)	Yes	No	N/A
1.2 Provide redundant text links for each active region of a server-side image map.			n/a
9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.			n/a
And if you use tables (Priority 1)	Yes	No	N/A
5.1 For data tables, identify row and column headers.	Y
5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.	Y
And if you use frames (Priority 1)	Yes	No	N/A
12.1 Title each frame to facilitate frame identification and navigation.	Y
And if you use applets and scripts (Priority 1)	Yes	No	N/A
6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.		N lorsm
And if you use multimedia (Priority 1)	Yes	No	N/A
1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation.			n/a
1.4 For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation.			n/a
And if all else fails (Priority 1)	Yes	No	N/A
11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.		N lorsm

Priority 2 checkpoints

In General (Priority 2)	Yes	No	N/A
2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. [Priority 2 for images, Priority 3 for text].	Y
3.1 When an appropriate markup language exists, use markup rather than images to convey information.	Y
3.2 Create documents that validate to published formal grammars.	Y
3.3 Use style sheets to control layout and presentation.	Y
3.4 Use relative rather than absolute units in markup language attribute values and style sheet property values.		N calendar
3.5 Use header elements to convey document structure and use them according to specification.	Y
3.6 Mark up lists and list items properly.	Y
3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation.	Y
6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page.			n/a
7.2 Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off).	Y
7.4 Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages.	Y
7.5 Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects.	Y
10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user.	Y
11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported.	Y
11.2 Avoid deprecated features of W3C technologies.	Y
12.3 Divide large blocks of information into more manageable groups where natural and appropriate.			n/a
13.1 Clearly identify the target of each link.	Y
13.2 Provide metadata to add semantic information to pages and sites.	Y
13.3 Provide information about the general layout of a site (e.g., a site map or table of contents).	Y
13.4 Use navigation mechanisms in a consistent manner.	Y
And if you use tables (Priority 2)	Yes	No	N/A
5.3 Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version).	Y
5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting.	Y
And if you use frames (Priority 2)	Yes	No	N/A
12.2 Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone.	Y
And if you use forms (Priority 2)	Yes	No	N/A
10.2 Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned.	Y
12.4 Associate labels explicitly with their controls.	Y
And if you use applets and scripts (Priority 2)	Yes	No	N/A
6.4 For scripts and applets, ensure that event handlers are input device-independent.	Y
7.3 Until user agents allow users to freeze moving content, avoid movement in pages.			n/a
8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]	Y
9.2 Ensure that any element that has its own interface can be operated in a device-independent manner.			n/a
9.3 For scripts, specify logical event handlers rather than device-dependent event handlers.	Y

Priority 3 checkpoints

In General (Priority 3)	Yes	No	N/A
4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs.		N
4.3 Identify the primary natural language of a document.	Y
9.4 Create a logical tab order through links, form controls, and objects.		N
9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls.		N
10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links.	Y
11.3 Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.)	Y
13.5 Provide navigation bars to highlight and give access to the navigation mechanism.	Y
13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group.		N
13.7 If search functions are provided, enable different types of searches for different skill levels and preferences.		N
13.8 Place distinguishing information at the beginning of headings, paragraphs, lists, etc.			n/a
13.9 Provide information about document collections (i.e., documents comprising multiple pages.).	Y
13.10 Provide a means to skip over multi-line ASCII art.			n/a
14.2 Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page.			n/a
14.3 Create a style of presentation that is consistent across pages.		N
And if you use images and image maps (Priority 3)	Yes	No	N/A
1.5 Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map.			n/a
And if you use tables (Priority 3)	Yes	No	N/A
5.5 Provide summaries for tables.		N
5.6 Provide abbreviations for header labels.		N
10.3 Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns.		N
And if you use forms (Priority 3)	Yes	No	N/A
10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas.		N

References to this Page: en:coding-standards-index Categories: Zen Project (OpenACS.org), Coding Standards (OpenACS.org), Accessibility (OpenACS.org)