Skip to main content

Blog

Building a More Inclusive Digital World: The Livana Approach

Building a More Inclusive Digital World: The Livana Approach

In today's fast-paced digital landscape, accessibility is no longer an afterthought – it's a necessity. However, for many teams, the path to building inclusive products feels overwhelming, complex, or in conflict with design ambitions. This is where Livana comes in.At Livana, we believe accessibility should enhance user experience, not limit it. We're not just accessibility consultants; we're developers, designers, and innovators with a clear mission: to create inclusive digital and physical spaces without compromising on quality, creativity, or functionality.Accessibility done differentlyFor years, accessibility has been treated as a checkbox, a legal requirement to be met at the end of a project. Unfortunately, this reactive approach often yields inefficient and costly retrofitted solutions. And what's worse, they usually still leave many users' needs unmet.Enter Livana: we flip the script. We embed accessibility into the development workflow from day one, making it a natural, integrated part of how products are built. By aligning accessibility with user experience and design goals, we help teams create digital experiences that are usable, aesthetic, and inclusive for everyone.Designed by people, for people. Backed by technology.Our approach is rooted in a simple yet powerful principle: technology should empower everyone to live, work, and connect with ease and dignity.We partner closely with digital teams; developers, designers, product leads, and assess and enhance their existing accessibility practices. Whether it's web applications, enterprise tools, or mobile platforms, we help to ensure compliance with standards like WCAG and ADA, while pushing beyond the basics to build truly inclusive experiences.As your needs evolve, we offer smart, inclusive tools designed to support people of all abilities. Our solutions draw on expertise in user experience and machine learning to deliver seamless functionality without complexity. Whether you're scaling an existing product, or just starting out, Livana equips your team with the knowledge and tools to do accessibility right.Who we areLivana was founded by three brothers – developers with expertise in accessibility, user experience, and AI – who share a passion for building a more inclusive digital world. With firsthand experience navigating the disconnect between good intentions and real inclusion, they set out to change how teams approach accessibility from the ground up.This passion is at the forefront of every project we take on. We don't just bring technical skill; we bring empathy, curiosity, and a people-forward approach.Why inclusion matters now, more than everOne in five people globally lives with some form of disability. As digital platforms become central to everything from banking to healthcare to remote work, excluding users with disabilities isn't just bad design – it's bad business.Inaccessible platforms create barriers that affect not only users, but also brand reputation, customer loyalty, and legal risk. Inclusive design benefits everyone. It fosters better usability, reaches wider audiences, and often leads to cleaner, more intuitive interfaces overall.Livana is here to help you unlock that potential.We're here to help streamline inclusivity.If you're ready to move beyond minimum compliance and toward digital experiences that truly include everyone, Livana is your partner.Together, we can build tools, platforms, and services that don't just meet standards – they set them.Let's build a future where inclusion is the default, not the exception.

Accessibility
Design Systems: Your Secret Weapon for Accessibility at Scale

Design Systems: Your Secret Weapon for Accessibility at Scale

