axe-con 2024: Day One (Ashley)

Once again Deque tweaked their conference format, going back from two days to three, but ending the day sooner. It will definitely allow me to attend more talks, and hopefully with less fatigue, but I'll reserve judgement on the lack of lunch break until the end of the conference. Without further ado, here are my thoughts on the talks I attended on day one of axe-con this year!

Responsible and Ethical AI

Speaker: Dr. Rumman Chodhury, Responsible AI Fellow, Harvard University, co-founder and CEO of the nonprofit Human Intelligence, and former Director of AI Ethics, Twitter

For a more in-depth review of this talk, take a look at Riley's axe-con Day One article, but I will say that I thought this was a great talk, and definitely got me thinking about our responsibilities as developers to look at different ways to use AI in an ethical way, and not to always work towards the 'average,' and likely excluding large groups of people in that process.

Human-Centered AI and Accessibility

Speakers: Dylan Barrell, CTO and Author, Preety Kumar, CEO, Founder & Board Member, both of Deque Systems

This talk gave some interesting insights into Deque's history, and how they first sought to create an automated testing tool that tested for 100% of problems. The result? Inaccurate and and disastrous. Their shift toward a model of 0 false positives, and working more slowly to increase issue coverage, created a much better product.

But their human centered approach to digital accessibility helped them to craft the tool and its priorities. Which issues have a bigger impact on users? On businesses? Which types of errors are most common? Most disruptive? Easiest to fix? Building tools around these problems resulted in real-world reduction of defects. Having seen how axe has developed over the last several years, seeing these changes is exciting!

So how did they relate this to AI? Dylan Barrell explored the concept of "socially beneficial," one of Google's AI principles. With regards to disability and using AI for digital equality, the human still needs to be in control, and the platform needs to be transparent to avoid false expectations and misinformation. AI has its flaws, and depending on the model, can deliver very different results in response to the same source.

He described some potential human-centric uses for AI, such as generating text in a CMS that an admin can then edit, or to generate descriptions on demand when one is not present. This can allow users to ask additional questions about an image that aren't covered in its alternative text. These ideas, while exciting, do make me nervous because of biases that many models have, or, if used as an assistant authoring tool, is abused and not edited for accuracy and context.

The other part of this equation is enabling people to create accessible experiences (ATAG, anyone?). AI can assist with this in a variety of ways, including object detection, speech to text, image description, code generation, code remediation, and answering questions. I know I've encountered most of these at some level of frequency in recent years. Again, the risk of these is relying too heavily on AI and not editing/evaluating for accuracy, which can result in new barriers being added even as as others are resolved. But, if we as developers can leverage these AI technologies and balance it with transparency and human evaluation, then these tools could empower the masses to create accessible content.

Bottom line? AI is exciting, but still a work in progress, and it's up to all of us to guide the development of AI in a human-centric direction that benefits people in an impactful way.

The Digital Accessibility Legal Landscape

Speakers: Lainey Feingold, Law Office of Laney Feingold, Disability Rights Lawyer, Author

I think the legal talk they do every year is destined to have technical difficulties. I began attending this talk by reading the live transcription, which was working when the video was not. However, the content was good, and thanks to having this accessible alternative, I was able to get the information!

I liked that as a lawyer, her perspective was that collaboration is worth a shot before lawsuits. Because in the mind of many business owners, lawsuits are a hassle and puts them in a negative mindset. Collaboration, however, can ease stress and actually result in a better user-centered solution, instead of just checking a box to get the monkey off your back.

She described digital access as both a door and a bridge. It connects people, and can lead to opportunities...or block them. Barriers she illustrated as stairs, which before the ADA were a major barrier to public spaces, before enforcing ramps and elevators. Today's digital barriers are yesterday's steps. So what is digital accessibility from a legal perspective? Privacy and security for disabled people, and essential aspect of the DEI community, an ethics issue, and, most importantly, a civil right.

She also pointed out that the federal court system is divided into twelve circuits, and each one might interpret the law differently. That's why we end up getting things overturned from district to circuit courts, as cases have different interpretations. I must say I liked her stance that the ADA is applicable to everything in the digital space. She's not alone in her opinion, but it's unfortunately far from unanimous. But the U.S. is inching along, with Acts and laws like the ADA, Air Carriers Act, Section 508, CVAA, and more. Some of these acts and laws use WCAG as a base, but most will reference it regardless of whether it is included in the wording of the law.

The point of these different opinions and interpretations is to look at how cases are ruled in districts all over the country (or globally, if that's your audience), you should be basing your accessibility compliance off of laws and court rulings from everywhere, not just how it is in your own district court. States like California and New York have anti-discrimination laws that digital accessibility would fall under. Maryland has a K-12 procurement law. Maine has a state law forbidding overlays for its digital services and requires native solutions instead (Maine, that's awesome!). So unless you're restricting site access to these different areas, building your site accessibly is the best way to go.

