Some people in higher education don’t get universal design, especially when creating curriculum or web sites. UD isn’t about the branding or style. And it isn’t about accommodation or creating content for the lowest common denominator student (a phrase that borders on insulting to those students who are left out when universal design isn’t practiced). UD is about getting it right the first time by providing content accessible to all users, not just those with a disability. Instead of one-size-fits-all, UD recognizes that there are numerous sizes. The goal is to provide a continuum of sizes to fit each individual. To suggest otherwise is to miss the point entirely. Continue reading “universal design in education”
This ain’t your mom’s accessibility panel. This is how universal design benefits everyone, not just those with disabilities. Universal design is “design that is so thoughtful that it works for everyone from the start instead of needing to be ‘patched’ for the disabled.” The idea is to make a more enabled future for everyone, not just traditional disabled people.
The curb cuts (ramps) on sidewalks or roads are probably the best examples of universal design. Think about how many non-disabled people use those ramps for pushing strollers/prams, riding bikes or skateboards. This was a solution that helped everyone.
At least, tables (can) kill accessibility in web portals.
Accessibility in a portal has always been a challenge. It has to do (initially) with boxes.
Many early portals used quite hideous tables to layout the screen. Hey, a portal is a set of boxes, right? Oracle Portal still enforces a level of table-as-layout. Tables aren’t evil, but as layout devices they make it difficult to control keyboard interaction on a screen. You have to really implement them right to keep them accessible.
But my main problem with tables as a way to arrange a set of boxes is that the boxes (portlets) on a page are not always neat, tabular data in common rows and columns. Tables are for arranging tabular data. That means there are common relationships among the data sets.
A portlet is too complex an interaction to always fit as “tabular data”. The ways I want to navigate a table of numeric data is usually different from the way I want to interact with a portlet or group of portlets. For example, do I have to tab through every portlet (and inside through the inner elements) on the screen in order to get to the one I want (with the keyboard)? Or can I jump through HTML headers like every other well-formed webpage I encounter?
The other problem with tables is styling. Think about how difficult it is to style your own profile at MySpace. Nested tables to the nth degree. Portals are susceptible to this trap as well. Taking a beautiful Photoshop design of a portal interface and then attempting to style unclassed table cells (when tables themselves tend to break certain CSS layout rules–or better yet, when there is inline CSS inside a table definition that you cannot override!) is an exercise in insanity. I mention this because the level of design control I have over my content is usually closely related to the level of accessibility I can ensure in a page.
So the first accessibility challenge for portals is having enough control over the page layout interface to display portlets on a page in a way that is semantic and easy to interact with via a keyboard. The second is having enough freedom to make it look great.