Accessibility feels overwhelming when every component, every page, every feature needs individual attention. There's a better way.Design systems let you bake accessibility into reusable components once, then use them everywhere. Fix an issue in the button component, and every button across your product gets better. Update focus styles in your system, and they propagate to hundreds of interfaces.This is how organisations scale accessibility without scaling effort. Let's look at how to build it right.Start with accessible foundationsYour design system is only as accessible as its base components. Get the fundamentals right from the beginning, or you'll be fixing the same issues across dozens of implementations.Build your colour palette with contrast in mind. Every text and background combination should meet WCAG standards. Document which combinations work together and why. Make it impossible to accidentally create low contrast pairings.Define focus states once. Make them prominent, consistent, and work across all components. Your developers shouldn't need to think about focus indicators. They should just work.Component-level accessibilityEach component should handle its own accessibility requirements. A button component manages keyboard interaction and ARIA attributes. A modal component implements focus trapping. A form component handles error announcements.Document the accessibility features built into each component. Developers using your system need to know what's handled automatically and what requires their attention. Make it clear, make it visible, make it hard to miss.When you discover an accessibility issue in a component, you fix it once and the fix propagates everywhere that component is used. This is the real power of design systems.Testing at the system levelEvery component in your design system should have accessibility tests. Automated tests catch regressions. Manual tests verify the experience actually works for users.Test keyboard navigation. Test screen reader behaviour. Test with different zoom levels. Test in high contrast mode. Build these tests into your component development workflow, not as an afterthought.Document test results alongside components. When developers pick a component from your system, they should know exactly how it behaves for all users, including those using assistive technologies.Governance and evolutionDesign systems aren't static. They evolve as your product grows and accessibility standards improve. Someone needs to own that evolution.Establish clear governance around accessibility updates. When WCAG releases new guidelines, who evaluates their impact on your system? When a component accessibility issue is discovered, who prioritises the fix?Make accessibility a required checklist item for any new component or significant update. Don't let inaccessible patterns enter your system in the first place.Documentation that actually helpsYour design system documentation should include specific accessibility guidance. Not generic statements about following WCAG, but concrete examples of how to use components accessibly.Show good and bad examples. Explain why certain patterns work and others don't. Include code snippets demonstrating proper implementation. Make it easier to do the right thing than to get it wrong.Document keyboard shortcuts, ARIA usage, and expected screen reader behaviour for complex components. Your developers shouldn't need to reverse engineer how accessibility works.The compound effectDesign systems create a compound effect for accessibility. Every improvement you make gets multiplied across every implementation. The effort you invest upfront pays dividends across your entire product portfolio.Compare this to the alternative: every team implementing their own components, making their own accessibility decisions, fixing their own issues. The duplication is massive. The inconsistency is confusing. The maintenance burden never ends.A well built design system doesn't just make accessibility easier. It makes it sustainable. That's how you build inclusive products at scale without burning out your team.

AccessibilityUI/UX
Keyboard Navigation: The Complete Guide for Developers

Keyboard Navigation: The Complete Guide for Developers

If you can't use your product with a keyboard alone, it's not accessible. Full stop.Keyboard navigation affects more users than you might think. People with motor disabilities, repetitive strain injuries, or those who simply prefer keyboard shortcuts. It's not a niche concern.Yet we consistently see products where critical features are completely unreachable via keyboard. Custom dropdowns that trap focus. Modal dialogs you can't escape from. Buttons that require a mouse click.Let's fix that. Here's everything you need to know about implementing proper keyboard navigation.The tab order mattersUsers navigate through your interface using the Tab key. The order they encounter elements should follow a logical, predictable path. Typically, that means left to right, top to bottom, matching the visual layout.Don't mess with the natural tab order using tabindex values greater than 0. It creates confusion and makes your site harder to navigate. If your tab order feels wrong, the solution is usually to restructure your HTML, not force a different order.Only interactive elements should be in the tab order. That means links, buttons, form inputs, and custom interactive widgets. Regular text and decorative images should be skipped.Focus management in single page appsTraditional websites handle focus automatically when you navigate to a new page. Single page applications don't work that way. Route changes happen without a page refresh, and focus often stays wherever it was.When your app navigates to a new view, move focus to a logical starting point. Usually that's the main heading of the new page. This tells keyboard and screen reader users that the content has changed and where they are now.Skip links deserve a mention here too. They let users jump past repetitive navigation directly to main content. Essential for keyboard users who don't want to tab through your entire header on every page.Building accessible custom widgetsStandard HTML controls work with keyboards out of the box. Native buttons, links, and form inputs all behave correctly without extra work. Problems start when you build custom components.If you're creating a custom dropdown, modal, or any interactive widget, you need to handle keyboard interaction yourself. That means implementing proper ARIA roles, managing focus, and responding to the right keyboard events.Arrow keys should navigate within components like menus and tabs. Escape should close dialogs and cancel operations. Space and Enter should activate buttons. These patterns are established conventions. Follow them.Focus traps and modal dialogsWhen a modal opens, focus should move to it and stay there until it's closed. Users shouldn't be able to tab out and interact with the page behind it. That's what we call a focus trap, and in this case, it's exactly what you want.Implement this by moving focus to the first focusable element in the modal when it opens. When users press Tab at the last focusable element, cycle back to the first. When they press Escape or close the modal, return focus to whatever triggered it.Get this wrong and users can find themselves lost, tabbing through invisible elements or unable to interact with your modal at all.Testing your keyboard navigationAutomated tests catch some keyboard issues, but you need to test manually. Unplug your mouse. Navigate through your entire application using only the keyboard.Can you reach every interactive element? Can you see where focus is at all times? Does the tab order make sense? Can you complete core tasks without touching your mouse?If you get stuck, frustrated, or confused during this test, your users will too. Take notes on pain points and fix them.Making it part of your processKeyboard accessibility isn't something to add at the end. Build it in from the start. Use semantic HTML. Test as you develop. Make keyboard navigation a requirement in code reviews.The patterns we've covered form the foundation. Master these basics and you're well on your way to building truly accessible interfaces. Your keyboard users will notice the difference immediately.

