Email Accessibility

• Subject lines: Simple, No-nonsense
• Preheaders (i.e., the snippet that shows up in the inbox view) need to clearly state the purpose of the email
• Use alt text for images (even for logos, "unimportant" information. Blind and low-vision folks don't want to "miss out" on information. If you've decided it's important enough to include in your email, it's important enough for alt text)
  • Buttons should be large, bold color, obvious, and should have ARIA labels
• Software like Salesforce, Constant Contact, and Mailchimp allow you to paste HTML code, which allows you to add ARIA roles, alt text, etc

• Will continue to use A, AA, and AAA to indicate 1st priority, 2nd priority, and 3rd priority
• 2.2 Guidelines will be more technically prescriptive, but will offer multiple ways to meet guidelines so designers still have control over look and feel of content
• New AA requirement: All functionality that uses dragging movement can be operated by a single pointer without dragging, unless dragging is essential (might have implications for creating highlights/annotations?)
• Requirement that users can find help for completing tasks (having a "Contact us" link meets this requirement, so Hypothesis will be covered)
• Accessible authentication: don't require users to remember an email/password or complete a CAPTCHA. Allow for social login, or provide "Email a login link" option.

Integrating Accessibility Into The Software Development Lifecycle

Link to Session

Segun Ola, Andela

After the Audit: Integrating Accessibility into the Testing Process

Link to session

Crystal Preston-Watson, Salesforce

Phases of audit:

• Start with one feature or set of features
• Testing (automated and manual)
• Result report
• Remediation of issues
• Re-testing and validation
• Accessibility conformance report

Tips

• Establish a baseline of knowledge
• Play to people's strengths - if someone is already proficient in keyboard-only navigation, they might be a good candidate to own screenreader testing
• Upskill whole org instead of making 1 or 2 people responsible
• Budget time for learning. Screenreaders are time consuming to learn
• Checklists are helpful but will need to be adapted for each feature / part of application.
• 20-40% issues are found with automated testing, which is why manual testing is needed
• bulk of automation should be unit tests. integration and UI tests should be less automated
• dedicate most of your resources to UI tests because that is the "human" portion - your users' experience is paramount

Improving PDF Accessibility with AI and Liquid Mode

Link to session

Robert Haverty, Adobe, Senior Product Manager, Document Cloud Accessibility

Rick Treitman, Adobe, Entrepreneur in Residence

Matthew Hardy, Adobe, Senior Engineering Manager, Document Cloud

Jamila Keba, Adobe, Frontend Developer for Acrobat’s Liquid Mode

Demo

