I dislike this question. It’s not because I tend to dodge conversations about accessibility that I dislike the question – but rather because it’s so black and white. It frames accessibility as a checklist or series of milestones. It suggests that having good link names, page names, alt text, etc. magically makes a website accessible and that we can check some compliance box and stop working.
Standards are a great tool. They set an excellent baseline for accessibility and help disparate groups work towards a common goal of cross platform and assistive technology support – but they should never been seen as the ultimate goal. When we think beyond standards and checklists, we remember the moral and societal commitments that drive accessibility.
Non-Disclosure
While standards don’t currently require this, morally, a web application should avoid requiring that a person disclose their disability.
For instance, a student shouldn’t have to go to disability services in order to get access to system orientation information. This should be readily available, for all users. Similarly, a student shouldn’t have to expose their needs to classmates. They shouldn’t have to ask classmates to “turn on” an accessibility feature so they can participate in a project group. The system should enable accessibility features by default.
Individualization
When we’re creating learning materials, assessments, software, etc., it’s important to remember that each individual’s needs are unique. Disability isn’t a Venn diagram. There aren’t tidy groups of people with exactly the same needs; rather, everyone has unique learning needs and preferences, and as educators and technology designers we need to support and embrace these differences.
Instead of a “one size fits all” approach, applications should be configurable and adaptable. This goes beyond favorite colors and nice background pictures. Like a good room layout, with outlets, lighting and windows in all the right places, web applications should offer a basic, flexible context that individuals can organize and adapt to their needs and preferences.
Inclusion, not accommodation
Finally, we should not lose sight of the overall goal of equality. Full inclusion is different from accommodation. Accommodation sounds like a favor. A certain amount of timeliness, quality and availability is implied in inclusion. Inclusion means that accessibility is not an afterthought or alternative, but a part of a seamless experience.
People with disabilities don’t want to use buggy or confusing features. They don’t want to have to request alternative resources. They want to participate in real-time, in the same engaging environment as their peers.
Expanding the conversation
Instead of asking – are you compliant – I would love to hear someone ask – “how do you support full participation by people with disabilities?” This type of open question encourages technology providers to focus on how their technologies support real people and provide real opportunities for growth and learning, rather than reducing accessibility to a checklist.
What do you think? Let’s dialogue. You’re also invited to join our next interest group meeting on April 7 at 11 a.m. ET. Meeting details are sent through our mailing list: https://behemoth.wac.ohio-state.edu/mailman/listinfo/d2l-consortium
Comment Submitted
Thank you for your comment