AccessibilityUI/UX
WCAG 2.2 Is Here: What Actually Changed and Why It Matters

WCAG 2.2 Is Here: What Actually Changed and Why It Matters

WCAG 2.2 became the recommended standard in October 2023. If you've been putting off reviewing the changes, now's the time.The good news: most of 2.1 carries over. If your product was already compliant, you're not starting from scratch. The new success criteria target specific pain points that weren't adequately covered before.Let's break down what's new and what you need to do about it.Focus appearance gets stricterThe new Focus Appearance criterion raises the bar for visible focus indicators. They need to be more prominent than before, with specific size and contrast requirements.Your focus indicators must be at least 2 CSS pixels thick or have an area at least as large as a 2 pixel thick perimeter. They need 3:1 contrast against both the focused component and the background.This directly addresses a common issue: focus indicators that are technically present but practically invisible. If users can't see where focus is, keyboard navigation becomes guesswork.Help for people with cognitive disabilitiesSeveral new criteria specifically target cognitive accessibility. These are areas where previous versions of WCAG were notably weak.Consistent Help means if you offer help mechanisms like contact info or chatbots, they appear in the same relative location across pages. Users shouldn't hunt for support options on every page.Redundant Entry prevents forcing users to enter the same information multiple times in a single session. If they've already given you their email address, don't make them type it again three pages later.These seem obvious, yet they address real frustrations users face daily. Implementing them improves the experience for everyone, not just people with disabilities.Authentication without cognitive testsThe Accessible Authentication criterion tackles a major accessibility barrier: cognitive function tests required to log in.At Level AA, you can't require users to solve puzzles, remember passwords, or transcribe text from images unless you provide an alternative. Password managers count as an alternative. So do biometric authentication and magic links.This has major implications for how you implement login flows. Pure memorisation requirements are out. You need cognitive function test free alternatives.Dragging movements need alternativesAny functionality that relies on dragging must have a single pointer alternative. This covers drag and drop interfaces, sliders, sortable lists, anything requiring a dragging motion.The fix usually means adding buttons or other controls that achieve the same result. A sortable list gets up and down buttons. A slider gets increment and decrement controls. A drag and drop file upload gets a traditional file picker.This benefits people with motor disabilities who struggle with precise dragging motions, but also users on devices where dragging is awkward or unreliable.Target size gets more specificTouch targets need to be at least 24 by 24 CSS pixels, with some exceptions for inline links and controls where increasing the size would fundamentally change the functionality.This is smaller than the 44 by 44 pixel requirement at Level AAA, but it's now required at Level AA. The practical impact: most of your interactive elements need to be bigger.Check your icon buttons, close buttons on modals, and any compact UI controls. They probably need more padding or larger hit areas.What this means for your roadmapDon't panic. WCAG 2.1 isn't deprecated. You have time to plan your transition. But legal requirements will eventually catch up, and early adopters gain competitive advantage.Start with an audit against the new criteria. Identify gaps. Prioritise fixes based on user impact and implementation effort. Work them into your regular sprint planning rather than treating them as a separate project.The changes in WCAG 2.2 aren't arbitrary. They address real user needs that weren't adequately covered before. Meeting them makes your product genuinely better, not just more compliant.

