One Platform, Many roles: How Different Teams Use Accessible Web RAMP | Webinar Video
Accessibility work rarely belongs to one person. Developers fix code, designers make decisions long before anything gets built, content teams publish new pages every week, and someone has to keep track of legal requirements and accommodation requests. When each group works from its own spreadsheet, things fall through the cracks.
Accessible Web RAMP gives those teams a shared place to find violations, organize the work, and track progress over time. Hope Alwine, Digital Accessibility Specialist, will walk through how each role uses RAMP day to day, and how the pieces connect.
What we’ll cover:
- How developers use Remediation Tasks and Remediation Instructions, and link tasks to tools like Jira
- How designers use the Figma Annotation Kit to flag issues before development starts
- Where content teams fit in, from automated page monitoring to the Accessible Web Helper Chrome extension
- How compliance leads use the Compliance Center and Accessibility Log to see which laws apply and document progress
- Setting up your organization in RAMP so the right people see the right work
Bring your specific RAMP questions — we encourage you to ask them live throughout the session!
Webinar Recording
Watch on YouTube for the full transcript.
Q&A
-
Yes. Conformance and usability are separate. You can be fully conformant and still have usability problems. Plenty of websites have usability issues even for sighted users and people who don’t use assistive technology. Usability always needs attention on top of a strong conformance foundation.
That’s one reason a feedback mechanism is critical, even after a full manual audit shows you’re fully WCAG conformant. Users need a way to report usability issues, and those reports should be treated as legitimate barriers even when they aren’t WCAG failures.
On our team, it’s almost a running joke that some things are “a bad experience for everyone.” The way WCAG is currently written and applied, something that’s equally bad for everyone can technically conform. That’s probably not your goal as a product owner or an organization.
Keep in mind that something annoying or inefficient for one person may be a barrier for someone else who doesn’t have the time, energy, or resources to work past it that day. That’s still an accessibility issue, even though WCAG doesn’t cover it.
-
It comes down to user preference. Whether or not someone uses assistive technology, they probably prefer different devices for different tasks. You might sit down at your laptop, with a full keyboard and a bigger screen, for one task. If you’re in the car and need to make a reservation, you’ll grab your phone. That’s why considering both is essential.
For screen reader users, the expected outcome is the same on mobile and desktop. They need to be able to perceive the information, operate and interact with it, understand it, and use the content with their technology across platforms. When content is designed correctly, screen readers on a phone and on a laptop should give the user similar information.
-
Yes. Screen readers keep adding customization options, and that lets people get the amount and type of information that matters most to them. Verbosity settings are one example. You can have every piece of punctuation read aloud. That helps if you’re writing code, but you probably don’t want to hear every period, comma, and quotation mark while you read a book for pleasure. Screen reader brands use different names for this, but most let you set up themes or profiles so your preferences fit a specific task, like writing code or editing documents.
If your content conforms to WCAG and you consult with users, settings shouldn’t affect whether someone can use it. A new screen reader user who knows a few navigation strategies and how to work with basic interactive components should have the same easy, frictionless experience as a power user who has everything set up exactly how they like it. Customizations let people choose how information is relayed to them. They aren’t meant to make up for inaccessible content or design.
That’s the intent behind WCAG, especially the requirements for what interactive components communicate about themselves. When components meet those requirements, assistive technology handles them consistently and adapts to each user’s settings. Users get the interactions they expect and hear information communicated the way they’re used to.
The best way to learn how users interact with your content is to talk to them, so build formal user feedback into your organization and your development practices. To go deeper on screen reader testing, including how it differs from the real user experience, watch our previous webinar, Screen Reader Testing: A Guide for Non-Native Users.