• Reflows content to fit on small screens
• Takes headings to create an outline. Click on heading to go to that section of document
• Sections are collapsible
• font size, character spacing, and line height can be changed
• developed to be compatible with screenreader
• future areas of improvement: tables and images (using machine learning to create alt text when images don't have one)
• Currently available for mobile devices and Chromebooks where Android app can be loaded

Impact on readability

• allows users to increase text spacing, font size, etc
• student with 3rd grade school children with varying levels of fluency: one kid increased his speed by 27 words per minute, was able to read with inflection + meaning. even the fastest student jumped 27 words per minute.
• helps people who struggle to read, but also increases efficiency for proficient readers
• font, size, character spacing, line height, and character stretch seem to be the key factors in increasing efficiency.

Built in highlighter

• Used as a "ruler" to guide reader through document, not necessarily to make highlights/annotations to refer to later
• 4 ways of highlighting: mouse, underline, lightbox, and grey line
• No 1 solution worked better for the group as a whole - it was individual to the reader

Don’t Believe The Type!

Link to session

Gareth Ford Williams, BBC

David Bailey, BBC

Bruno Maag, Typeface designer

"Emotional accessibility"

• Is it appealing? Technical and functional aspects are meaningless if no one wants to use your product/tool
• Typeface = "visual tone of voice" and has a large bearing on emotional a11y

Readability group survey

• looking at series of fonts to see which they find most readable (also had people remove reading glasses if they use them)
• cognitive bias: we might find fonts used in system UIs and commonly used fonts easier to read just because we're used to seeing them
• 2022 user sessions, every font viewed 16,800 times
• Segments for participants: confident readers, glasses for reading, pinch-to-zoom user, larger font, colored text, farsightedness, dyslexia & similar characteristics

Font selection rate: all participants

• Open dyslexic, Comic Sans, Times new Roman selected least frequently
• Helvetica, Ubuntu, Roboto slab, etc did moderately well
• SF Pr, Segoe UI, BBC Reith Sans, Verdana selected most often
• But none of the fonts scored more than 70%
• How do we know people are choosing for readability and not aesthetics? We'd probably see no difference b/t those with dyslexia and those who don't have it

Font selection rate: Dyslexic traits

• Open Dyslexic, Dyslexie, Comic Sans MS performed better among dyslexic folks but they were still selected least frequently
• Helvetica, Roboto, Segoe UI, and SF Pro selected less often (5-10%) among dyslexic people

Poor near vision group

• Times New Roman and Helvetica see largest drop

Letter combos used to find issues

• "rn"in words like kernel, furnished, surname

Why some typefaces work better than other

• Top 4 performers: San Francisco Pro, Segoe UI, Verdana, BBC Reith Sans
• All sans serif, either grotesque or humanist
• Grotesque: closed character shapes - stroke terminal loops back into character
• Humanist: open character shapes - more akin to movement of handwriting (more distinction b/t shapes like c, e, and o)
• Why does Helvetica not perform well? Probably because of tight letter spacing
• Why does Ubuntu fall short even though it has hallmarks of humanist design? Font weight is stronger than other similar fonts, maybe just outside acceptable parameters. Or maybe it looks too modern.
• Why do dyslexic-specific fonts perform poorly? The irregularity claims to be beneficial to dyslexic people but maybe is too much, affecting smoothness of reading and emotional appeal
• Why does Comic Sans perform poorly, even though it's most used font and thought to be helpful to learning readers? No data to back up this claim, but it's possible the childish appearance is more appealing to young readers. But on the other hand, it could have performed poorly because it's trendy to hate Comic Sans.
• Is there an unconscious bias toward serif designs? Reading on a computer is more commonplace, and perhaps we associate sans serif with screens and serif with print.
• Times New Roman has some characteristics of fonts that perform well, but letter spacing is tight.
• Lower-case g: modern g is not necessarily more accessible, or we'd expect Roboto to perform better
• x-height impacts perceived size, even at same font-size. Smaller x-height is perceived as "less readable"

Yes, Virginia, PMs Are Responsible for Accessibility

Link to Session

Angela Hooker, Microsoft

Why build in a11y from the start?

• Much easier / less "expensive" than adding it after the fact.
• PMs are expected to set expectations and manage scope. Set the expectation from the beginning that team delivers accessible product.
• Consider budget, timeline, people, & other resources. The design phase is "too late."

Getting support from leadership

• Talk about ROI & $8+ trillion in disposable income that people with disabilities have worldwide
• Helps the org be more competitive
• Show them how inaccessible content hurts. Demo use of product with a screenreader with no visuals, ask them to navigate with keyboard only. If possible, have a person with access needs do that demo.

Include multiple accessibility reviews in your timeline

• Team should check their work as they go along

Choose the standards and level of compliance you'll achieve

• Compliance and accessibility are not the same. You can conform to WCAG 100% but be unusable for people with certain disabilities
• If project is used globally, consider laws worldwide. Some countries require specific documentation & standards will vary

Put accessibility requirements in contracts with outside vendors

• Be specific about the standards they need to meet
• Ask for proof they can produce accessible work

Carefully choose the tech you'll use to build your project

• If you don't have a choice in what tech you'll use, see if team can fix those a11y issues. If it would expand scope or timeline to do so, flag as risk for leaderships

Document all your team's work

• Good to have on hand for showing "good faith effort" to be accessible
• Prepare a general statement about project's a11y status.
• Document known a11y issues and create a roadmap for resolving

Get training for your team

• Pointing toward info on the web is risky, as there is lots of misinformation. Start with info from W3C a11y curriculum.

How do you coach your team and oversee their work?

• Don't make it about any one person. Discourage things like "if we can't make you happy, we can't move forward." It's not about you being happy, it's about putting out the most usable and successful product you can!
• Publicly praise team members as a way to motivate them to prioritize a11y in the long run

Written content comes first

• This is the easiest to remediate, so get this out of the way.
• Ask people with cognitive impairments to read through with you to find out where things might not be clear

Working with designers

• Annotate design docs to indicate to engineering where they'll need to consider a11y
• Review mockups & wireframes for missing a11y considerations so eng can raise concerns or questions
• Start with user personas based on people with disabilities
• Invest in usability testing at several points during project build

What if you're updating a legacy project?

• Start small
• Have an auditor review for a11y and create a plan to give team "quick wins." Create roadmap for remaining items.
• Talk to team responsible for product to find out what questions/concerns they have
• Get training & other needed resources for team

From Nothing to Something: How A Team of 2 Kickstarted an Accessibility Program

Link to presentation

Alexis Lucio, Splunk, Accessibility and Inclusive Design Lead

Simarjeet (Sim) Kaur Splunk, Software Accessibility Engineer

Splunk: a tool to help devs monitor, secure, and troubleshoot dev environments.

• First step is to learn the product and map out current state of a11y. Review available VPATs, evaluate test cases for a11y and improve where necessary, gather existing bug reports for a11y issues.
• Find mentors in the a11y space
• Pass info to rest of company in a digestible format. Alexis started a program called "A11y Hour" where colleagues were invited to come learn about disability and accessibility topics
• Prioritize customer-generated issues
• Work with developers to test for a11y during development, not after
• Evaluate how you're doing: how many a11y issues are opened vs closed? And set goals for improvement from there.
• Form a network within the company, and pool together your external networks
• Advocate for a11y-specific headcount
• Tailor the business case for a11y based on who you're talking to. When speaking to designers, "the right thing to do, ethically" is effective. But for other stakeholders, consider angles like financial, legal, tech debt, sales/competition, industry regulation, SEO...
• Provide specific examples of a11y done well for inspiration (where possible, use NVDA/JAWS and take away visuals so sighted folks get same experience as Blind folks)
• Put together a detailed proposal, so all leadership has to do is "Say yes"
• Open a communication channel for the company to use: Slack channel worked well at Splunk. Helps to "democratize knowledge" - if a Q is asked more than once, pin it as part of an FAQ.
• Create resources to share with rest of org: for example, learning session that can be part of new employee bootcamp
• Advocate for company-wide OKR for a11y

The Landscape of Digital Accessibility in Higher Education

Link to presentation

Charles Collick Jr, Rutgers

Pat Kogos, University of Chicago

Nate Evans, Michigan State University

Handling legacy applications

• Involve students! Paid or volunteer. They can edit captions, add alt text, etc, and have first-hand perspective on student needs & experience
• Use a priority-based approach to determine how you can make the biggest impact on faculty and students
• If anything can be sunset, retire it rather than allocating resources toward overhauling
• Anything that has high usage and directly impacts learning & research activities should be hi-pri

Securing budget for a11y & promoting culture

• Focus on storytelling and "sell" the need for a11y as much as possible. Start with the "why" before trying to secure cash
• Focus on the benefits rather than threatening with negative consequences
• Diversity, Equity & Inclusion gaining traction in the higher ed world right now. Those are likely the ideal folks to partner with.
• Student experience also a more popular topic these days - tie to a11y.
• "Get in trouble" - call attention to things that aren't accessible, taking to Twitter/public forums when appropriate

Consortiums

• While the speakers on this panel don't participate in buying consortiums, lots of info sharing (if one school reviews a tool for a11y they might share the results of those audits across the consortium)
• To watch: Big 10 Alliance: Library E-Resource Accessibility

Tools used to evaluate a11y and share results back to content owners

• Enterprise tools allow for more robust reporting than free tools
• Using built-in a11y tools in Canvas, Blackboard Ally
• Axe & Deque are popular tools

Getting Faculty buy-in

• Teaching & Learning with Tech groups help with outreach
• Make a11y part of conversation about course design & pedagogy

What initiatives are you excited about for 2021? And If you could recommend ONE change to improve web a11y in higher ed, what would that be?

• Rutgers: Initiatives: New procurement process, Ally rollout, and mandatory training for IT. The one recommended change: awareness.
• U Chicago: Initiatives: Scaling up use of enterprise tool, training for IT staff & faculty. 1 Recommended change: integrating a11y into processes from beginning.
• U Mich: launching a11y audit team, including hiring students. 1 recommended change: don't think you have to be perfect to get started or make progress.

Building Accessibility Success within Smaller Enterprise Companies

Ted Drake, Intuit

Link to Session

Getting Started

• Assess company's needs: regulatory environment? resource-strapped startup? are you about to go public & concerned with PR?
• Build goodwill with leadership and keep communication lines open (CEO, CTO, product leaders, etc)

1, 3, and 5 year goals

• 1 year: get to know all products/aspect of product intimately
• 2 year: documentation
• 3 year: "low-hanging fruit" and basic compliance
• 4 year: work with customers and contributors to get real user feedback from disabled customers
• 5 year: Set goals for metrics that will be used in perpetuity with regular testing

Tips for Success

• Build support within the org - idea: "Accessibility Champions" program. Have devs set up their computers for keyboard only testing, install certain browser plugins, etc.
• Develop empathy: record and share customer interviews, create personas, empathy exercises (put on a mask & use your product with a screenreader)
• Include developers and designers in customer research
• Transparency: blog posts, internal comms

ROI of Accessibility

Greg Williams, Deque Systems

Link to Session

4 main business cases (eCommerce case study):

• Increasing market share
• Controlling operational costs
• Managing risk profile
• Aligning digital presence with company core values

Increasing market share

• after-tax income for working-age people with disabilities in the US: $490 billion
• 20 million (35% of all people with disabilities) are US working age adults, age 16-64
• If you're not accessible and your competitor is, you lose that market share
• Vision, Hearing, Ambulatory, and Cognitive are most common disabilities
• Inaccessible e-commerce retailers losing out on $6.9B annually

Controlling operational costs

• "Click-in" payment costs much lower than call-in, mail-in, and walk-in (brick & mortar). Pushing to digital channel cuts costs - up to $14m. Can't push disabled customers to digital if experience is inaccessible.
• Blind users call company's customer service department 1x/week on average because of website inaccessibility. They call multiple times even when they have abandoned the transaction. Save time & $ on customer service calls.

Risk management

• approx 10k ADA lawsuits per year. CA, NY, and FL are where lawsuits are most prevalent
• potential cost of complaints: blended rate of $120/hr when you consider support personnel, compliance/regulatory personnel, product management, devs, QA, testing, etc
• calculating proactive vs reactive fix loss, assuming 100 complaints annually, upwards of $1m per year cost for "reactive" fixes
• lawsuits: blended rate of $225/hr assuming company leadership, legal council, external SMEs, etc are involved
• DOJ could levy fine of $96,834 for first action while still requiring website to become accessible

Alignment with core values

• If mission or motto is to be inclusive, customer-centric, etc, are you really meeting that mission if you don't include a11y in priorities?
• Customers increasingly want to purchase from companies that share their view
• Consumers who have a negative or positive experience re: a11y tend to share with family and friends