Accessibility
Five WCAG Mistakes That Are Costing You Conversions

Five WCAG Mistakes That Are Costing You Conversions

You've probably seen the statistics. One in five people has a disability. Your site might technically pass an automated accessibility test, but are you actually reaching that audience?The truth is, many teams unknowingly create barriers that push potential customers away. These aren't obscure edge cases. They're common mistakes that affect real people trying to use your product right now.Let's walk through five accessibility issues we see repeatedly in audits, and more importantly, how to fix them.Invisible focus indicatorsPicture this: you're navigating a website using only your keyboard. You tab through links and buttons, but you can't tell where you are on the page. This is what happens when focus indicators are removed or barely visible.Many designers remove the default browser focus outline because they find it visually unappealing. Fair enough. But removing it without providing an alternative leaves keyboard users lost.The fix is straightforward. Design a custom focus state that fits your brand. Make it prominent, with at least 3:1 contrast against the background. Your keyboard users will thank you, and your conversion funnel will see the difference.Form errors that screen readers missError messages that only show up visually are a conversion killer. A screen reader user fills out your contact form, hits submit, and hears nothing. They don't know what went wrong or how to fix it.The solution involves proper ARIA labels and live regions. When an error occurs, announce it. Tell users which field has the problem and what they need to do. Better yet, validate as users type so they catch issues before submitting.Good error handling isn't just accessible. It reduces frustration for everyone and increases form completion rates across the board.Colour as the only indicatorRed means error. Green means success. Simple, right? Not if you're among the 8% of men and 0.5% of women with colour vision deficiency.When colour is the only way to convey information, you're excluding millions of users. This shows up everywhere: form validation, data visualisations, status indicators, interactive elements.Add icons, patterns, or text labels alongside colour. Your charts can use both colour and texture. Error messages can include warning icons. Success states can show checkmarks. The information becomes accessible to everyone, regardless of how they perceive colour.Low contrast text that strains everyoneLight grey text on white backgrounds might look sleek, but it creates real problems. Users with low vision struggle to read it. Older users find it difficult. Even people with perfect vision squint when reading it on their phone in bright sunlight.WCAG requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. These aren't arbitrary numbers. They're based on research into what people actually need to read comfortably.Test your colour combinations. There are free tools that calculate contrast ratios instantly. When in doubt, go darker. Legibility always wins over aesthetics.Buttons that don't look like buttonsFlat design led to a trend where everything looks the same. Links that look like buttons. Buttons that look like text. Clickable elements that look decorative.This creates confusion for everyone, but particularly impacts users with cognitive disabilities who rely on familiar patterns to navigate interfaces.Make interactive elements obvious. Use established patterns. Buttons should look pressable. Links should be underlined or clearly differentiated from body text. Maintain consistency throughout your interface.Moving forwardThese five issues represent just the beginning. Real accessibility goes deeper than checklist compliance. It requires understanding how diverse users actually interact with your product.The good news? Most accessibility improvements make your product better for everyone. Clearer focus states help all keyboard users. Better error messages reduce support tickets. Higher contrast improves readability in any lighting condition.Start with these common issues. Test with real users. Build accessibility into your workflow rather than treating it as a final polish step. Your conversion rates, user satisfaction, and bottom line will reflect the effort.

AccessibilityUI/UX