Incorporating accessibility into your product - UPA 2012 unconference
Tips for incorporatingaccessibility into your product An “unconference” talk Amanda Nance, @amandaux Senior Usability Analyst at Sage June 7, 2012 Usability Professionals’ Association
Four broad categories1. Educate the product team2. Get buy in for allocating developer time to accessibility3. Create checklists and processes4. The secret sauce
1. Educate• Educate designers – Accessibility starts with good design! – Design-specific issues include text size, color contrast, multimedia captions, etc.• Teach QA how to test for accessibility – Have QA team include test plans about accessibility
1. Educate• Educate the development and QA teams further – Show virtual seminars – Share top accessibility resources such as WebAIM.org• Name a developer the accessibility expert – Typically, user experience practitioners can’t provide all of the programming advice that developers need. A developer can create coding guidelines for your product’s language and be a resource to other developers. – Naming a developer as the expert may make them feel more responsible and engaged in accessibility issues.• Show a test of your product with a disabled user
2. Get buy in for developer time• If developers aren’t given time to learn about accessibility, you will always have difficulty• There are many resources on how to get buy in, and different arguments work for different stakeholders. – It’s the right thing to do – It takes minimal effort to be accessible, especially if accessibility is considered up front – Fear of bad press if product is not accessible – Its the law (depending on your country and industry)
3. Create checklists and processes• Make checklists specific to each role (e.g., developer checklist, designer checklist). – Start with a shorter, high priority checklist. Accessibility novices may be overwhelmed with a long, thorough accessibility checklist. – Exclude “one-time code” from the short checklist. For example, skip navigationand landmark code should be included a reusable template. Therefore, developers don’t need to remember it for each separate feature.
3. Create checklists and processes• Sit with developers to check for accessibility – My team reviews a new feature before the developer checks in code. This review is a great time to do a quick check for accessibility issues.• Send developers the code or “how to” resources – Developers appreciate anything you can do to help them learn accessibility or meet accessibility goals more quickly.
3. Create checklists and processes• Include accessibility requirements in the design specification and/or UI style guide – For example, guidelines for using H1, H2, and fieldset• When you review the product with the team, check for accessibility issues (e.g., during the sprint demo)• Include an accessibility check in developer code reviews• Write defects for accessibility issues
4. The secret sauce• Lather. Rinse. Repeat if necessary.• In other words, you may have to remind your team about accessibility.• And remind them again.• And again.• Be encouraging and patient with your team. Forming new habits is difficult.