Summary of Accessibility Summit 2016: Reports that designers and Developers love

OK, next up was my good friend, a man of demos, known for mobile accessibility – Paul J Adam presenting Reports that designers and developers love.

Paul has demonstrated report formats that designers and developers love and tips to create good accessibility assessment reports. His presentation was consist of Scoping the website / mobile app, Finding issues, segregating, navigation through report and advantages of such a report.

Began with Scope. Scoping of project is critical and it’s essential to capture information like:

  • Does this project require any VPN access? if yes, ensure credentials are in place
  • Does this project include any documents like PDF, Word etc.,
  • What are the standards that would need project to comply with; Web Content Accessibility Guidelines (WCAG), Air Carriers Accessibility Act (ACAA), Communication and Video Accessibility act (CVAA) etc.,
  • Identify if all pages and flows are within scope?
  • Assistive Technology User flow
  • Credit Card info (if needed)
  • It’s also important to know if site has a session time-out

While preparing a report, it would be good to capture common components like Header, Footer, Navigation, common widgets like social media icons, models, calendar, error handling etc., as Project Wide; there is no need to report as separate issues for each page. This will help both testers and developers. Developers can just pick Project wide issues, fix them and that would solve a lot of problems often.

Screenshots are important Yes, indeed screenshots play an important role to reproduce issues reported. It is important to identify location of issue that you are talking about. Do NOT misunderstand difference between Subject Matter Expert and Client. Client may not even know what WCAG is. Especially screenshots are useful when viewing the report after a gap (which happens quite often) and site gets changed. Shows where the issues is actually exist. Issue description could become alternate text to screenshot to benefit developers who are blind. Remember to include screenshot of what you are actually testing.

Some questions that gets addressed in the report:

  • Who faces this problem? a keyboard only user, Assistive Technology user or both, Is it a problem due to color contrast and affects people with low vision, elderly or cognitive? etc.,
  • What is WCAG Success Criterion?
  • How can this be fixed?
  • Where is this problem? (Screenshot will answer) – but be sure that add description along with screenshot
  • How big is the negative impact of the issue? Please be honest about impact. It would be good to include a demo (if possible a screen cast)

  • Normative wording of WCAG Success Criterion – it would be good to provide a link to the same

It is very important to call out impact of the issue; Is it Critical where user cannot carry out the task, Serious if user can perform the task but with some difficulty, other categories are major and minor.

It’s also important to use color coding in the report to highlight Critical failures in red, Serious failures in Orange, major and minor in shade of Yellow and Pass issues in green etc., This would be make readability of the report easy.

Be cautious while writing a recommendation It’s important to be careful while providing a recommendation. Be practical and be nice.

It’s important to write good description of the issue, steps to reproduce and if possible a code example.

It would be good to use collaborative tools like iCloud, Google drive etc., this helps multiple resources to work together.

Peer reviews are greatly important. Different ways can be used to provide feedback. Something like Insert comments in the report, add a new column to write reports, exchange emails or set up a meeting. Whatever works the best!

Paul, enjoyed your presentation and thank you for great talk.

Link to Paul Adam’s Slide Deck

Desclaimer:These are not exact words used by Paul Adam.

Summary of Accessibility Summit 2016 – PM Led Accessibility

Thanks to Joseph O’Connor, I have attended recent Accessibility Summit – a virtual conference on Accessibility that was held on 7th and 8th Septmber, 2016.

It was amazing to see that summit organizers took as much care as they could to make the event accessible. Speakers have described everything that they have shown visually and closed captions were provided live.

Ari Stile kicked off the event with a welcome note and housekeeping tips. She admired Adobe Connect as the platform has become much responsive than ever before but suggested audience to use wired connection better quality. Other option is to turn off the video; they keep running cameras because some people might love lip reading (either by choice or by necessary – again inclusion here!).

First talk was by Robert – a Project Manager and title of the talk is “PM Led Accessibility”; it was very insightful to hear how Project managers / product owners can create a great impact. He began explaining about typical roles of a PM that includes, managing timelines, deliverable, taks, communication, risk mitigation, resourcing, requirements, scoping etc.,

So whose responsibility is accessibility? Can PM take this responsibility; the answer is Yes! and how that can be done; by having little learning about accessibility, having empathetic mindset, have understanding about accessibility requirements and roles of resources. It’s important to include discussion about accessibility in Project meetings, let me know about risk if product does not comply with accessibility standards. Even if product does not have an accessibility requirement, it’s still be a risk from legal prospective. It’s obvious that as the progress, there will be resistance or setbacks about accessibility but being firm is important. Ask coworkers how the product would work for diverse users like people who are blind, hard of hearing, cognitive disabilities, elderly etc.,

It’s also important to educate resources about the impact accessibility creates. Showcase examples like how product having low color contrast would impact users when viewing on a mobile device in a sun light environment etc.,

Robert has recommended one should read book “Reimagine Empathy” by Paul Parkins (unfortunately, I couldn’t find this book online; if anyone does, please leave the link in comments section please…).

If you are new to accessibility, that’s Okay, ask for help. There are a lot of wonderful people and forums like WebAIM who would be happy to help. It’s good to seek help rather than spending your time. Of course, research is good too!

Let us, however, agree that accessibility is not single line item and all stakeholders has to put in efforts as per their roles and responsibilities. For instance, designers should design products keeping inclusion in mind, developers should code keeping semantics and standards in mind. QA folks should include accessibility into their test plans. Accessibility should be discussed in product / project status meetings. Communication plays a key role to achieve goals.

Some resources that Robert has mentioned in his presentation:

Then Robert discusses about significant risks with accessibility problems. Includes litigations happening in all industries, people demanding rightfully equal access, law suits etc.,

Accessibility of a project can be achieved by raising awareness among all stakeholders, reporting accessibility progress, knowing when to ask for help, as needed, bring in accessibility consultants on board, etc.,

Robert has also recommended people reading Developing a Web Accessibility Business Case for you, Accessibility Business Case by Karl Groves and Website of Lainey Feingold – an advocate who does a fantastic work in the area of accessibility advocacy and structured negotiations that could lead to win-win situation.

Then Robert focuses on a few tips how to get the accessibility work done. Well, PMs has great power; they can dictate! But a constructive discussion brings the success. When providing a feedback about accessibility, start conversation with positive notes and say something like “Hey buddy, you are great; you love code, how about adding that love to accessibility too?”. Make sure to bring back the focus as you notice. Recall project requirements so that it stays on everyone’s thinking. At times, you may need to esclate too. If situation minor, just mark in tracking system but if issue is major, call all stakeholders for a discussion.

When there was a question about what Robert would advice to deal with B2B companies, he says that though B2B companies doesn’t directly deal with consumers, we never know if business that company is dealing with may have people with disabilities in stakeholders. Today given that technology does a great job and make things possible, anyone can take up any job… I agree with Robert.

That concludes session of Robert; Next post will be about Paul Adam’s Presentation titled “Reports that designers and developers love”. Stay tuned!

Visit Robert Jolly’s website for slide deck

Disclaimer: These are not exact words that Robert have used.