Accessibility Features in Software

Happy Global Accessibility Awareness Day everyone! It's a great day to remind people, that, accessibility is the responsibility of the whole team, including designers! A couple of things designers can do: - Use sufficient color contrast (text + UI elements) and don’t rely on color alone to convey meaning. - Ensure readable typography: support text resizing, avoid hard-to-read styles, maintain hierarchy. - Make links and buttons clear and distinguishable (label, size, states). - Design accessible forms: clear labels, error help, no duplicate input, document states. - Support keyboard navigation: tab order, skip links, focus indicators, keyboard interaction. - Structure content with headings and landmarks: use proper H1–Hn, semantic order, regions. - Provide text alternatives for images, icons, audio, and video. - Avoid motion triggers: respect reduced motion settings, allow pause on auto-play. - Design with flexibility: support orientation change, allow text selection, avoid fixed-height elements. - Document accessibly and communicate: annotate designs, collaborate with devs, QA, and content teams. Need to learn more? I got a couple of resources on my blog: - A Designer’s Guide to Documenting Accessibility & User Interactions: https://lnkd.in/eUh8Jvvn - How to check and document design accessibility in your mockups: a conference on how to use Figma plugins and annotation kits to shift accessibility left https://lnkd.in/eu8YuWyF - Accessibility for designer: where do I start? Articles, resources, checklists, tools, plugins, and books to design accessible products https://lnkd.in/ejeC_QpH - Neurodiversity and UX: Essential Resources for Cognitive Accessibility, Guidelines to understand and design for Dyslexia, Dyscalculia, Autism and ADHD https://lnkd.in/efXaRwgF - Color accessibility: tools and resources to help you design inclusive products https://lnkd.in/dRrwFJ5 #Accessibility #ShiftLeft #GAAD

It’s an exciting moment for assistive technology users — JAWS 2026 has officially arrived, and AI is finally becoming a first-class part of the screen-reading experience. I’ve been reading through the new features, and some of them have the potential to meaningfully change day-to-day accessibility for blind users. One of the biggest additions is the new AI Labeler, which can automatically generate labels for unlabeled buttons and controls. Anyone who uses a screen reader knows how often “button… button… button…” shows up. Having an AI-powered way to generate sensible labels on the fly is a big deal. But the feature that really caught my attention is Page Explorer, a new AI-powered page summarization tool. Pressing INSERT+SHIFT+E gives you an instant, high-level overview of a webpage — its structure, main content, important links, and even personalized navigation tips. For complex or cluttered pages, this could save a lot of time. Page Explorer can: • Provide a quick summary of what the page contains • Describe each region and table, along with keystrokes to jump between them • Highlight key links so you don’t have to hunt for them • Answer follow-up questions right inside the Page Explorer window — including summarizing long articles or stripping out ads and unrelated content It’s exciting to see assistive technology making use of AI in ways that actually support efficiency and independence. I’ll also be honest: it’s disappointing that some of these features — like Page Explorer — are only available to higher-tier subscription users. AI shouldn’t become another accessibility divide. But I’m still encouraged to see innovation moving in the right direction. If this is where screen readers are headed, the next few years could be transformative for blind users. #Accessibility #JAWS #AssistiveTech #A11y #Blindness #DigitalInclusion

Power BI Hidden Gem: Accessibility isn’t just a nice-to-have- it’s essential. Everyone should be able to explore and understand your reports, no matter how they interact with the screen. Power BI has a hidden gem in the Table visual settings that helps with this “Refer to row by” under the Accessibility section. And it's a small setting that makes a huge difference! What does it do? It tells screen readers which column to use when reading out each row. This helps users (especially those using assistive tech) understand your data better. Example: In the table present in the image below, if you set “Refer to row by” = Pie Flavor, a screen reader would say: "Apple row: Total Cost $25,635, Total Quantity 2148 Instead of just: "Row 1: Pie Flavor Apple, Total Cost $25,635, Total Quantity 2148" See the difference? It’s way more meaningful and user-friendly! Best Practice: - Pick a column that clearly identifies each row like Customer Name, Product, or Employee ID. Small steps like this go a long way in making your reports inclusive. Let’s build for everyone. #PowerBI #Accessibility #DataForEveryone #InclusiveDesign #PowerBITips #HiddenGem

