T Level OSP - Activity A(i)
Inclusive Design · WCAG Standards · User Research
Identify and analyze different user groups for RZA's digital solution
Apply UX design principles to create user-friendly interfaces
Understand WCAG 2.1 compliance requirements (Levels A, AA, AAA)
Implement accessibility best practices for inclusive design
Conduct user research and create personas
Document user requirements with evidence and justification
• 88% of users won't return after bad UX
• 70% abandon bookings due to complex process
• Negative reviews damage reputation
• Lost revenue from abandoned transactions
• Increased support costs from confused users
• Higher conversion rates (30-40% increase)
• Reduced support inquiries (40-60% decrease)
• Positive word-of-mouth and reviews
• Increased customer loyalty and repeat visits
• Competitive advantage in market
In the UK, 14.6 million people (22%) have some form of disability. Ignoring accessibility means excluding nearly a quarter of potential customers. It's also a legal requirement under the Equality Act 2010 and Public Sector Bodies Accessibility Regulations 2018.
💡 User-centered design isn't just about doing good—it's good business. Accessible websites have 50% higher reach and better SEO performance.
Parents with children (ages 2-12). Looking for educational fun, value for money, convenient facilities
Key needs: Easy booking, child-friendly content, safety info
Adults without children. Seeking relaxing day out, romantic hotel stays, quality experiences
Key needs: Quiet zones, premium options, adult-focused content
Teachers organizing educational visits. Need curriculum-linked content, group discounts, risk assessments
Key needs: Bulk booking, educational resources, safeguarding info
Older adults (65+). May have accessibility needs, prefer quieter times, value convenience and comfort
Key needs: Accessibility features, clear text, phone support
Multi-language support, currency conversion, cultural considerations
Hotel guests for conferences, fast check-in, reliable WiFi, business center
Internal users managing bookings, content, reports - need admin interfaces
Personas are fictional characters that represent key user groups. They help design decisions by putting a human face on data.
Working Mum, Age 35
Background: Teacher, two children (ages 5 and 8), lives in Manchester, visits zoos 2-3 times per year
Goals: Educational fun for kids, good value, easy planning, safe environment
Pain Points: Limited time for planning, budget-conscious, needs child-friendly facilities
Tech Comfort: Confident with mobile apps, prefers to book on phone during commute
Design Priority: Mobile-first, quick booking, clear pricing, family packages
Retiree, Age 68
Background: Retired engineer, lives in Leeds, member of wildlife trust, visits with wife monthly
Goals: Peaceful visits, educational content, comfortable facilities, good photography spots
Pain Points: Small text frustrating, complex navigation confusing, mobility considerations
Tech Comfort: Uses computer for email/news, less confident with smartphones
Design Priority: Large text, simple navigation, phone support, accessibility features
👤 Basic Information
Name, age, occupation, location, photo/illustration
📝 Background
Brief personal context - family situation, lifestyle, relevant interests
🎯 Goals & Motivations
What are they trying to achieve? Why are they visiting RZA?
😤 Pain Points & Frustrations
What problems do they face? What makes them abandon websites?
💻 Technology Comfort Level
How confident are they with technology? Preferred devices?
📱 Typical User Journey
How would they discover, research, book, and visit RZA?
✨ Design Implications
What features/design choices would best serve this persona?
Base personas on research, not assumptions. Interview real users, analyze booking data, review support tickets. Create 3-5 personas maximum - too many dilutes focus. Give them realistic names and details to make them memorable.
Principle: Users should instantly understand what to do next
• Clear headings and labels
• Obvious call-to-action buttons
• Remove unnecessary elements
• Use plain language, avoid jargon
Principle: Similar elements should look and behave the same way
• Consistent navigation across pages
• Standard button styles and positions
• Predictable interaction patterns
• Uniform terminology throughout
Principle: System should inform users about what's happening
• Loading indicators for waits
• Success/error messages
• Form validation in real-time
• Progress indicators for multi-step processes
Principle: Prevent errors when possible, make recovery easy
• Confirmation for destructive actions
• Helpful, specific error messages
• Easy undo/back options
• Input validation and suggestions
Principle: Help users accomplish tasks quickly
• Minimize clicks to complete tasks
• Auto-fill and smart defaults
• Keyboard shortcuts for power users
• Fast page load times (<3 seconds)
Principle: Design for mobile devices first, then scale up
• Touch-friendly buttons (44px minimum)
• Responsive layouts that adapt
• Consider thumb reach zones
• Optimize for one-handed use
Information Architecture (IA) is how you organize and structure content so users can find what they need easily.
🏠 Home
├── 🎫 Visit the Zoo
│ ├── Tickets & Prices
│ ├── Opening Times
│ ├── What's On Today
│ └── Plan Your Visit
├── 🦁 Animals & Exhibits
│ ├── Meet the Animals
│ ├── Feeding Times
│ └── Conservation
├── 🏨 Hotel
│ ├── Rooms & Suites
│ ├── Facilities
│ ├── Book a Room
│ └── Special Offers
└── ℹ️ About Us
├── Our Story
├── Contact Us
└── FAQs
• Logical grouping (related items together)
• 3-click rule (reach any page in 3 clicks)
• Clear category names
• Breadcrumb navigation
• Search functionality
• Unclear or overlapping categories
• Too many menu items (7+ is overwhelming)
• Buried important content
• Confusing navigation labels
• No way to find specific content
Web accessibility means designing websites that everyone can use, including people with disabilities.
Conditions: Blindness, low vision, color blindness
Solutions:
• Screen reader compatibility
• Alt text for images
• High contrast colors
• Scalable text (zoom support)
• Don't rely on color alone
Conditions: Deafness, hard of hearing
Solutions:
• Captions for videos
• Transcripts for audio content
• Visual alerts (not just sound)
• Text-based alternatives
• Sign language videos (optional)
Conditions: Limited dexterity, tremors, paralysis
Solutions:
• Keyboard-only navigation
• Large clickable areas
• No time limits on forms
• Voice control support
• Skip navigation links
Conditions: Dyslexia, ADHD, learning disabilities
Solutions:
• Simple, clear language
• Consistent layouts
• Break content into chunks
• Icons and images as aids
• Avoid flashing content
Web Content Accessibility Guidelines (WCAG) 2.1 is the international standard for web accessibility. It has three conformance levels: A, AA, and AAA.
The most basic level of accessibility. If you don't meet Level A, some users will find it impossible to use your site.
Examples:
• All images have alt text
• All functionality available from keyboard
• Videos have captions
• Page titles describe content
This is the legal requirement in the UK (Public Sector Bodies Accessibility Regulations 2018). Most organizations aim for AA compliance.
Additional requirements beyond A:
• Minimum contrast ratio 4.5:1 (text)
• Text can be resized to 200%
• Headings and labels are descriptive
• Multiple ways to find pages (menu, search)
• Focus indicator clearly visible
The highest level, often difficult to achieve for all content. Not legally required but shows commitment to accessibility.
Additional requirements beyond AA:
• Minimum contrast ratio 7:1 (text)
• Sign language videos provided
• No time limits on reading
• Very simple language (reading level)
Target Level AA compliance - it's the legal requirement, widely achievable, and covers the vast majority of accessibility needs. Some AAA criteria may be unrealistic (e.g., sign language for all content).
WCAG is organized around four core principles, remembered by the acronym POUR:
Information and user interface components must be presentable to users in ways they can perceive.
This means:
• Provide text alternatives for non-text content (alt text for images)
• Provide captions and alternatives for multimedia
• Content can be presented in different ways (e.g., simpler layout)
• Make it easier for users to see and hear content (contrast, audio control)
User interface components and navigation must be operable by all users.
This means:
• Make all functionality available from keyboard
• Give users enough time to read and use content
• Don't use content that causes seizures (flashing)
• Help users navigate and find content (clear navigation, search)
Information and the operation of the user interface must be understandable.
This means:
• Text is readable and understandable (clear language)
• Content appears and operates in predictable ways
• Help users avoid and correct mistakes (form validation, clear errors)
• Consistent navigation and identification
Content must be robust enough to be interpreted by a wide variety of technologies, including assistive technologies.
This means:
• Use valid, clean HTML code
• Ensure compatibility with current and future tools
• Use semantic HTML elements correctly
• Provide name, role, value for UI components
Sufficient color contrast is essential for users with low vision or color blindness. WCAG defines minimum contrast ratios.
Normal Text (under 18pt):
Minimum contrast ratio 4.5:1
Large Text (18pt+ or 14pt+ bold):
Minimum contrast ratio 3:1
UI Components & Graphics:
Minimum contrast ratio 3:1
Normal Text:
Minimum contrast ratio 7:1
Large Text:
Minimum contrast ratio 4.5:1
✓ Good Contrast
Black text on white background
Contrast ratio: 21:1 (Excellent)
✗ Poor Contrast
Light gray text on white background
Contrast ratio: 1.6:1 (Fails WCAG)
Use contrast checkers to test your color choices: WebAIM Contrast Checker, Coolors Contrast Checker, or browser DevTools. Never rely on color alone to convey information - add icons, text labels, or patterns too.
Alt text (alternative text) describes images for users who can't see them - essential for screen reader users and when images fail to load.
Image: Lion resting in grass
Alt text: "Adult male lion resting in long grass under shade of acacia tree"
Why it's good: Descriptive, concise, conveys the meaningful content of the image
Image: Lion resting in grass
Alt text: "image", "photo", "IMG_4729.jpg"
Why it's bad: Not descriptive, doesn't convey any meaningful information
• Be specific and concise (ideally under 125 characters)
• Describe the content and function
• Don't start with "Image of..." or "Picture of..."
• Include relevant context
• For complex images, use long descriptions
• Decorative images: Use empty alt="" (not missing)
• Linked images: Describe destination, not image
• Icons: Describe function (e.g., "Search")
• Charts/graphs: Summarize data in alt text
• Text in images: Include that text in alt
Every animal photo needs descriptive alt text - species, appearance, behavior, setting. For marketing images, convey the experience/emotion. For icons and buttons, describe the action ("Book tickets", "View map").
Many users rely on keyboards (not mice) due to motor disabilities, blindness, or personal preference. All functionality must be keyboard-accessible.
Tab: Move forward through interactive elements
Shift + Tab: Move backward through elements
Enter/Space: Activate buttons and links
Arrow Keys: Navigate within components (menus, tabs)
Escape: Close modals and dropdowns
• All interactive elements reachable by Tab
• Logical tab order (left-to-right, top-to-bottom)
• Visible focus indicators (outline/highlight)
• No keyboard traps (can always navigate away)
• Skip links for long navigation menus
Clear, high-contrast outline that's easy to see
No visible focus indicator - impossible to know where you are
Put your mouse away and try to use your entire website with only the keyboard. Can you navigate everywhere? Book tickets? Fill out forms? If not, you have accessibility issues to fix.
Forms are critical for bookings but often have accessibility problems. Accessible forms benefit everyone.
We'll send confirmation to this email
✓ Clear, descriptive label
✓ Required field marked with *
✓ Helper text explains purpose
✓ Good contrast and sizing
✗ No label (only placeholder)
✗ Not clear if required
✗ No helper text
✗ Screen readers can't identify field
Every input needs a visible <label> element properly associated with the input. Don't rely on placeholders alone.
Mark required fields clearly with * or "required". Use aria-required="true" for screen readers.
Show specific, helpful errors near the field. "Email is required" not "Error". Use icons + text, not color alone.
Use <fieldset> and <legend> to group related fields (e.g., billing address).
Use autocomplete attributes (name, email, tel) so browsers can autofill forms.
Ensure logical tab order through form fields. Don't use tabindex values above 0.
Semantic HTML uses elements that clearly describe their meaning. This helps screen readers, search engines, and future developers understand your content structure.
<header>
<nav>...</nav>
</header>
<main>
<article>
<h1>Title</h1>
<p>Content</p>
</article>
</main>
<footer>...</footer>
Clear meaning, screen readers understand structure
<div class="header">
<div class="nav">...</div>
</div>
<div class="main">
<div class="article">
<div class="title">Title</div>
<div>Content</div>
</div>
</div>
<div class="footer">...</div>
No meaning, everything is just a div
Site or page header with logo, navigation
Navigation menu or links
Primary content (only one per page)
Self-contained content (blog post, news article)
Thematic grouping of content
Sidebar or tangentially related content
Page footer with copyright, links
Clickable button (not <div> styled as button)
Proper heading hierarchy (don't skip levels)
You need to test your website for accessibility issues. Automated tools catch ~30-40% of issues; manual testing finds the rest.
Free browser extension
Visual feedback showing errors, alerts, and accessibility features. Very user-friendly for beginners.
✓ Best for: Quick page-by-page checks
Browser extension (free & paid versions)
Detailed reports with specific WCAG criteria. Integrates with browser DevTools. Highly accurate.
✓ Best for: Detailed technical audits
Built into Chrome DevTools
Automated audits for accessibility, performance, SEO. Gives overall score and actionable recommendations.
✓ Best for: Comprehensive site audits
Command-line tool
Automated testing you can run in development pipeline. Tests against WCAG 2.1 standards automatically.
✓ Best for: Continuous integration / automated testing
Navigate entire site with keyboard only. Check Tab order, focus indicators, all functionality accessible.
Test with NVDA (Windows, free) or VoiceOver (Mac, built-in). Does content make sense when read aloud?
Zoom to 200% in browser. Does layout stay usable? Text readable? No horizontal scrolling?
Run automated tools (WAVE, axe, Lighthouse) during development. Do keyboard testing on every page. Screen reader test critical paths (booking flow, hotel reservation). Get real users with disabilities to test if possible.
Use this checklist to ensure your digital solution meets WCAG 2.1 Level AA standards.
Color contrast meets 4.5:1 minimum (normal text)
Text resizable to 200% without loss of content
All images have appropriate alt text
Don't use color alone to convey information
No content flashes more than 3 times per second
All functionality accessible via keyboard
Visible focus indicators on all interactive elements
Logical tab order (left-right, top-bottom)
No keyboard traps (can always navigate away)
Skip navigation links for long menus
Page titles are descriptive and unique
Headings follow proper hierarchy (H1→H2→H3)
Link text is descriptive (not "click here")
Language of page is defined (lang attribute)
Content is organized logically with semantic HTML
All inputs have associated labels
Required fields are clearly marked
Error messages are clear and specific
Form has logical structure and grouping
Autocomplete attributes used appropriately
User Group / Persona
Which user group does this requirement serve? (e.g., "Families with young children")
Requirement Description
Clear statement of what the user needs (e.g., "Users need to be able to book tickets on mobile devices")
Rationale / Why It Matters
Explain why this is important - user pain point, business benefit, accessibility necessity
Accessibility Considerations
Specific WCAG criteria or accessibility features that apply to this requirement
Success Criteria
How will you know this requirement is met? Measurable outcomes.
Priority
Must-have (MVP), Should-have (Phase 2), or Nice-to-have (Future)
Evidence / Sources
User research, industry data, WCAG guidelines, case studies that support this requirement
User Group: Seniors (65+)
Requirement: Text must be resizable to 200% without loss of functionality
Rationale: Many older visitors have age-related vision decline. Small text creates barriers.
Accessibility: WCAG 2.1 Level AA Success Criterion 1.4.4
Success Criteria: All text scales to 200% in browser without horizontal scrolling or overlapping content
Priority: Must-have (legal requirement)
Create TWO user personas for RZA from different user groups, then document THREE user requirements with accessibility considerations.
Choose from: Families, School Groups, Seniors
Use the persona template from Slide 6. Include: name, age, background, goals, pain points, tech comfort, design implications.
Choose from: Couples, International Visitors, Business Guests
Ensure this is a different type of user with different needs than Persona 1. Contrast helps identify diverse requirements.
Document THREE user requirements using the template from Slide 19. At least ONE requirement must address a specific accessibility need (WCAG compliance).
Example requirements might include:
• Mobile-first booking process (for on-the-go families)
• Large text and high contrast mode (WCAG AA for seniors)
• Multi-language support (international visitors)
• Keyboard-only navigation (motor disabilities)
• Screen reader compatibility for booking flow
Two complete personas with realistic details • Three documented requirements using template • At least one requirement addresses WCAG accessibility • Clear rationale and evidence for each requirement • Proper citation of WCAG criteria where applicable
In the UK, accessibility isn't optional - it's a legal requirement under multiple pieces of legislation.
Makes it unlawful to discriminate against people with disabilities. This includes providing services online.
Key points:
• Websites must be accessible to people with disabilities
• Businesses have duty to make "reasonable adjustments"
• Inaccessible websites can result in legal action
• Applies to all private sector organizations
Requires public sector websites and apps to meet WCAG 2.1 Level AA standards. While RZA is private, these regulations set industry standard.
Requirements:
• WCAG 2.1 Level AA compliance mandatory
• Accessibility statement required on website
• Regular accessibility audits and testing
• Feedback mechanism for accessibility issues
• Discrimination claims under Equality Act
• Potential court cases and settlements
• Enforcement action from regulators
• Legal costs can be substantial
• Reputation damage and negative press
• Lost customers (22% of UK population)
• Reduced search engine rankings
• Exclusion from contracts/partnerships
👥 User-centered design starts with understanding your diverse user groups - their goals, frustrations, and accessibility needs. Create personas to keep users front-of-mind.
♿ Accessibility isn't optional - it's both a legal requirement (Equality Act 2010) and good business (22% of UK population has disabilities). Target WCAG 2.1 Level AA.
🎯 Apply UX principles consistently - clarity, consistency, feedback, error prevention. Mobile-first design is essential given most bookings happen on mobile devices.
🧪 Test accessibility early and often - automated tools catch 30-40% of issues, manual testing (keyboard, screen reader) finds the rest. Don't wait until the end.
📋 Document all requirements with clear rationale and WCAG criteria. Your proposal needs evidence-based justification for every design decision.
Finish creating the two personas and three user requirements from today's activity. Ensure accessibility considerations are thoroughly documented with WCAG citations.
Think about how user needs influence technology choices. Does your "senior" persona need larger touch targets? Does this affect your mobile framework choice?
Session 5 covers Regulations & Compliance - GDPR data protection, PCI DSS payment security, cookies law, and other legal requirements for RZA's digital solution.
You now have: hardware/software research, emerging tech analysis, AND user needs documentation. You're building a comprehensive evidence base for your proposal!
Keep all your research organized by category: (1) Technology options, (2) User requirements, (3) Regulations & compliance. This structure will map directly to your final proposal sections, making writing much easier.
You now understand how to design inclusive, accessible digital experiences that serve all RZA visitors.
🎯 Coming Next: Regulations & Compliance - GDPR, PCI DSS, cookies law, and other legal requirements you must address in your proposal.