So what happens when you do have a case filed against you? You have to fix the barriers and systems that have issues in the first place, pay fines up to 150k, and pay the plaintiff, their laywers, your lawyers...in other words, you have a headache on your hands. And that's just how things are now.

So what does the future look like? Here are some proposed laws and regulations to keep an eye on:

1. Websites and Software Apps Law (Federal Level): The FAQs on this one includes a juicy snippet that confirms that the ADA applies to the digital space. That is one of the biggest questions in accessibility lawsuits today, so confirming that in an official law will make things a lot more clear!
2. Communications, Video, and Technology Accessibility Act (CVTA)
3. CA Bill AB 1757: clarifies and strengthens law around web accessibility. It didn't pass last year, but could possibly pass this year.
4. Title II web and mobile regulations
5. Self-service transaction terminals (kiosks)
6. Healthcare (HHS 504 Update)
7. ACA Update
8. FCC Video conferencing

There also exists guidance in certain sectors:

1. DOJ + HHS Telehealth Guidance (7/22)
2. DOG + EEOC AI Hiring Tool guidance (5/22)
3. Biden's AI Executive Orders
4. Dear Colleague DOE/DOJ Letter (7/23)

Enforcement of these laws and guidelines comes down to people with disabilities advocating for themselves, government agencies, lawsuits, etc. There are currently digital accessibility cases in the public sector, education, employment, kiosks, podcasts, and more. 933 cases in 2023 were against companies using an overlay! Over 700 cases were against defendants that were already sued for accessibility at least once before. And 97% of these cases were against websites.

The biggest takeaway from this talk? Don't wait. Don't wait for the laws to specifically enforce digital accessibility. Don't wait for a lawsuit to come in. Be proactive in making your digital experiences accessible, not reactive, since we already know what's coming.

What WCAG 2.2 Means for Native Mobile Accessibility

Speakers: Rachael Yomtoob, Developer Advocate, Devanshu Chandra, Android Developer, both of Deque Systems

This talk kicked off with some bread and butter information about the history of WCAG, which I won't go into here, but was good to have a review of its development up to this point. Then they went into how accessibility applies to mobile apps.

Native mobile apps follow different rules in their development and execution than websites. They are rendered in native mobile views, with native styles instead of css, and different operating systems have different assistive technologies and accessibility features that can result in different interpretation of content. So how does WCAG 2.2 (launched in 2023), which had a focus on mobile accessibility, apply to native mobile apps? According to Devanshu, some of the criteria applies directly, but others don't. And some of the criteria should be carefully interpreted into a native mobile equivalent. to still try to create an accessible experience.

I was interested to hear about the mobile-centered AGWG (Accessibility Guidelines Working Group) task forces, which are working groups that focus on mobile. One is the Mobile Accessibility Task Force, the other is the WCAG2ICT Task Force.

Three of the newly introduce WCAG 2.2 criteria are centered around focus management (minimal and advanced). For mobile apps, full keyboard access needs to be turned on to be able to fully test this criteria. One set of criteria is 2.4.11 (AA) & 2.4.12 (AAA), Focus Not Obscured. This criteria is luckily automatically met as long as you follow best practices from Apple and Google. However, developers should take care not to create content that is obscured by other content, though assistive technology will still correctly handle focus management underneath. Another new focus-centered criteria is 2.4.13 Focus Appearance (AAA). This is also largely inapplicable to native mobile apps, since focus is handled by the user agent and can't be adjusted by the author in iOS and Google, though some others do have that power. 

Another criteria is related to movement of content, 2.5.7 Dragging Movements (AA). This criteria, that states that drag & drop functionality needs an alternative method to accomplish the same task. This is for people with motor control disabilities, or even just fat fingers. This equivalent function should not rely on dragging, but involve only taps and clicks. The WCAG2ICT working group notes that this doesn't technically apply if the user agent or assistive technology offers the alternative, but since it's still confusing and time-consuming, it should still be supported in mobile apps.

Target size isn't a new idea by a long shot, but is defined as success criteria in 2.5.8 Target Size (Minimum, AA) and the updated 2.5.5 Target Size (Enhanced, AAA). Basically, controls need to be at least 24x24 pixels for minimum, 44x44 pixels for AAA compliance. But this doesn't necessarily mean the size of the button, but the button and the spacing around it. So, if you have a set of 20x20 pixel buttons, as long as there's 4px of space between each one, you've still met the touch target minimum size. Inline links are an exception to this criteria, but so are user agent controls that can't be modified by the author. Luckily, default components in from Apple and Google met this criteria.

