Accessibility - the art (and almost-standard) of making webpages accessible to the vision-impaired as well as others.
- Augmented Accessibility: Initial page is fully accessible, then it is augmented with javascript to make it more usable.
- Example: load all expandable sections fully expanded, and then run javascript onload that contracts them.
- Why this is good: in the event of no javascript, the page is still entirely visible. Also doesn’t require too much extra development. Generally the easiest of all options to implement—generally.
- Why this is bad: potential flicker. More javascript code required in the app. Javascript is notoriously difficult to debug.
- Gracefully Degraded Accessibility: Initial page is more usable, with accessibility fall backs when javascript is absent.
- Example: load the sections contracted. The javascript-based links to expand the sections have a backup URL, in the event of no javascript, that reloads the page from the server with the selected section (or all sections) expanded.
- Why this is good: the usable page loads guaranteed without any flicker, we only accommodate the javascript-disabled crowd in the rare extremity that they exist.
- Why this is bad: more development time.
- Informed Accessibility: Initial page is more usable, unless a server flag indicates accessibility-compliance, and then the page conforms primarily to accessibility demands and only secondly to usability concerns.
- Example: loads all sections contracted. If a flag on the server is set, then all the sections are loaded expanded.
- Why this is good: doesn’t require too much extra dev time, and every user gets what is suited to him/her.
- Why this is bad: there are all kinds of dilemmas about how/when one sets this flag. My personal favorite is a ‘Simplified HTML’ option on the site that allows people to specify they want something not so flashy, but with all the information/functionality. (ie. Something Accessible.)
Comments
