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
- Normative wording of WCAG Success Criterion – it would be good to provide a link to the same
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)
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.