3.2.6 Consistent Help (A), means that help needs to be provided consistently and in the same pattern. Native mobile apps don't need to provide help in the same place everywhere, but if it is offered on multiple screens, it should be in the same place, and in cases of changes in orientation, it should also maintain its position in the flow of content.

Not being a builder of mobile apps myself, I found this interesting to see how the rules of application are different for native mobile apps vs. websites. It's not something I've had to think about a lot. But I'll be keeping my eye out for how these apply to the apps I have on my phone for sure!

Future of Accessibility Guidelines

Speakers: Wilco Fiers, Senior Accessibility Engineer, Glenda Sims, Chief Information Accessibility Officer, both of Deque Systems

I'm always excited to hear about this subject, since WCAG 3.0 has been in development for awhile now. Unfortunately it had to be shortened due to technical difficulties (ah, what is a virtual conference without those?), so they didn't go as in depth as I would have liked.

One thing I learned that I didn't know was hat there were over 600 open issues on WCAG 2! But luckily, 2.2 helped to close over 80 of these. Progress! But the question is, will there be a WCAG 2.3, or will the focus be on WCAG 3.0? As of right now, WCAG 3.0 is the focus (yay!). So let's hope 2.2 can hold us over until 3.0 is ready.

So how is WCAG 3.0 different from 2.2? Principles will be removed, guidelines will translate over, and success criteria will become outcomes. There are a handful of other changes as well, one of the most notable being navigating away from A, AA, and AAA and moving to bronze, silver, and gold as ways to evaluate levels of conformance within each outcome. Outcomes are currently being sorted as drafts into meaningful categories, and will be crafted to be testable. Another aspect to look forward to will be outcomes related to cognitive accessibility, an area largely untouched by WCAG 2.x. To top it all off, they have a goal to make it technology agnostic (which sounds very relevant on the heels of a native mobile app WCAG talk!).

The other way WCAG will change is how outcomes are tested. They might be sorted into quantitative and qualitative, a new way to look at automated vs. manual, and will look to confirm testing methods as well. Ten outcomes have been drafted so far for feedback, which I'll be looking for later to review! But progress may be slow going. Wilco was predicting 2030 before WCAG 3.0 is ready to go, while Glenda was hoping progress on outcomes could be made simultaneously, and be able to launch sooner.

Of course, it looks like they're toying with the idea that WCAG 3.0 might be published in sections or modules, so areas of the document that are ready to go would be available earlier. But there are drawbacks to that approach in terms of being locked into a format, etc. I'm torn, but leaning towards wanting to start using 3.0 as soon as possible!

That's not to say we shouldn't still be keeping an eye on guidelines on a global scale the EU has additional requirements beyond WCAG for accessibility compliance, both for content and authoring tools, and they have a new directive coming out next year as well. Even some of the US laws, such as Section 508, go beyond WCAG.

My takeaway here is to keep our eyes open and look at the bigger picture. WCAG 3.0 may be gentler in some ways, such as having levels of passing instead of every criteria being pass/fail. But it will also have wider applications, into apps, AI, AR/VR environments, and more. This encourage these new and fast-developing industries to be accountable. And who knows, maybe laws will be passed offering protections to people that piggyback off of WCAG's prior history in the digital space and extend into these burgeoning technologies. Crossing my fingers!

Designing Accessible Dashboards

Speakers: Emily Kund, Dataviz & Tableau COE Leader & Consultant

Dashboards can be a way to present summaries of complex and/or high volumes of information. But with the trend towards using graphics and charts to present data, not to mention atypical layouts, it can also be an area ripe with accessibility barriers. Some common issues include relying solely on color, insufficient contrast, lack of screen-reader alternatives to visual data, and more.

Emily suggests a six step design process to help design dashboards with accessibility in mind:

1. Know & learn about your audience
   • How will the audience interact with the dashboard?
   • Get feedback, ask nonintrusive questions
2. Recognize exclusion
   • Not everyone realizes they have a disability
3. Solve for one, extend to many
   • Think curb cuts! Solves issue for wheelchairs, but helpful for strollers, bikes, elderly, blind, etc.
4. Be consistent with your conventions
   • Consistent semantics and visual headings
   • Consistent color usage
   • Guide focus with consistent layouts
5. Provide choice
   • Provide multiple ways to access information and complete tasks
6. Prioritize content
   • Focus on most important information
   • Use big aggregate numbers to draw attention to key metrics

When we design dashboards, we need to be thinking about all types of exclusion, including sight, dexterity, comprehension, etc. Think about the needs of these different group and design to address their needs. Designs that enable access to some groups will enhance the experience for others as well.

Overall, most of the content of this presentation was not new to me, but it was helpful to see it in context of a particular type of design, especially since I've been working on some dashboards lately!