Accessibility case study: Spotify When we talk about accessibility leaders in the Nordics, most people think of IKEA. But there’s another name worth celebrating: Spotify. ✨ A few highlights: ▷ Accessible by default: their design system, Encore, has an “Encore x Accessibility” track. Many components come with accessibility built-in, and for edge cases, designers get clear, practical guidance. In other words: devs don’t need to reinvent the wheel — accessibility is baked in. ▷ Guidelines that scale: Spotify even shares their Accessibility Guidelines for Developers openly. They’re structured into “quick wins,” “medium-term wins,” and “intensive wins.” It’s a roadmap teams can actually use, not just a wish list. ▷ Research that listens: when they redesigned Your Library, they didn’t just crunch numbers. They combined quant data (how people use the app) with qual feedback (interviews, beta testing) to understand the “why” behind the struggles. That balance is rare, and it shows in the end product. ▷ Nothing about us without us: Spotify partnered with Fable, a community of people with disabilities, to test their products and shape their upcoming Accessibility Plan. Over 100 people with lived experience gave feedback across vision, hearing, mobility, cognition, and speech. That’s accessibility grounded in reality, not theory. 🚀 Why does this stand out compared to others? Lots of companies are still at the stage of “raising awareness” or “appointing an accessibility officer.” Spotify is already embedding accessibility into the tools, workflows, and research methods that shape their everyday product decisions. That’s the shift: from side project to core practice. ⚠️ Gaps & real-world limits: ▷ Scale + legacy product complexity: large platforms must balance many priorities; rolling out accessibility universally across all surfaces (mobile apps, web players, embedded widgets, third-party integrations) takes time. Public work shows progress but also ongoing work. ▷ Content ecosystem challenges: user-generated content (podcasts, artist uploads, social clips) creates variability — captioning and metadata quality depend heavily on creators and tooling. This is an industry-wide gap, not unique to Spotify. 🔎Lessons for companies: ▷ Start with people, not checklists. Invest in user research with people who actually use assistive tech; let the data drive product choices. ▷ Make accessibility social inside the company. Run regular meetups, internal talks, and learning series so the knowledge spreads beyond a single team. ▷ Partner early with specialists & communities. External partners bring lived experience, accelerate learning, and reduce the risk of misguided solutions. ▷ Plan for content & ecosystem complexity. Where creators supply content, invest in creator tools (easy captioning, templates) and moderation/quality flows. ▷ Measure & be transparent. Track accessibility metrics and be honest about scope and remaining work — transparency builds trust.

Picture this: A user fills out your form, hits submit, and sees red borders around a few fields. For a sighted user, that's a visual cue something went wrong. But for someone using a screen reader? Nothing. No announcement. No context. Just silence and confusion. This is one of those accessibility issues that seems small but creates real frustration for users who rely on assistive technology. The problem: Error messages that only show visually (like red borders or red text near the form field) leave screen reader users guessing what went wrong. They know something failed, but they have no idea what or how to fix it. The fix: Programmatically connect your error messages to their form fields using aria-describedby. Here's how it works: When the error appears, the screen reader announces both the field label and the error message together. Now the user knows exactly what needs to be fixed. Why it matters: People can't fix errors they can't perceive. If your form doesn't communicate errors accessibly, you're not just creating a bad user experience - you're actively preventing people from completing tasks like signing up, checking out, or getting help. This is the kind of issue automated scanners often miss. You need manual testing to verify that error states are actually announced correctly to screen reader users. That's where tools like AAArdvark come in - our manual testing workflow helps you catch these gaps and verify that your fixes work the way they should. Accessibility isn't just about passing automated tests. It's about making sure real people can actually use what you build. #Accessibility #WebDevelopment I can't enter HTML in a LinkedIn post, so the image descriptions that follow describe the HTML in prose for those who can't see the image. Short image description: The sample HTML markup programmatically associating both a label and an error message with a form field. Longer image description: HTML code for form error messages showing one email field. At the top, the heading "Form error messages". Below this, a segment of HTML code illustrates how to handle email input errors. An input element has three attributes: type set to email, id set to email and aria-describedby set to email-error. There is a label with a for attribute set to email before the input. There is a span with an id of email-error after the element. The lines showing the aria-describedby attribute on the input and showing the id attribute on the span are highlighted to demonstrate how the error message is programmatically tied to the form field.

Digital accessibility is a legal requirement. So why do so many companies still treat it like an add-on? Remediation is expensive. The smart move? Build accessibility into your process from day one. Start with the basics: 1. Use semantic HTML. That means using the right tags (like <nav>, <button>, <h1>) so assistive tech users can navigate without barriers 2. Write meaningful alt text. “Image of smiling person” doesn’t cut it 3. Enable full keyboard access, especially for forms, menus, and modals (pop-up forms, logins, alerts) 4. Test with disabled users not just automated checkers Are you ignoring these steps? That’s how lawsuits happen. Accessibility lawsuits are increasing in 2025. Inaccessible websites and apps are easy targets for legal action. Customers don’t care if your site just launched. If they can't use it, they will move on. Prioritizing accessibility is much cheaper than facing a lawsuit. Is your team building with accessibility in mind? Or are you waiting until you're served? Let’s talk.