Accessibility
This page aims to list and document accessibility rules and best practices, to help core and plugins developpers to make Elgg the most accessible social engine framework that everyone dreams of.
Note
This is an ongoing work, please contribute on Github if you have some skills in this field!
Resources + references
List of practical techniques for implementing accessibility (It would be great if someone could go through this and filter out all the ones that are relevant to Elgg)
Tips for implementing accessibility
All accessibility-related tickets reported to trac should be tagged with “a11y”, short for “accessibility”
Use core views such as
output/*, andinput/*to generate markup, since we can bake a11y concerns into these viewsAll images should have a descriptive
altattribute. Spacer or purely decorative graphics should have blankaltattributesAll
<a>tags should have text or an accessible image inside. Otherwise screen readers will have to read the URL, which is a poor experience<a>tags should contain descriptive text, if possible, as opposed to generic text like “Click here”Markup should be valid
Themes should not reset “outline” to nothing.
:focusdeserves a special visual treatment so that handicapped users can know where they are
Tips for testing accessibility
Use the tools linked to from the resources section. Example report for community.elgg.org on June 16, 2012
Try different font-size/zoom settings in your browser and make sure the theme remains usable
Turn off css to make sure the sequential order of the page makes sense
Documentation objectives and principles
Main accessibility rules
collect and document best practices
Provide code examples
Keep the document simple and usable
Make it usable for both beginner developpers and experts (from most common and easiest changes to elaborate techniques)