Accessible (Morville Honeycomb): What It Is and Why It Matters

You'll learn to define 'Accessible' as the removal of unnecessary barriers, distinguishing it from usability and compliance. By the end you'll be able to identify where accessibility fits within Peter Morville’s seven-facet model and why it matters for ethical design. This lesson gives you a framework for integrating accessibility early in the design process to prevent exclusion. Learning Objective: By the end of this lesson, learners will be able to define the 'Accessible' facet of the UX Honeycomb and distinguish it from usability and compliance. Transcript The Problem of Exclusion Have you ever built a product that works perfectly for everyone except the people who actually need it most? Exclusion happens when design decisions inadvertently lock out segments of the population. It’s not malicious; it’s just an oversight that treats able-bodied users in ideal conditions as the default. This creates a dangerous gap between functional for some and functional for all. The consequences are severe: lost market opportunities, legal risks, and ethical failures. You’re not just missing revenue; you’re failing to serve the community. Accessibility solves this by ensuring your work is inclusive from the start. That’s your Fix on Design Exclusion! Key Points: Scenario: A design team creates a product that works perfectly for able-bodied users in ideal conditions but fails for users with disabilities. The core problem is exclusion: design decisions inadvertently lock out segments of the population. Consequences include lost market opportunities, legal risks, and ethical failures. Accessibility solves the gap between 'functional for some' and 'functional for all'. Defining Accessible By the end of this section, you’ll be able to define the ‘Accessible’ facet of the UX Honeycomb and distinguish it from usability and compliance. Peter Morville’s UX Honeycomb positions accessibility as one of seven core facets, sitting alongside useful, findable, usable, credible, valuable, and desirable. This framework elevates accessibility from a mere technical constraint to a strategic design goal, ensuring it receives equal weight in your evaluations. We define accessible specifically as the removal of unnecessary barriers to access and use. It’s not just about ticking compliance boxes for standards like WCAG; it’s about embodying the principle that good design is inherently inclusive design. When you treat accessibility as a core heuristic, you ensure products work for people with diverse abilities, contexts, and constraints. This facet solves the critical problem of exclusion by preventing design decisions that inadvertently lock out segments of the population. It bridges the gap between being functional for some and being functional for all, creating an equitable experience that acknowledges varied physical and mental capabilities. Integrating this early during discovery phases prevents costly retrofits later, making it a foundational pillar rather than a final QA task. We’ll explore how this differs from usability in the next section, where we’ll separate access from ease of use. Key Points: Objective: Define 'Accessible' as the removal of unnecessary barriers to access and use. Context: It is one of the seven facets of Peter Morville’s UX Honeycomb (alongside useful, findable, usable, credible, valuable, desirable). Scope: It ensures products are usable by people with diverse abilities, contexts, and constraints. Goal: Expand the potential user base and enhance the experience for everyone through inclusive design. Prior Knowledge: Usability vs. Accessibility You’ve probably seen teams obsess over how fast a user can complete a task, focusing heavily on efficiency, learnability, and satisfaction. That is usability, and it matters, but it assumes the user can already access the product in the first place. Accessibility asks a fundamentally different question: can the user access and use the product at all, regardless of their specific abilities or constraints? Think back to when you tested a sleek interface that worked beautifully for sighted users but failed completely for someone relying on a screen reader. That product was highly usable for the able-bodied, yet entirely inaccessible to others, highlighting the critical distinction between ease of use and actual entry. Experienced practitioners know that removing barriers must come before optimizing for speed, because you cannot improve the experience of those who cannot enter the door. True accessibility goes beyond checking off WCAG standards or meeting ADA compliance; it is an ethos of inclusion and empathy that shapes the entire design. When you prioritize removing barriers first, you ensure the product serves everyone, not just the majority. That distinction between access and ease sets the stage for how we apply these principles in practice. Key Points: Recall: Usability focuses on efficiency, learnability, and satisfaction for those who can already access the product. Contrast: Accessibility focuses on whether a user can access and use the product at all, regardless of ability. Distinction: A product can be highly usable for able-bodied users but completely inaccessible to others. Clarification: Accessibility is not just compliance (WCAG/ADA); it is an ethos of inclusion and empathy. The Accessible Facet in Practice The first step in applying this facet is recognizing that accessibility is defined as the removal of unnecessary barriers to access and use, which means your product must be free from obstacles that prevent anyone from interacting with it. This definition moves beyond simple compliance with standards like WCAG or the Americans with Disabilities Act, because it treats accessibility as a measure of inclusivity rather than just a legal checkbox. When you design for visual, auditory, motor, and cognitive differences, you are actively ensuring that the user experience is equitable for people with diverse abilities and constraints. This approach solves the problem of exclusion by preventing design decisions that inadvertently lock out segments of the population, thereby broadening your market reach and strengthening your ethical standing. Experienced practitioners notice that treating accessibility as a core heuristic within Peter Morville’s UX Honeycomb changes how teams evaluate their work. It serves as a critical evaluation criterion alongside utility, findability, usability, credibility, value, and desirability, which means a product cannot be considered high-quality if it fails this specific facet. If a user cannot access the content or functionality due to a design flaw, the product fails this heuristic, regardless of how usable it is for able-bodied users. This distinction is vital because usability focuses on efficiency and satisfaction for those who can already access the product, whereas accessibility focuses on whether a user can access and use the product at all. By applying this heuristic, designers ensure their work does not inadvertently discriminate against users with disabilities, closing the gap between functional for some and functional for all. Accessibility considerations belong at every phase of a project, from initial research and conceptualization to design, development, and post-launch evaluation, but it is most effective when integrated early during the discovery and definition phases. This is when design decisions have the highest impact and the lowest cost of change, so delaying accessibility until the end of a project often leads to significant rework and technical debt. For instance, during wireframing, designers should consider keyboard navigation and screen reader compatibility before visual details are finalized, which prevents the need for costly retrofits later in the development cycle. In the development phase, accessibility checks ensure that code semantics support assistive technologies, while inclusive user testing with participants who have disabilities provides critical feedback that standard usability testing might miss. The reason early integration is a best practice for efficient and effective design is that it embeds accessibility into the fundamental architecture of the design process rather than treating it as an afterthought. By incorporating accessibility checks into early design reviews and using automated accessibility checkers to identify obvious issues, you create a workflow where accessibility is a shared responsibility rather than a final QA task. Train your team to think about diverse user needs during brainstorming sessions, ensuring that the principle of early integration is recognized as a foundational pillar of quality. This proactive approach fosters a more robust and resilient product that can handle edge cases and diverse user needs without breaking the budget or timeline. That's the structure of the work; the specific decisions practitioners face inside it come next. Key Points: Definition: 'Accessible' means free from unnecessary barriers that prevent access or use. Inclusivity: Designing for visual, auditory, motor, and cognitive differences is a measure of inclusivity. Timing: Accessibility belongs at every phase, but is most effective when integrated early during discovery and definition. Cost of Delay: Delaying accessibility until the end leads to significant rework and technical debt; early integration is a best practice. Next Steps for Integration In your next project, try incorporating accessibility checks into early design reviews instead of waiting for final QA. This shifts accessibility from a compliance hurdle to a shared responsibility that shapes the product from the start. You’ll want to use automated accessibility checkers to catch obvious issues, but you must supplement these with manual testing and inclusive user research. Automated tools miss context, so human judgment remains essential for true inclusivity. Train your team to think about diverse user needs during brainstorming sessions, ensuring that empathy drives every decision. When you embed accessibility into your workflow, you create products that are not only compliant but truly inclusive and user-centered. This approach prevents costly retrofits and fosters a more robust design that serves everyone. That brings the lesson full circle, back to the moment you’ll first put these principles into practice. Key Points: Action: Incorporate accessibility checks into early design reviews, not just final QA. Tools: Use automated checkers but supplement with manual testing and inclusive user research. Mindset: Train teams to think about diverse user needs during brainstorming sessions. Outcome: Embed accessibility into the workflow to create equitable, high-quality user experiences.