System Generated PDF Accessibility

Hampus Sethfors — Mon, 02 Feb 2026 13:43:40 +0000

How do you make sure documents generated by systems — likely most documents out there today — are accessible to users and comply with accessibility legislation? Let’s geek out on that topic in this article!

What’s the problem?

When learning about accessible documents, almost all guidance focuses on manually created files: how to tag a PDF by hand, how to export a Word document correctly and so on.

But think about the last few documents you received that were personalised for you. Maybe a:

loan commitment from your bank
salary statement
tax information
digital receipt

These documents are almost always generated by systems.

If they come from an organisation covered by accessibility legislation (public sector, banks, e-commerce, etc.), documents must be accessible — regardless of how they’re produced.

In practice, making the document accessible includes ensuring that:

the document is properly tagged
headings, tables, lists and so on are marked up correctly
images have alt-text that describe them
color contrast of text and important graphical elements is sufficient

In short: assistive technologies like screen readers must be able to understand the structure and content.

Example: an inaccessible system generated document

Here’s a classic example of an untagged document. The Accessibility tags pane, which I’ve opened in Adobe Acrobat Pro, shows “No Tags available”:

Without tags, assistive technology like screen readers can’t interpret the content in a meaningful way. Many visually impaired users navigate documents by jumping between headings — something that’s simply impossible when headings aren’t tagged.

Example: an accessible system-generated document

Now here’s an accessible one.

Notice the tag tree contains meaningful structure:

,
and so on for headings
for paragraphs

,	for tables (TH and TD stand for table header and table data) and for lists (List and List Item) This structure is core in making the document accessible and usable for assistive technology users. Figure out how accessible your system generated documents are If you have Adobe Acrobat Pro, this is fairly easy: Open the Accessibility Tags panel Run Adobe’s Accessibility Checker You’ll quickly get a high-level view of what’s working and what’s not. No Acrobat Pro? Reach out and we’ll help you with an initial assessment: [email protected] Three ways to approach the challenge There are three common strategies for improving accessibility in system-generated documents, and which one you chose will likely depend on the current state of your organisation. System upgrade or migration – we can call this “Accessibility by design”. Accessibility add-ons – “Accessibility by remediation” Change to HTML (with PDF as alternative) – “Accessibility by default” Let’s go through them one by one! 1. System upgrade or migration – “Accessibility by design” This is the most robust—but also the most time-consuming—approach to achieving accessibility in system-generated documents. Pros: One-off implementation effort Long-term, maintainable solution Supports all aspects of accessibility, not only technical compliance Cons: Can be time-consuming and complex May require a new installation Does not address historical documents Most system generated documents are produced using a Customer Communication Management (CCM) system. The three major CCM providers are OpenText, Quadient and Smart Communications. All three offer platforms that support accessible PDF generation, including: OpenText Communications Quadient Inspire Flex Quadient Inspire Evolve Smart Communications SmartCOMM Accessibility support in these platforms has matured significantly in recent years. When running on the latest released versions, all three vendors provide strong support for accessible PDF output. Introducing accessibility through a system upgrade requires all document templates to be reviewed and updated with correct semantic structure and tagging. This includes proper handling of headings, tables, images, lists and other artefacts that affect the user experience for users of assistive technologies like screen readers. The organisation must decide on the migration strategy—whether to perform a 1:1 migration or to rationalise templates. We generally recommends starting with template rationalisation workshops to reduce scope and identify synergies. This approach has proven effective in shortening time to market while also future-proofing the CCM setup. A system upgrade supports accessibility by design for all new documents. It also allows organisations to address not only technical compliance, but also qualitative aspects such as clearer language, improved typography, and better contrast—resulting in a more inclusive user experience. In many cases, this is also a suitable opportunity to review the CCM solution as a whole. However, if the accessibility initiative is subject to tight deadlines, this approach may be challenging due to implementation time and, depending on the selected platform, higher costs. 2. Accessibility Add-Ons – “Accessibility by Remediation” With this approach, accessibility features such as tagging and reading order are added after the PDF has been generated. The visual layout and content of the PDF remain unchanged, although content updates can of course be handled separately if required. Pros: Short time to market Source-agnostic (depending on licence model) Can support historical documents Cons: Increased complexity due to dual code bases (CCM + remediation) Primarily addresses technical accessibility Post-composition remediation is a fast and effective way to create value early in an accessibility initiative. Both OpenText and Quadient provide remediation tools: OpenText Accessibility Add-On Quadient Inspire Adapt If the technical prerequisites are met—such as a suitable CCM project setup or compatible source systems—the remediation work can be divided into multiple parallel streams. This makes the approach well suited for projects with tight deadlines. The primary advantages are speed and flexibility. The approach can be largely source-agnostic, and depending on the licensing model, it may also support both new and historical documents. Implementation is typically straightforward. However, remediation introduces two separate code bases: one for document generation and one for PDF remediation. This requires disciplined governance, controlled change management, and a robust testing framework to ensure both layers remain aligned over time. 3. Change to HTML (with PDF as alternative) Delivering content in HTML format often results in significantly higher accessibility. HTML is inherently well suited for assistive technologies, offering strong support for semantic structure, responsiveness, navigation and user-controlled presentation. For many use cases, HTML can therefore serve as the primary delivery format, while PDF is retained as a backup or archival version. Pros Higher level of accessibility can be achieved Low software and tooling costs PDF can be retained as complement or for legal, audit and archival purposes Cons Not suitable as a replacement for PDFs in all legal contexts Requires investigative and modelling work Potential double maintenance (HTML delivery and PDF generation) In digital inboxes, users typically interact with transactional information through an HTML-based view optimised for accessibility and usability, while still having the option to download the corresponding PDF for reference or storage when needed. A HTML-based letter in digital inboxes will be easy to read with assistive technologies, text is usually resizable among other benefits. This approach shifts the focus from making PDFs accessible to ensuring that users receive information in a format that is accessible by default. The PDF is still generated and stored where required—for example, for legal compliance, auditing, or long-term archiving—but it is no longer the primary interface for the end user. When does an HTML-first approach make sense? From a CCM perspective, this approach is particularly relevant when: A full system upgrade is not immediately feasible Accessibility legislation, such as the European Accessibility Act (EAA), must still be met Documents are primarily informational rather than legally binding In these situations, organisations can deliver content in HTML while keeping the PDF as a complementary, secondary or fallback format. This enables progress toward accessibility compliance without delaying longer-term CCM modernisation initiatives. An HTML-first approach also allows improvements to language clarity, structure, typography, and contrast—similar to what is possible in a fully upgraded CCM environment. Some investigative and modelling work may be required to extract or re-structure document logic, particularly for older templates, but this approach often provides a pragmatic and scalable path to accessibility. Where to Start? Begin by identifying which approach—or combination of approaches—best fits your organisation’s document landscape, timelines, and regulatory obligations. Book a meeting with Axess Lab and Enit, and we will help you assess your current situation and define the most effective path forward: [email protected] Optimizing VoiceOver in an iOS E-Commerce App with Conditional Accessibility Diogo Melo — Thu, 08 Jan 2026 10:19:02 +0000 In the previous articles, we built an iOS e-commerce app accessible to VoiceOver, Full Keyboard Access, and Voice Control users. This article explores how we can optimize the VoiceOver experience without breaking Full Keyboard Access or Voice Control in the process. On the Product Detail Page, we saw how fixing VoiceOver issues in SwiftUI almost automatically produced the expected behavior for keyboard and voice interaction. In the Product List Page and Wishlist, SwiftUI and UIKit fixes targeting VoiceOver similarly translated to other assistive technologies. However, the Product List Page exposed an important trade-off. To make the Cart and Wishlist buttons reachable by Full Keyboard Access and Voice Control, we had to change how VoiceOver navigated the list. Instead of a single swipe per product with contextual actions, VoiceOver users now had to swipe through three separate elements per item. As I wrote in the previous article: “Using VoiceOver, navigation now requires more swipes per product because each element is treated separately. From my perspective as a VoiceOver user, although the interface is functionally correct, I prefer the original single-element approach with accessibility actions, which allows quicker navigation and easier access to all available options.” Conditionally Grouping PLP Elements (Actions Included) At this point, we can treat the accessible implementation from the previous article as our baseline, and focus on improving the VoiceOver experience further, but only when VoiceOver is actually running. SwiftUI exposes several accessibility-related environment values that describe the current accessibility context. Many of these relate to visual presentation, such as Increased Contrast or Differentiate Without Color. There’s no equivalent signal for Voice Control or Full Keyboard Access, but there is one for VoiceOver. We can read it directly from the environment: @Environment(\.accessibilityVoiceOverEnabled) private var isVoiceOverEnabled Because this value is a simple Bool, we can use it to conditionally apply VoiceOver-specific enhancements, without changing how the UI behaves for other assistive technologies. With that information available, we can start adapting how elements are grouped depending on whether VoiceOver is running. In the earlier articles, we used .accessibilityElement(children: .ignore) to prevent VoiceOver from navigating individual decorative elements (such as stars). This effectively hides the children from the accessibility tree, allowing us to expose a single parent element and manually provide its accessibility label and traits. SwiftUI provides two additional grouping strategies particularly useful in this context: .combine, which makes VoiceOver merge all child elements into a single accessibility element .contain, which keeps inner elements independent but ensures they are navigated consecutively By reading @Environment(\.accessibilityVoiceOverEnabled), the PLP can adapt its child grouping behavior at runtime. When VoiceOver is running, the product information and its actions are presented as a single combined element. When it is not, the elements remain separate and independently focusable for Full Keyboard Access and Voice Control. HStack { NavigationLink(destination: ProductDetailView(product: product)) { ProductCellNoButtons(product: product) } VStack { // Cart and Wishlist Buttons } } .accessibilityElement(children: isVoiceOverEnabled ? .combine : .contain) Now that the elements are grouped so VoiceOver can navigate each product as a single unit without affecting other assistive technologies, the question becomes: where should the accessibility actions live? In this case, nowhere at all. When using .combine, buttons are not merged into the spoken label; instead, they are automatically exposed as accessibility actions. We just need to provide them with the correct label beforehand and the magic happens. The result is a single, efficient element with contextual actions when VoiceOver is enabled, and three distinct, independently focusable elements when it is not. In this case, optimizing for multiple assistive technologies resulted not only in a more accessible interface overall, but also in the same VoiceOver navigation with less code. Once we accept conditional accessibility as a valid pattern, it opens the door to more ambitious VoiceOver optimizations elsewhere in the app. PDP Options Becoming Adjustable One advantage of native mobile development over the web is the richer toolkit it offers to assistive technology users, especially when it comes to optimizing navigation for screen readers. SwiftUI offers the accessibilityRepresentation modifier, which lets us expose an alternative accessibility-only control for a complex UI. For color and storage selection, a picker could be much faster to navigate for VoiceOver users, presenting a single element to focus on, where its value can be changed by flicking up and down. So, at the end of the VStack containing the color label and options, we can add: .accessibilityRepresentation { Picker("Please choose a color", selection: $selectedColor) { ForEach(colors, id: \.self) { Text($0.description) } } .pickerStyle(.wheel) } This works beautifully once focused, but in iOS 18 it doesn’t always appear in the expected place in the swipe order. To fix the order while preserving the same interaction model, we can manually implement adjustable behavior using accessibilityAdjustableAction. This lets us define what happens when the user performs an increment or decrement gesture. We also set an accessibility label, ignore children, and provide a meaningful value for VoiceOver to report when the user performs the adjust gesture. So, instead of accessibilityRepresentation, the color selection VStack gets these modifiers: .accessibilityElement(children: .ignore) .accessibilityLabel("Available colors") .accessibilityValue(colors[selectedColor].description.capitalized) .accessibilityAdjustableAction { direction in switch (direction) { case .decrement: if selectedColor > 0 { selectedColor -= 1} case .increment: if selectedColor < (colors.count - 1) { selectedColor += 1} default: break } } How does VoiceOver behave now? The UI doesn’t visually change, but VoiceOver now announces the whole group as “Available colors: Blue, adjustable.” Flicking up or down cycles through the color options, and the visual selection updates accordingly. The same logic was implemented in the storage options. When One Fix Breaks Another What happens to Full Keyboard Access once we introduce the adjustable elements used to improve VoiceOver navigation? Full Keyboard Access now treats the color and storage selectors as single focusable elements, just like VoiceOver does. Using the left and right arrow keys adjusts their values. Unlike VoiceOver, however, there’s no spoken feedback when the value changes. Whether this is an optimal experience for keyboard-only users is debatable. This highlights an important point: improving one assistive technology can subtly affect others, sometimes positively, sometimes in ways that need further iteration. And how does Voice Control react to these VoiceOver enhancements? This is where things start to fall apart. By turning the color and storage options into adjustable elements for VoiceOver, Voice Control effectively stops working for those controls. What were previously exposed as individual, actionable buttons can no longer be reliably targeted using voice commands once they become a single adjustable element. Nothing changed visually and the VoiceOver experience improved significantly, but for Voice Control users these controls effectively disappeared. Optimizing VoiceOver Without Collateral Damage Once again, we can rely on @Environment(\.accessibilityVoiceOverEnabled) to apply VoiceOver-specific enhancements, without negatively affecting Full Keyboard Access or, especially, Voice Control users. When VoiceOver is enabled, we use adjustable actions to make navigation faster and more efficient. When it is not, we fall back to the original implementation, exposing individual buttons that work well with Voice Control and Full Keyboard Access. To avoid duplicating layout code, we can extract the original color options into a @ViewBuilder property and reuse it in both cases. The same pattern applies to the storage options. if isVoiceOverEnabled { colorOptions // our @ViewBuilder property .accessibilityElement(children: .ignore) // all previously used VoiceOver-specific adjustable modifiers } else { colorOptions // just the normal View } Does this approach restore Voice Control? In the video, I turn VoiceOver off and use Voice Control to tap individual color and storage options, exactly as before introducing the VoiceOver enhancements. When VoiceOver is turned back on, those same controls are once again exposed as adjustable elements. Each assistive technology now gets the interaction model it expects. What about Full Keyboard Access? Here too, the behavior returns to what keyboard users expect. I can navigate between individual buttons using the arrow keys, and selections only change when I explicitly activate a control, rather than adjusting values automatically with every left or right press. Navigation is now accessible to Full Keyboard Access and Voice Control users, and when VoiceOver is running, the already accessible interface becomes even more efficient for VoiceOver users. Same Pattern Added to the Wishlist The same conditional accessibility pattern used in SwiftUI can also be applied to the Wishlist, which is implemented in UIKit using a UICollectionView. UIKit doesn’t expose accessibility state through an environment like SwiftUI does. Instead, we need to query VoiceOver directly and react to changes imperatively. We can check whether VoiceOver is currently running using UIAccessibility.isVoiceOverRunning. And because UIKit is notification-driven, we should also observe changes to that state: NotificationCenter.default.addObserver( self, selector: #selector(voiceOverStatusDidChange), name: UIAccessibility.voiceOverStatusDidChangeNotification, object: nil) This allows us to switch between two accessibility configurations at runtime: one optimized for VoiceOver, and one that preserves the expected behavior for Full Keyboard Access and Voice Control. When VoiceOver is running, instead of exposing the product information stack and the Cart/Wishlist buttons as separate elements, we make the entire cell accessible as a single element and attach accessibility actions. For VoiceOver users, this results in: One swipe per product Product information read as a single coherent summary A standard double-tap that opens the Product Detail Page Cart and Wishlist actions available via the rotor To do this, we mark the entire cell as an accessibility element and provide a meaningful label, hint, and traits, and then we add the Cart and Wishlist actions: self.isAccessibilityElement = true self.accessibilityLabel = "\(product.name), \(product.price), rated \(product.ratingAsString)" self.accessibilityHint = "Swipe up or down to select a custom action" self.accessibilityTraits = [.button] let addToCartAction = UIAccessibilityCustomAction(name: "Add to Cart") { _ in self.onAddToCartButtonTap?() return true } let wishlistAction = UIAccessibilityCustomAction(name: "Remove from Wishlist") { _ in self.onWishlistButtonTap?() return true } self.accessibilityCustomActions = [addToCartAction, wishlistAction] Finally, we restore the default VoiceOver behavior of opening the Product Detail Page when the user double-taps the element. In UIKit, this is done by overriding accessibilityActivate: override func accessibilityActivate() -> Bool { self.onAccessibilityActivate?() return true } The collection view controller already knows how to open the PDP via didSelectItemAt, so it simply provides the same logic through the onAccessibilityActivate closure. One Wishlist, Various Wishes Fulfilled So how does VoiceOver navigate now, and how does this affect the other assistive technologies? In the video, I start with VoiceOver enabled. The Wishlist behaves as intended: each product is a single element, with custom actions for adding to the cart and removing from the wishlist, and a standard activate action that opens the Product Detail Page. I then turn VoiceOver off and back on again. Because of an intentional bug in the demo, the VoiceOver-optimized configuration is not re-enabled, and the interface remains in its original accessible configuration even with VoiceOver running. In this state, the product information and buttons are exposed as separate elements. This allows Full Keyboard Access users to navigate between the product information, the Cart button, and the Wishlist button using arrow keys or Control–Tab, and to activate each one directly. This mirrors the original behavior that also allows Voice Control users to reliably target and activate individual buttons. If the VoiceOver-style custom actions were always enabled, Full Keyboard Access users would need to press Tab + Z to reach the Cart and Wishlist actions, and Voice Control users would lose access to those controls. By switching accessibility behavior based on whether VoiceOver is running, each assistive technology gets the interaction model it expects, without forcing compromises on the others. Final thoughts Improving the VoiceOver experience is second nature to me as a VoiceOver user, and I usually know early what kind of navigation and interaction I want. In the previous articles, I faced a familiar challenge: optimizing for VoiceOver can sometimes conflict with Full Keyboard Access or Voice Control. That’s why I first made the PDP, PLP, and Wishlist accessible to additional assistive technologies, and only then introduced VoiceOver-specific refinements in this article. With the foundation in place, we could optimize the interface for VoiceOver users. In SwiftUI, this meant reading environment values to detect when VoiceOver was active; in UIKit, we queried UIAccessibility.isVoiceOverRunning and responded to state changes. We also implemented several strategies to streamline navigation and interaction: adjustable controls for faster option selection, .combine to merge elements while exposing buttons as actions, and custom accessibility actions in UIKit. Nothing changed visually, and nothing was removed. Yet each assistive technology now receives an interaction model tailored to how it works. Different tools, different APIs, same result: a more efficient and intuitive VoiceOver experience, fully accessible to Full Keyboard Access and Voice Control users. I’m deeply passionate about both iOS development and accessibility. If your iOS team needs someone who truly cares about accessibility and great user experience, I am open to new assignments. Drop me an email at [email protected]. Making an iOS E-Commerce Product List Accessible to VoiceOver and Beyond Diogo Melo — Thu, 08 Jan 2026 10:17:13 +0000 For a webinar on November 11, I wanted to show how I code and test iOS apps using VoiceOver as a blind developer. To make it realistic, I built a small e-commerce prototype that naturally ended up with the same types of accessibility issues I often encounter in real projects. The premise was simple: build the app “normally,” without deliberately creating accessibility issues, and then fix whatever emerged, all without changing a single pixel of its visual design. This article walks through how I improved the VoiceOver experience on the Product List Page (PLP) and the Wishlist, and how those changes impacted Full Keyboard Access and Voice Control. The article about the Product Detail Page can be read here: Making an iOS E-Commerce Product Detail Page Accessible to VoiceOver and Beyond And the full webinar recording is available here: Webinar Developing and testing iOS Apps using a screen reader with Diogo Melo Product List Page: The Hidden Problems The PLP is built in SwiftUI using a NavigationStack. Each row is a product cell containing: A small image on the left The product’s name, description, price, and a star-based rating in the middle Tapping the product name or information opens the Product Detail Page “Add to Cart” and “Wishlist” buttons on the right, with the heart icon reflecting the wishlist state) In code terms: an HStack containing the image, a VStack with product information (including an HStack for the stars), and a second VStack for the action buttons. In the first implementation, VoiceOver skipped the star rating entirely and didn’t expose the Add-to-Cart or Wishlist actions. Because the entire row sat inside a NavigationLink, VoiceOver treated everything as one big “button,” leaving the product actions completely unreachable. Labels and Actions: Fixing the PLP The star icons were not being read at all. To fix this, I gave them a proper label. Since they’re rendered inside a ForEach, I needed to collapse them into a single accessibility element to avoid repeated labels and present the rating as one meaningful unit. HStack { ForEach(0.. Now VoiceOver announces a clean “Rating: 4.5” instead of ignoring the stars or reading “star, star, star…” To expose the Add to Cart and Wishlist options, I used accessibility actions. Embedding interactive controls inside a NavigationLink is inherently problematic for VoiceOver, so actions were the cleanest approach. At the very end of the product cell, I added: .accessibilityAction(named: existsInWishlist(product) ? "Remove from Wishlist" : "Add to Wishlist") { addOrRemoveFromWishlist(product) } .accessibilityAction(named: "Add to Cart") { addToCart(product) } SwiftUI uses a LIFO order when presenting actions to VoiceOver, so I wrote them in reverse to get the correct order in the rotor. With these changes, VoiceOver now announces the product rating properly and clearly indicates that actions are available. The user can swipe up or down to pick “Add to Cart” or “Add to Wishlist” and the Wishlist action is dynamically updated (e.g., “Remove from Wishlist” after adding). This preserves the visual layout while giving screen-reader users full, efficient control. Wishlist: Too Much Information The wishlist is implemented in UIKit using a UICollectionView. Each cell contains: A vertical stack of product name, price, and rating Tapping any of these informative elements opens the Product Detail Page Buttons to add to cart and remove from wishlist VoiceOver originally treated every subview in the cell as its own element. The star rating came through as an image, and the Wishlist button even switched languages briefly before just saying Wishlist. Navigating a single product required multiple swipes. Imagine doing that across dozens of items. Fixing the Wishlist: Grouping Information To make the experience smoother, the product information needed to be treated as one coherent unit. To group and label the information stack, I set it as an accessibility element and gave it a proper label. I also gave the Wishlist button a clear, explicit label: infoStackView.isAccessibilityElement = true infoStackView.accessibilityLabel = "\(name), \(price), rated \(ratingAsString)" wishlistButton.accessibilityLabel = "Remove from Wishlist" Now VoiceOver focuses the entire information block at once and reads it naturally as a single product summary, just like a sighted user perceives it visually. VoiceOver focuses first on the product information and then navigates to the Cart and Wishlist buttons. It still requires more than one swipe per product, but the flow is much improved. Added to the Wishlist: Keyboard and Voice Control After fixing the Wishlist for VoiceOver, I tested the same implementation with Full Keyboard Access to see whether the changes translated beyond screen-reader use. Using Tab or arrow navigation, Full Keyboard Access can now reach all three meaningful elements in each cell: the grouped product information (which opens the Product Detail Page), the Add to Cart button, and the Remove from Wishlist button. Grouping the product information for VoiceOver also made it reachable by Full Keyboard Access. Before this change (not shown in the initial demo), keyboard navigation could reach the buttons but skipped the product information entirely. I then tested the same Wishlist implementation using Voice Control. Voice Control correctly presents numbers for each actionable element: one for the product information that opens the Product Detail Page, and separate numbers for the Add to Cart and Remove from Wishlist buttons. In this case, improving element grouping for VoiceOver also produced immediate benefits for Voice Control. Even when using “Show Numbers,” Voice Control exposed all elements with their correct, meaningful labels. We have a PLP Problem Testing the improved Product List Page with Full Keyboard Access produced mixed results. On the one hand, keyboard navigation could move between products using arrow keys or Control–Tab. On the other hand, the Add to Cart and Add/Remove from Wishlist buttons were not focusable at all. Full Keyboard Access users can still reach these actions by pressing Tab + Z, which opens the accessibility actions menu and allows the selected action to be activated. However, accessibility actions are not exposed to Voice Control at all. As a result, Voice Control users can only open the product page and cannot access the cart or Wishlist actions at all. Breaking the Original Premise Earlier, I set a constraint for this demo: I would not change a single pixel of the original design. To resolve this issue, I had to slightly relax that rule. On the Product List Page, instead of wrapping the entire product cell in a NavigationLink, I limited the link to the product image and information. The Cart and Wishlist buttons were moved outside of it. HStack { NavigationLink(destination: ProductDetailView(product: product)) { ProductCellNoButtons(product: product) } VStack { // Cart and Wishlist Buttons } } Visually, this moves the chevron indicator so that it appears before the Cart and Wishlist buttons rather than after them. As a blind developer rather than a visual design expert, I can’t say which layout is more common, but the change is subtle and does not alter the overall structure of the list. With this structure, Voice Control users can now activate all product actions directly. Because VoiceOver and Voice Control do not always cooperate (Voice Control overlays are not consistently read by VoiceOver), in this demo I activate actions without VoiceOver feedback and confirm them afterward. I could add a product to the Cart by saying “Tap 2,” add and remove it from the Wishlist using “Tap 3,” and finally open the Product Detail Page with “Tap 1” And the same approach works to Full Keyboard Access users. Navigating with the arrow keys or Control–Tab now focuses on the three actionable elements per product: the product information, the Add to Cart button, and the Wishlist button. Each can be activated directly using the Space bar, without invoking the accessibility actions menu. Using VoiceOver, navigation now requires more swipes per product because each element is treated separately. From my perspective as a VoiceOver user, although the interface is functionally correct, I prefer the original single-element approach with accessibility actions, which allows quicker navigation and easier access to all available options. In a future article, we will explore strategies to optimize for VoiceOver navigation without conflicting with other assistive technologies. Final thoughts Making the Wishlist accessible in UIKit turned out to be relatively straightforward. By grouping elements the way sighted users visually perceive them and providing clear, explicit labels, VoiceOver navigation improved immediately. Those same changes translated automatically to Full Keyboard Access and Voice Control, without requiring any additional adjustments. The Product List Page required more iteration. Wrapping the entire product cell in a NavigationLink is a common SwiftUI pattern and works well visually, but it hides secondary actions from assistive technologies. Exposing those actions through accessibility actions improved the experience for VoiceOver and, to a degree, Full Keyboard Access. However, it left Voice Control users unable to interact with the Cart and Wishlist buttons. By separating navigational content from action buttons, all assistive technologies could access every available action directly. The visual change was minimal, but the accessibility impact was significant. This process highlighted an important distinction between assistive technologies. VoiceOver and Full Keyboard Access can benefit from accessibility actions, assuming users are informed of their existence. Voice Control, however, relies much more heavily on directly exposed, clearly labeled controls. If something is not a button, it is effectively invisible to voice interaction. As someone who relies primarily on VoiceOver, this was a valuable perspective shift. Supporting Voice Control required rethinking interaction patterns I normally take for granted, and ultimately led to a more robust and inclusive Product List Page overall. I’m deeply passionate about both iOS development and accessibility. If your iOS team needs someone who truly cares about accessibility and great user experience, I am open to new assignments. Drop me an email at [email protected]. Making an iOS E-Commerce Product Detail Page Accessible to VoiceOver and Beyond Diogo Melo — Mon, 22 Dec 2025 08:54:10 +0000 For a webinar on November 11, I wanted to show how I code and test iOS apps using VoiceOver as a blind developer. To make it realistic, I built a small e-commerce prototype that naturally ended up with the same types of accessibility issues I often encounter in real projects. The premise was simple: build the app “normally,” without deliberately creating accessibility issues, and then fix whatever emerged, all without changing a single pixel of its visual design. This article walks through how I improved the VoiceOver experience on the Product Detail Page (PDP), and how those changes impacted Full Keyboard Access and Voice Control. The article about the Product List Page and Wishlist can be read here: Making an iOS E-Commerce Product List Accessible to VoiceOver and Beyond And the full webinar recording is available here: Webinar Developing and testing iOS Apps using a screen reader with Diogo Melo. The Accessibility Issues Hiding in Plain Sight The Product Detail Page is implemented in SwiftUI and presents quite a lot of information: A large product image — in this demo it’s an SF Symbol rather than a real image The product name as the page’s headline The product star rating and price The product’s color and storage options, represented as buttons with hard-coded demo values A generic product description A small text label that announces the currently selected color and storage (added purely for early accessibility testing) The Add to Cart and Add to Wishlist buttons, with the latter updating visually depending on wishlist status In code terms, everything lives inside a VStack within a ScrollView, with inner HStacks for the star rating, color options, storage options, and the Cart/Wishlist buttons. Testing the first (accessibility-unfocused) version with VoiceOver revealed several issues. The most noticeable one was the star rating: each individual star was treated as a separate image, and VoiceOver tried to run image recognition on each one (“A yellow star against a black background”). The color buttons produced even stranger results (“night sky”, “outdoor”, “chart”, or nothing at all), and VoiceOver didn’t even identify them as buttons. There were also structural issues: The decorative product image should not be spoken at all The product name and description were not identified as headings The wishlist button didn’t reflect its current state While VoiceOver could read the storage options, it didn’t indicate which one was selected. Hide-and-Seek (Labels and Headings) I started by collapsing the star rating into a single accessibility element, to avoid it being navigated repeatedly, and to give it a single clear label. HStack { ForEach(0..<5, id: \.self) { _ in Image(systemName: "star.fill") } } .accessibilityElement(children: .ignore) .accessibilityLabel(ratingAsString) Next, I hid the decorative product image and marked the product name and the “Description” label as headings: Image(systemName: product.imageName) // proper formatting skipped .accessibilityHidden(true) ... Text(productName) .font(.title) .accessibilityAddTraits(.isHeader) ... Text("Description") .font(.headline) .accessibilityAddTraits(.isHeader) .accessibilityHeading( .h2) Since iOS 18, VoiceOver supports heading levels (1 to 6), just like on the web. I used level 2 here to maintain a logical structure. As far as I can tell as a VoiceOver user, the levels don’t currently change the interaction experience, but I’d love for that to matter one day. For now, I’m just trying to get developers to include any headings at all. Finally, the wishlist state needed to match the visual toggle. If the app uses one dynamic button, we can simply attach a dynamic label: // button whose state depends on whether the product is on the wishlist .accessibilityLabel(existsInWishlist(product) ? "Remove from Wishlist" : "Add to Wishlist") If the UI uses two different buttons, one for each state, each button just needs its own static label: If existsInWishlist(product) { // button to remove product from wishlist .accessibilityLabel("Remove from Wishlist") } else { // button to add product to Wishlist .accessibilityLabel("Add to Wishlist") } Turning Visual Selection Into Accessible Feedback The storage button was already labeled properly, but VoiceOver had no idea which storage option was selected. To fix that, I added the .isSelected trait so the accessibility state reflects the visual state: Button(storage) { selectedStorage = storageOptions.firstIndex(of: storage) ?? 0 } .background(storageOptions[selectedStorage] == storage ? Color.blue : Color.gray) .accessibilityAddTraits(storageOptions[selectedStorage] == storage ? .isSelected : []) For the color options, the logic is similar. We add the .isSelected trait, give each option the .isButton trait (as explained in this previous article), and give each option a meaningful label: Circle() .fill(color) .overlay( Circle() .stroke(colors[selectedColor] == color ? Color.blue : Color.clear) .onTapGesture { selectedColor = colors.firstIndex(of: color) ?? 0 } .accessibilityLabel(color.description.capitalized) .accessibilityAddTraits( colors[selectedColor] == color ? [.isButton, .isSelected] : [.isButton]) Let’s see how all of this changes the experience. Bringing the Page to Life With VoiceOver With these fixes, navigating the product page with VoiceOver starts behaving exactly how a sighted user would expect. The product name is now read as a heading, and the star rating is a single, clear element. Color and storage options are read as buttons, and double-tapping to select one announces the new choice as Selected. The description header can be navigated via the rotor’s heading mode. And the wishlist button correctly reports whether it will add or remove the item. It also reports the “Remove from Wishlist” button as Selected using the .isSelected trait. This is more of a personal preference, as some apps do this and I intuitively expect it as a VoiceOver user. In short, the PDP now communicates structure, meaning, and state, not just raw UI fragments. A Little Less Full Keyboard Access Testing the accessible version of the PDP with Full Keyboard Access (FKA) mostly works as expected. Using Tab navigation, I can reach: The back button All the color and storage options Add to Cart Add to Wishlist / Remove from Wishlist However, one unexpected element appears in the tab order: the star rating. Even though it isn’t interactive, Full Keyboard Access treats it as focusable. This happens because collapsing the stars into a single accessibility element implicitly marks it as something the user might want to interact with. To fix this, we can explicitly mark the element as static text by adding the .isStaticText trait: HStack { // ForEach with star rating } .accessibilityElement(children: .ignore) .accessibilityAddTraits(.isStaticText) .accessibilityLabel(ratingAsString) This tells Full Keyboard Access exactly what this element is: decorative information presented as text. Once marked correctly, it’s skipped during keyboard navigation. Voice Control Comes Along for Free Testing the PDP with Voice Control shows that the same accessibility improvements translate cleanly to voice-based interaction, with no additional effort. Like with Full Keyboard Access, all interactive elements are exposed correctly: All color and storage options Add to Cart Add to Wishlist / Remove from Wishlist Tab bar navigation Voice Control identifies these elements as tappable and allows them to be activated using spoken commands. Because Voice Control relies heavily on accessibility labels, the earlier work of adding meaningful labels, button traits, and selected states pays off here without any Voice Control–specific code. Final thoughts Making the Product Detail Page accessible to VoiceOver turned out not to be a complex or disruptive task. Most of the work involved hiding or collapsing purely decorative elements, providing meaningful labels, and using the correct accessibility traits to reflect structure and state. None of these changes required visual redesigns or custom accessibility workarounds, just more intentional use of the APIs SwiftUI already provides. Even though this article focused primarily on VoiceOver, testing along the way showed an important pattern: improvements made with VoiceOver in mind often benefit other assistive technologies as well. Full Keyboard Access became more predictable once roles were clearly defined, and Voice Control was able to expose and activate all interactive elements without any technology-specific code. In that sense, Voice Control works as a powerful validation tool. If an element can’t be easily activated by voice, it’s often a sign that its accessibility role, labeling, or structure needs improvement. In the webinar, I also presented a more VoiceOver-optimized version of this Product Detail Page, exploring what happens when we go beyond baseline accessibility and start enhancing navigation and interaction patterns. That version, and how to make it work without breaking Full Keyboard Access or Voice Control, will be covered in the next article. I’m deeply passionate about both iOS development and accessibility. If your iOS team needs someone who truly cares about accessibility and great user experience, I am open to new assignments. Drop me an email at [email protected]. Accessibility of Fuel and EV Charging Stations: Wheelchair user insights and the European Accessibility Act Nathalie Pentler — Fri, 12 Dec 2025 16:38:03 +0000 Wheelchair users experience accessibility challenges at fuel and charging stations that most people never notice. The issue isn’t our disabilities, but the way fuel and charging stations are designed. This is finally starting to change. The European Accessibility Act (EAA) now requires self-service terminals to be accessible, which is a big deal for anyone who has ever struggled with a poorly placed payment screen. Many people don’t realize that a large number of wheelchair users drive their own cars. As a result, it is often challenging or even impossible to refuel or charge cars independently. For an example of how some wheelchair users drive or get in their cars, have a look at this video by Kathryn Granger. What Wheelchair Users Experience at Fuel or Charging Stations I use a wheelchair myself, but I don’t have a driving license yet. Since the European Accessibility Act (EAA) is now law all across the EU, I wanted to ask drivers with disabilities how it actually works for them to charge or refuel their cars here in Sweden. Spoiler alert: It is not going very well. 1. Needing assistance because of the inaccessibility Many wheelchair users can’t refuel or charge independently because of the inaccessible stations. Having to depend on others is frustrating and can be very time-consuming. “I can’t do it myself, I always need to bring someone that can help me.” “I need to call the store and ask the staff to come out and help me”. “Last time, along the E4 highway, it took over 40 minutes before anyone had time to help me.” “My partner refuels the car for me. Otherwise I would probably call the station and ask someone to help me solve the problem.” 2. Steps and Curbs Are Major Obstacles A single step or curb can make a station inaccessible. Poorly placed payment terminals that are high up or tucked away on narrow platforms are difficult or impossible to use independently. “Many times there’s a step up to the card machine or the fuel pump.” “The payment terminal is placed high up because of the curb and because it’s positioned further in on the platform. Many of them can’t be reached at all when they’re placed far back on a high, narrow ledge”. 3. Equipment is Out of Reach Even without steps, equipment is often mounted too high. Buttons to select fuel type, card readers, and screens are designed for standing users. “Many have a small ledge/plateau on which the machines stand, making them difficult to reach. On others, the number pad for the card terminal is positioned far too high.” “The difficult part is that some diesel pumps have buttons to choose between car or truck fueling placed too high. I’ve learned that if you wait, it will start in car mode anyway, but it was really frustrating before I figured that out, and I had to ask passersby to press the button.” 4. Unstaffed Stations Are a Problem When no staff are available, wheelchair users have to rely on other people or plan their drives based on where the staffed stations are. This creates both practical and safety concerns. “I try to avoid unstaffed stations, but sometimes there’s no choice. I didn’t choose an electric car because I feared it would be even harder.” “I try to plan to refuel on one of the days I have an assistant, but sometimes I forget, so then I have to try to find a staffed station.” “Unstaffed stations are often difficult, with a step up to the card reader. If it had at least been turned around, it would have worked better and been accessible from the side.” 5. Big Differences Between Stations Not all stations are equal. Some chains have pumps and card readers at lower heights. Others still require climbing onto concrete platforms. “I almost always refuel at the same chain, and I never experience any issues there. The payment terminal is angled outward and even though it’s mounted a bit higher, it’s still reachable from a wheelchair.” “The station where I live has a lower pump that I can use from my wheelchair.” “Certain pumps work well because I can reach to insert my card and enter my PIN while staying in my wheelchair. The least accessible ones are those where you have to get up onto a concrete platform just to use the card reader.” 6. Apps Make it Easier More and more companies are making it possible to use apps to control refueling or charging, which can solve many of these problems. But it’s important to remember that while digital solutions make it much easier for many, the apps themselves need to be accessible as well. “Many providers offer the option to control the refueling process through a mobile app instead of using the physical terminal on site.” “I use a fuel provider that also has an app where I can select the pump and start refueling, so I don’t have to deal with the barrier around the pump that makes it hard to reach the card terminal.” Summary of wheelchair users’ experiences at fuel and charging stations Many need assistance and are forced to plan their trips accordingly. Steps and curbs are both common and major obstacles. Reaching pumps, chargers, and payment equipment is often difficult. Unstaffed stations are even more challenging since no help is available. The level of accessibility varies between stations. Apps can simplify refueling and charging. Fuel and Charging Stations under the European Accessibility Act The European Accessibility Act has been in place since June 28 2025. This law covers products such as payment terminals and self-service terminals at fuel and charging stations and in other settings. The EAA states that controls and interfaces should be within reach and not require great strength or fine motor skills. Detailed requirements are specified in the European standard EN 301 549. According to the current version of the EN standard, controls or “operable parts” should be placed roughly between 38 cm and 122 cm from the ground (the exact measurements are under revision and will be specified in the upcoming version of EN 301 549). Other requirements include possibilities to extend the time given to perform a task, which is important for wheelchair users who might need extra time to navigate the fuel or charging stations. For a deeper dive into the legal requirements and detailed examples from the EAA, you can read our article European Accessibility Act (EAA) – Kiosks, touch screens and physical devices. It is also important to note that inaccessible fuel or charging stations may fall under national discrimination laws and lead to legal consequences. This has already happened in Sweden, where a fuel station company was found guilty of discrimination against a wheelchair user. Read more in an article by DHR (in Swedish). A new specification for accessible charging stations has been published A new Swedish accessibility specification for charging stations has been published by SIS in collaboration with disability organizations like DHR and BraunAbility. The specification is called Tillgängliga laddningsplatser för elfordon – Krav och rekommendationer (Accessible recharging stations for electric road vehicles — Requirements and recommendations). The goal of the technical specification is to create clear requirements for how charging sites should be designed in order to be usable for people with different levels of mobility, length or hand strength. The specification covers everything from site layout to digital interfaces and other interactive systems that are required for charging an electric vehicle. It is intended to guide both new construction and upgrades of existing stations. If widely adopted, this work can remove many of the barriers wheelchair users face today and make it possible for us to charge our cars more independently. Want a helping hand? We can help you audit and user test payment terminals, self-service terminals, and other physical machines. You will receive a clear report that shows whether your solution meets the requirements of the European Accessibility Act and EN 301 549. Even when a product is not formally covered by the EAA, we can still support you in making it easier to use for people with disabilities. If you would like help from accessibility specialists like me on your specific product or service, you can find our contact details in the footer below. The independence that comes with driving your own car should not be taken away from people with disabilities, especially when other forms of transport can be even less accessible. Improving accessibility at fuel and charging stations is essential and benefits everyone, with or without disabilities. Check out our accessibility consulting services or just drop us a message at [email protected] – we’re happy to help! ADA’s New 2026 Deadline: What Tech Vendors Need To Know Joel Holmberg — Wed, 10 Dec 2025 15:36:58 +0000 If your company builds websites, apps, or digital services for cities, counties, school districts, or any other state or local government body in the US—there’s a major accessibility deadline coming your way. In April 2026, new ADA requirements come into force that make accessible digital services mandatory for state and local governments in the US. And since most of these governments depend heavily on external vendors for their digital solutions… it may also affect you. This article walks you through: What the ADA update says Who must comply The April 2026 deadline Key exceptions What vendors need to do now How Axess Lab can help with accessibility audits and VPATs Let’s dive in. What’s happening in April 2026? In 2024, the U.S. Department of Justice (DOJ) finalized a major update to the ADA—specifically focusing on State and local government websites, mobile apps, and digital services. The rule requires all digital content provided by these public entities to meet WCAG 2.1 Level AA, the globally recognized accessibility standard. The enforcement deadline is April 24, 2026 for larger public entities, with smaller ones getting a bit more time. In short: accessibility is no longer a nice-to-have. It’s a legal requirement. Who does this affect? The rule applies to State and local governments in the US, but it has massive consequences for: 1. Tech vendors selling to US governments If you provide: Websites Mobile apps SaaS platforms Ticketing systems Payment portals Parking apps Transit apps Public service kiosks Scheduling or permit systems …your software must be compliant. 2. Integrators and service providers Companies that integrate digital systems for cities will also need to demonstrate conformance. 3. Agencies using off‑the‑shelf software Even if a government entity buys a product “as is,” they are still legally responsible for its accessibility. Which means they’ll put pressure on you—the vendor. When is the deadline? The compliance deadlines depend on the size of the public entity: Large public entities (50,000+ population): April 24, 2026 Smaller public entities: April 26, 2027 But here’s the key part for vendors: You will start getting accessibility requirements from government clients long before 2026. Cities and counties are already preparing their budgets, procurement language, and vendor requirements. If your product isn’t accessible or you can’t provide a VPAT, you risk being excluded from bids. Are there any exceptions? Yes, but they’re limited; Archived content Old content not needed for active use may be exempt. Third‑party content Information posted by third parties on government platforms may not always be covered. Certain live content Real‑time streams without the technical ability to caption may have temporary exceptions. Legacy documents PDFs and documents published before the compliance date may have limited exceptions. But the rule is clear: websites, apps, and core digital services must meet WCAG 2.1 AA. Most exceptions do not apply to vendor‑provided apps or SaaS platforms. What should tech vendors do now? Government agencies will increasingly ask for formal proof of accessibility. Here’s how to prepare: 1. Get an accessibility audit A WCAG audit by independent specialists gives you: A full list of accessibility issues Clear remediation instructions Prioritized fixes Evidence for procurement reviews Accessibility Audits 2. Publish a VPAT A VPAT (Voluntary Product Accessibility Template) is often required during procurement. It tells government buyers exactly how your product meets accessibility standards. VPAT Services 3. Start remediation early Fixing accessibility takes time—especially if your product has grown organically over many years. Starting early avoids rushed fixes and failed procurement bids. 4. Train your teams Developers, designers, product managers, and QA teams should understand accessibility basics. Government clients increasingly expect vendors to prove accessibility maturity. In order to stay compliant over time you need your teams to master at least the basics of accessibility without relying on external specialists. Accessibility training, workshops and talks Why this matters: more than compliance Beyond legal risk, accessible products perform better: Better UX for everyone Improved SEO Improved AI discoverability Better performance on mobile Expanded market reach Lower future remediation costs And of course—you help ensure equal access to public services. How Axess Lab can help We help Saas companies and tech vendors meet accessibility requirements by offering: Professional accessibility audits Identify issues early and get a clear roadmap for compliance. VPAT creation & publication We create accurate and industry‑standard VPATs that help you win government contracts. Developer & designer training Empower your teams to build accessible features from the start. We offer live teacher-led training remote or on-site as well as on-demand online courses. Ongoing accessibility support We partner with companies long‑term to maintain compliance as products evolve. From a shared Slack channel for quick questions to a full time Accessibility Lead from Axess Lab – whatever works best for you! Book a chat with our team Final thoughts The April 2026 ADA deadline is coming fast—and state and local governments are already preparing. If you provide digital solutions to the public sector, accessibility is now a mandatory part of your product. The good news? You don’t have to navigate it alone. Axess Lab is here to help you meet the requirements, win bids, and build products that everyone can use. Check out our accessibility consulting services or just drop us a message at [email protected] – we’re happy to help! VPAT – Volountary Product Accessibility Template Joel Holmberg — Wed, 10 Dec 2025 11:00:23 +0000 Are you looking to comply with the ADA, perhaps in order to win government contracts in the US, or just to show the world you care about accessibility and inclusion? Then you need something called a “VPAT”. Here is what that means! What is a VPAT? The Voluntary Product Accessibility Template is a document outlining how well your product complies with accessibility regulations. It contains information about any existing accessibility issues and how well you conform with each requirement in standards like the WCAG. This document allows buyers to assess how well your product will work for users with disabilities, so that they can decide if they want to, or even are allowed to purchase and use your product in their daily operations. You can create this document yourself. However it usually requires an accessibility audit be done to find any accessibility issues first. That can be difficult and time consuming for a non specialist to do. Why use a VPAT? The Americans with Disabilities Act (ADA) was recently clarified to enforce state and local governments in the US provide accessible websites and apps to their citizens. This includes such software provided via 3rd party vendors. You can read more about what this means for vendors but basically: IF you sell to state or local governments in the US And IF your product or service includes a website or app THEN the website or app has to comply with accessibility guidelines (WCAG 2.1 AA) for governments to be allowed to buy it The VPAT document is the formal way to show them how your product conforms to such guidelines How do I get one? In order to put together a VPAT you need to know all accessibility issues your product or service has. Preferably you’ll want to fix any major issues before publishing a VPAT which contains the remaining issues and workarounds for them. Contract a specialist to audit your website or app and compile a list of issues Work on solving the major issues (Axess Lab reports are prioritized and contain suggested solutions in design and code) Check for any remaining issues (for reference, acceptance tests are 30% of the original audit price at Axess Lab) Create a VPAT using the report of remaining issues, or have someone like Axess Lab do it for you Publish it on your website or link to it wherever you sell or describe your product, and have it ready to upload as a document in tenders or procurements. What does it cost? The big cost is finding the state of accessibility in your product. A VPAT document can be added for ~$1000 (Axess Lab price example) once there is a report to base it on. You can also create it yourself using templates found online, if you know what you’re doing. Otherwise, feel free to book a free meeting with us and we can guide you through the whole thing: Book a chat with our team How Button Traits can make a chaotic iOS app accessible Diogo Melo — Fri, 05 Dec 2025 12:18:37 +0000 A while ago, I was using an iPad app where the main call-to-action wasn’t marked as a button. As a blind VoiceOver user, I simply couldn’t find the one thing the entire screen was built around. I tried tabbing with Full Keyboard Access; nothing. I tried Voice Control; still nothing to target, nothing to say. As an iOS developer, I remember thinking: “Surely this is easy to fix. Why does this problem still happen?” So, naturally, I decided to intentionally build the most impossible-to-fix iOS app I could imagine, just to prove a point: if this can be fixed, then the same method can fix anything. The Most Chaotic App I Could Build (On Purpose) I built a tiny “game” that’s basically a psychological experiment disguised as a SwiftUI app: a 3×3 grid of playful tiles numbered 1 through 9. Behind them are four zeros, three small prizes, one €1M tile, and one haptic “shock.” Players can take their single chance by tapping a tile, use “Hide Zeros” to remove the duds (at the cost of halving all prizes), or simply forfeit. To push accessibility to its absolute limits, I deliberately filled the UI with decorative shapes stacked everywhere, purely to confuse assistive technology. Watching Three Accessibility Systems Fall Apart VoiceOver completely falls apart in this UI. It treats every tile as several unrelated elements instead of a single action. It first navigates a row of decorative images, then the tile numbers, then another row of decoration. Each tile ends up being five separate, non-adjacent items, none of them announced as buttons. The “Rules”, “Forfeit”, and “Hide Zeros” elements are split into a pair of items each, and double-tapping the latter doesn’t work. Navigating becomes a maze of noise. To Full Keyboard Access, the interface is impossible to navigate. Because I rely on VoiceOver, it is running in all demos. Pressing Tab cycles only between the Screen Recording button and a single “disabled” region that represents the entire app. None of the app’s elements can receive focus. To the system, there is literally nothing interactive on screen. Same issue with Voice Control: nothing is recognized as a button. Voice Control offers zero commands in the app, not a single button name appears. Even the tile numbers (“one”, “two”, “three”, etc.) don’t work as voice commands: the UI has no semantic structure, so the system can’t guess what’s interactive. For all three accessibility systems, this app is a complete void. Small Fixes With Great Impact on Usability At this point, you’d think the solution requires custom actions, accessibility overlays, rewritten components, or rebuilding the app from scratch. But no. All I needed were two tiny changes: Group each tile’s internal visual elements so VoiceOver perceives the tile as a single thing, not many fragments. Add the `.accessibilityAddTraits(.isButton)` modifier so iOS knows these elements are actions. Here’s the simplest version: // code block 1 ZStack { // unchanged chaotic visual layers } .accessibilityElement(children: .combine) .accessibilityAddTraits(.isButton) Sometimes combining the children wasn’t ideal, so I ignored them and added a custom label. Also, I needed a different approach when the user would hide zeros. So a second pattern was necessary: // code example 2 ZStack { // unchanged chaotic visual layers } .accessibilityElement(children: .ignore) .accessibilityLabel(hideZeros ? "0" : tileNumber) .accessibilityAddTraits(hideZeros ? .isStaticText : .isButton) .disabled(hideZeros) That’s it. No magic, no custom routing, just proper semantics. Three Accessibility Systems Fixed at Once Using VoiceOver, all the decorative noise disappears. Each tile is now a single clearly announced element like “1, button,” “2, button,” and so on, plus the three action buttons. VoiceOver even correctly reports dimmed zero tiles after using the “Hide Zeros” option. Navigation becomes linear, predictable, and effortless. Using Full Keyboard Access, all elements can be navigated through. With semantics in place, the system can finally tab to each tile and to the “Hide Zeros” button. Dimmed elements correctly prevent activation. Nothing else changed, only the traits. And with Voice Control, everything works now. With proper names and traits, Voice Control immediately identifies the tiles and UI actions. Users can activate actions by speaking the tile numbers or the action buttons, and it just works! No special routing, no custom speech commands, no keyboard-shortcut handling… Just proper semantics. Final Thoughts: Accessibility Isn’t About Extra Work — It’s About Clarity My absurd little 3×3 experiment taught me something important: `.isButton` isn’t just a convenience trait — it’s a foundational piece of accessibility across the entire iOS ecosystem. VoiceOver, Full Keyboard Access, Voice Control, Switch Control, and other assistive technologies all depend on these semantics. Grouping elements and adding a single trait was all it took to turn an impossibly inaccessible interface into a fully navigable one. Accessibility doesn’t mean adding complexity, it means giving the system the information it needs to help every user regardless of how they interact with your app. If a UI as chaotic as this can be fixed with two modifiers, imagine how much impact you can have on a real-world interface. I’m deeply passionate about both iOS development and accessibility. If your iOS team needs someone who truly cares about accessibility and great user experience, I am open to new assignments. Drop me an email at [email protected]. EAA deadlines, why you probably can’t wait another 5 years! Joel Holmberg — Fri, 28 Nov 2025 15:52:37 +0000 The European Accessibility Act (EAA) – formally Directive (EU) 2019/882 – became EU law 2019 and forces private companies to provide digitally accessible products and services to EU consumers. But when? Deadlines for companies can be hard to grasp because … it depends! Don’t worry though, this guide will clear it up! Short version Software like websites and apps need to be accessible by June 28, 2025. Existing physical products sold or installed before June 28 2025 can remain in use for 5-20 years. The basics We go through the basics of EAA in our article European Accessibility Act (EAA) – What you need to know. For self-service terminals, we explain more here: European Accessibility Act (EAA) – Kiosks, touch screens and physical devices. But in a nutshell: This EU directive was enacted 2019, and a grace period (let’s call it GP1) allowed EU countries until 2022 to enact this directive into local law. The law was to give another grace period (GP2) for companies to comply until June 28, 2025. This gave companies three years to make their products and services accessible. Since June 28, 2025, services like websites and apps, and digital products, like e-reader and TVs, must be accessible. Some extended grace periods exist: Self-service terminals like ticket machines that are in place and which cannot reasonably be made accessible are allowed to stay inaccessible until replaced, but at most 20 years (GP3). Inaccessible physical products used to provide services can be used for up to 5 years. For example old ATMs or POS systems installed before June 28 2025 (GP4). Existing contracts signed with consumers before june 2025 can stay in place unchanged for up to 5 years (GP5). Especially grace periods GP3-GP5 cause a lot of confusion, so let’s clear it up! And to be clear, we are not lawyers so this is not legal advice, but we do know digital accessibility! The confusion The grace periods that exist after 2025 do indeed offer deadlines farther into the future. But it’s important to understand why they exist, and when it is allowed to use them. Websites and apps are not products! Extended grace periods are available for “products used to provide services”. However, this only means physical products! Websites and apps are not products! They are considered part of the service being provided. Definition of “product” from Article 3 (2) in the EAA ‘product’ means a substance, preparation, or good produced through a manufacturing process, other than food, feed, living plants and animals, products of human origin and products of plants and animals relating directly to their future reproduction; Products in place before June 28 2025 Products that cannot reasonably be made accessible after they have been installed are allowed to stay inaccessible until they are replaced or reach their end-of-life. This is intended for things like payment terminals or physical kiosks like ticket-machines that don’t go through regular updates, and where a re-design would require replacing the whole machine. Doing so would mean “old” but still functioning machines would be destroyed, which would be economically and ecologically unwise. A grace period exists for 5 years for such products, or 20 years for self-service terminals. No such grace periods exist for websites and apps used to provide services. Grace period wording in the EAA “In order to allow service providers sufficient time to adapt to the requirements of this Directive, it is necessary to provide for a transitional period of five years after the date of application of this Directive, during which products used for the provision of a service which were placed on the market before that date do not need to comply with the accessibility requirements of this Directive unless they are replaced by the service providers during the transitional period.” and “Given the cost and long life-cycle of self-service terminals, it is appropriate to provide that, when such terminals are used in the provision of services, they may continue to be used until the end of their economic life, as long as they are not replaced during that period, but not for longer than 20 years.” Existing contracts If an EU consumer signed a contract before June 28, 2025 to use a service covered by the EAA, the company is allowed to keep that contract in place unchanged for up to 5 years even if the contract would break the EAA after June 28 2025. This includes if the contracts format and formalities are not fulfilling EAA requirements, as well as if the service that the contract is for is inaccessble. This clause was likely added to the EAA because the EU wanted to avoid forcing companies to immediately rewrite millions of existing consumer contracts on 28 June 2025. Many accessibility obligations affect: terms & conditions onboarding and account information invoices, statements, contractual notices customer support channels If this exception didn’t exist, telecoms, banks, transport operators, etc. would need to terminate or renegotiate all current consumer contracts — which would be disruptive and legally risky. Confusion “Contracts” only means contracts between the service provider and consumer! Contracts between the service provider and its suppliers and subcontractors are irrelevant! So for example if you are a bank and allow your users in the EU to trade stocks using a 3rd party software integrated in your banking app – it doesn’t matter that you signed the contract with the trading platform before June 2025 – the platform still has to be accessible by June 28 2025! Otherwise you are not allowed to accept new customers! If you have a webshop where a 3rd party chatbot handles customer questions – and you signed the deal for the chatbot in 2024 – that doesn’t matter. The chatbot still must be accessible by June 28, 2025! Here is a statement from the Swedish auditing agency PTS about their interpretation of this clause: “Our interpretation is that transitional provision 4 refers to agreements between the service provider and the consumer, which I also understand to be your interpretation. This means that other agreements, for example an agreement between a service provider and a subcontractor, are not covered by the transitional provision according to our assessment.” If you have an old service that you no longer offer to new customers after June 28 2025 – one that you make no updates for – then you are allowed to keep providing that inaccessible service for those customers who signed up before June 28 2025 until the contract ends, but at most 5 years. But you are not allowed to offer this service to new customers! So this exception is likely not for you! Lets look at some cases to make it more concrete: E-commerce website Case: The website “Fashion Lab” sells clothes online. The website was built 2024 and has not changes since. Ana from Spain buys a T-shirt there in August 2025. Question: Does the website have to be accesible? Answer: Yes! The website is providing a service (e-commerce) which is a service covered by the EAA. Ana is an EU consumer so she is covered. The purchase means a new contract or transaction is made after june 28 2025. This means “Fashion Lab” cannot claim the grace period that allows existing contracts for use of inaccessible products or services to stay in place even after 2025. They cannot claim any of the grace periods for products since a website is not considered a product. Banking app Case: A banking app uses 3rd party software for some of the features they provide to consumers on the EU. They signed a contract for a trading platform and a peer-to-peer lending platform 2024, and provide access to these services through their own app. They are not accessible yet, but the bank accepts new customers daily. Question: Does the app, including the trading and peer-to-peer lending features have to be accessible, and when? Answer: The app provides banking services to EU consumers which means the service is covered by the EAA. For existing customers the app is allowed to keep providing these services until the next major release. However, since it’s possible to make the next release accessible (let someone audit and find issues, then fix them) there is no grace period that allows them to wait until 2030 to make the app accessible. And since there is no existing contract from before June 2025 with any new users – those have to be offered an accessible service from the day they sign up. So to summarize – yes, the app and all 3rd party software in it needs to be accessible for the bank to legally provide these services to new consumers after June 28 2025. The only way that the software can legally stay inaccessible is if they block new users, and make no updates, and allow only the current users access during their current contracts, but no longer than 5 years. In all other cases, it has to be accessible now, since June 28 2025! Parking tickets, machine and app Case: A parking company allows users to pay with an app, or use a physical self-service machine that takes card or coin payments. The machine has a touch-screen and buttons, but they are not reachable for wheelchair users, and the touch screen doesn’t conform with the EAA regulations. The app is not accessible. Question: Is the company allowed to keep the machines installed and in use, and for how long? Answer: Yes! Ticket machines are considered “Self-service terminals” and they have a grace period until end of life, at most 20 years. The next time the physical machine is replaced, the new version must conform with accessibility requirements. If a new release of the software is made for the machine, it needs to be accessible in the ways that it’s possible. Question: Are they allowed to let their app be inaccessible, and for how long? Answer: No! Apps are services, not products, and all services must be accessible from June 28, 2025. Technically they are allowed to keep pre-deadline users using the inaccessible app. But if they accept new users – they have to get an accessible version directly – so that exception is likely not relevant for most companies. Question: If the app is made accessible, can they then keep installing new inaccessible machines after June 2025 since they provide an accessible option? Answer: No! There is no exception for new self-service machines placed on the market after June 28 2025. Having an accessible app is great, and often the best way to allow users to use their own device and assistive tech to make sure they can use your services. But there is no exception for “equivalent accessible service” in the EAA. Notice that the law doesn’t care when your company purchased the machine, only when it was installed and “provided to the market”. So if you have a stockpile of inaccessible hardware that was purchased before June 28 2025, you are still not allowed to install it after this date. Summary Websites and apps used to deliver services covered by the EAA have to be accessible now. Even if you have supplier contracts signed before 2025 for software that you use. And even though you are allowed to provide inaccessible experiences to existing customers for the remainder of their contracts signed before june 2025, you are still not allowed to sign up new customers for inaccessible services. So if you havn’t started your accessibility journey yet – it’s probably time! Feel free to reach out and we’ll happily give you some suggestions on what you can do yourselves, and when it is appropriate to involve a specialist like Axess Lab. If you have a case not covered by this post, let us know and we will make updates continuously! Need help? Check out our accessibility consulting services or just drop us a message at [email protected] – we’re happy to help! Ads and accessibility mismatch Erik Gustafsson Spagnoli — Fri, 21 Nov 2025 13:49:49 +0000 Ads online today are not built with accessibility in mind. I’ve asked if there are good ad-platforms out there and the answer is a silent tumbleweed rolling slowly across the dessert. Why is it like this? Time for advertisement platforms to step up! Examples when it does not work Contrast issues Contrast issues affect all users and impacts users with vision loss most. It puzzles me that companies paying for ads do not think of visibility since they pay for creators the work and for the placement. This is too common on bus-ads where you have so little time when you are behind the bus driving or as a pedestrian. You should really, with good vision, be able to see it from 100m away. Don’t get me started on company cars with bad screen print, that’s format for another ranting article. It’s important to have a look at 1.4.3 Contrast (Minimum) which says text must have 4.5:1 for regular text in contrast ratio. Large text can pass with 3:1. Remember this is the minimum level and not maximum allowed level, so aim higher! Ad for Elgiganten on Dn.se, default view: Ad for Elgiganten, where green text has low contrast of 2.92:1 in contrast ratio: Ad for Elgiganten, play button has very low contrast, 1.67:1 in ratio: This ad for Skoda must win the contrast ratio with a staggering 1.01:1 in ratio: ALT-text is missing When making image ads that have a clear message to donate to a cause, in the example from Aftonbladet. Without vision you cannot donate to the cause since the ALT-text is missing. Thus you are being excluded. I haven’t found any ads with meaningful alt-texts. Sometimes there’s a generic alt=“Ad” but this means you’re both excluding users and not getting the ad across to all potential users. Text cut off on zoom Some ads do resize with the content on zoom even if it’s an image, but the bounding box does not allow for increasing the space or changing from a 3 column view to 2 or 1 columns. The example on Coop.se shows content gets cut-off after 200% zoom and text-resize. Default: 200% Zoom: Text-resize of 200% (32px): Overlapping when text is resized Some ads actually have real text. But, the website or the advertisement platform is not adapting. While this ad probably works better in a screen reader, it’s impossible to read with larger text size set. The example shows Dn.se Allsvenskan MAX ad fails resize text getting overflowed. Default view: Text resize 200% (32px) overlapping the text on top of each other: Resize of page does not affect the ads. Ads not affected by text-resize For most people using text-resize in the browser the company will pay form the ad-view but the user will not see the ad text. Text has been resized but does not affect the ad for Jula. Default view without text-resize enabled: Volkswagen ad does not resize the text: Overflow fail People use different widths on their browsers, sometimes to be able to use multiple programs on the same screen. Overflow fails when you narrow the window and the ad is just an image. Example of SVD.se: Strange inverted zoom Ad on Aftonbladet.se for Blocket. Zooming in on content does the opposite for the ad and actually zooms out and decreases size. Clearly they have not tested this at all with accessibility in mind. Let’s make it better Use real text – not text as part of images In the world of ads, sometimes you do not have a choice or it’s not easy to do. There are of course benefits to using real text since you can change the zoom without loosing quality – an image becomes pixelated when zooming. Other benefits: Text-resize Change of color High contrast modes Font flexibility It is possible to translate Content is reusable for different formats and platforms. Easier to adopt to dark mode Links in images If you do use a link (URL) in the image, be sure to make it short so the ALT-text also can be understandable. An image with a QR-code should state that the QR-code is in the image and also where it leads. Using a QR-code could be easier for some since they do not have to memorize the link. For all text content in an image you need to consider 2.5.3 Label in name. What should you include in ALT-text? As all ALT-text you should start with the most important part and continue with less important parts. The basics of writing ALT-text can be read in Alt-texts: The Ultimate Guide. Practical example Let’s look at an example where AI-services have done complicated things on an ad with a lot of text in it. AI suggestion: Original in Swedish: ALT=”ICAKaviar_Mildrökt_VälbalanseradRökigFastGod_TestAlltOmMat_20241014_DisplayAnnons_GAM360” Translated to English: ALT=”ICAKaviar_Mildrökt_WellbalanceSmokeyFirmTasty_TestAlltOmMat_20241014_DisplayAd_GAM360” Underscore and capitalized words makes the ad unnecessary verbose and hard to read. Not all contents is added and the AI function cannot know the context and what is important. Better example: Original in Swedish: ALT=”Annons från ICA för ICA Kaviar mildrökt. Utsedd till bäst i test enligt Allt om Mat 14 oktober 2024: Välbalanserade smaker med tydlig rökighet. Bra lagom fast konsistens. God eftersmak. Gå till ICA.se för att se produkten.” Translated to English: ALT=”Advertisement from ICA for ICA Kaviar mildrökt. Named best in test according to Allt om Mat 14 October 2024: Well-balanced flavours with a distinct smokiness. Good, firm consistency. Delicious aftertaste. Go to ICA.se to see product.” End with the action, “Go to Ica.se to see product”. It might be too verbose starting with “Advertisment” so test it with users on your platform. Depending on context, use clarifying wording that it’s an ad. Put all the text in the ALT-text. Video ads Start with making sure the script for the video production includes verbal descriptions of such things as names or texts on display in the video and important visuals. This decreases the need of alternate video with audio description tracks. Always include captioning since most people view video content on social media without sound. They can be on a bus without headphones or putting kids to bed and rather not wake them up. So if you miss captions in the content you miss the chance to sell to a lot of people. Some platforms do not allow captions with files ( such as .srt or .vtt formats), embed the caption in the video in these cases since it is better than no caption at all. For audio, people can listen to video content but move focus when the ads arrive. If you miss the visual description in the audio track you’re missing a lot of users. Personally I am in the habit of multi-tasking and focusing on something else. So if you don’t even verbally tell me the company name or pitch you pay for views without value. Other parts of importance: Put text on solid backgrounds with good contrast. The video and audio should be easy to follow, so don’t go too fast. Make sure captions come synchronized and at least one line at a time. Avoid very high sound in the beginning and keep volume at the same level. Autoplaying sticky videos should be avoided. Make sure not to have ARIA-LIVE reading out updates such as the number of seconds to the next video. It interrupts the user. Conclusion Ads suck today, either the advertisement platforms do not support what is needed for accessibility or the publisher platform has restrictions. Let us increase the demands when choosing and procuring a platform. Everyone should be able to read ads if they want to. Want our help with making your ads and services better? We’ve guided many organisations through this process before and can make it a whole lot easier for you too. Check out our accessibility consulting services or just drop us a message at [email protected] – we’re happy to help! Accessible iOS design: how Forza Football included blind users Diogo Melo — Tue, 04 Nov 2025 09:50:31 +0000 In my early teens, when my sight was slowly entering the low-vision territory, I loved football (soccer, if you’re American). These days, despite being blind, I still follow scores and a few leagues. My favorite iOS app for keeping up with football is Forza Football, thanks to its outstanding support for VoiceOver, Apple’s built-in screen reader for blind and low-vision users. An unexpected accessibility champion If you haven’t seen it, Forza Football doesn’t just show match scores and league tables — it also presents lineups in a clean view that’s fully accessible to VoiceOver users. In this video you can hear VoiceOver navigating Forza’s lineup view — first Real Madrid’s starting lineup from goalkeeper to forward, then Barcelona’s, from goalkeeper to forward in reverse vertical order. Team lineups are one of the most visual parts of any football app, but Forza has made them incredibly accessible to VoiceOver users like me. It’s so well done that I, as an iOS engineer, just had to replicate their navigation logic to understand how they did it! How VoiceOver Reads a Football Pitch As you may know, in left-to-right languages, VoiceOver typically navigates from bottom to top, and from left to right. In football commentary, lineups are usually described from defense to attack (goalkeeper to forwards) and from right to left. Forza represents the pitch vertically — one goal at the top and one at the bottom. Since lineups show pre-match positions, the topmost player represents the home team goalkeeper, and the bottommost player is the away team goalkeeper, with both teams’ forwards being on either side of the center of the pitch. For the home team, VoiceOver’s default navigation naturally follows football’s logic: it reads the goalkeeper first, then moves across defenders, midfielders, and forwards — from left to right on screen (which is right to left from the team’s perspective). However, for the away team, things get trickier. The goalkeeper is at the bottom and the forwards at the top. VoiceOver, by default, reads in the opposite order to what a football fan would expect — forwards first, goalkeeper last. A user could adapt by finding the away goalkeeper and then swipe left, but that would be poor usability. Thankfully, Forza’s developers went a step further. In this video, you can hear VoiceOver navigating my app’s initial lineup page — reading the home team correctly, but the away team from forwards to goalkeeper. The Trick: Accessibility Priorities iOS provides a property called accessibilitySortPriority. This accepts a numeric value — the higher the priority, the earlier VoiceOver reads that element during normal swipe navigation. By default, each view has a priority of 0 (zero). It doesn’t affect where items appear on screen (exploring by touch still works), but it changes the logical order in which VoiceOver moves through the elements. I don’t know exactly how Forza implemented its lineup logic, but here’s how I replicated it. My implementation starts with an array of players ordered “footballistically” (goalkeeper to forward, right to left); This array is divided into subarrays, one per sector: goalkeeper, defenders, midfielders, etc; In SwiftUI, I render each sector vertically and each player horizontally within it — left to right. That works perfectly for the home team — once each player’s position is added to their accessibility label, VoiceOver reads the lineup exactly as it should. But for the away team, since SwiftUI can’t reverse the view creation order, I invert the formation (for example, 4-5-1 becomes 1-5-4) before creating the sector arrays. The result is a correct visual layout — but VoiceOver now reads from forwards to goalkeeper. To fix that, I assign an increasing priority value to each player while iterating in reverse order. The goalkeeper ends up with the highest priority, ensuring VoiceOver reads from goalkeeper to forwards, just as football fans would expect. // Setting the reversed priorities func playersByPosition() -> [[PlayerPrioritized]] { var players = awayLineup.reversed() // from forward to goalkeeper var sectors = [[PlayerPrioritized]]() var priority = viewSortingPriority for (i, sector) in formation.reversed().enumerated() { // creating inner array per formation sector sectors.append([PlayerPrioritized]()) for _ in 0.. Since this property affects the entire view, I also adjusted priorities for the home team and bench sections. To keep things simple, I used a small increment value (0.08) for each away player’s priority. In this video, you can hear VoiceOver navigating my app’s fixed lineup page, finishing the home team lineup, then reading the away team from bottom to top — goalkeeper to forwards, as intended. Handling Substitutes Unlike Forza, I decided to display both teams’ substitutes side by side. Without custom priorities, VoiceOver would alternate between home and away substitutes, reading one from each side. Here, you can hear VoiceOver reading substitutes alternately — one from the home team, then one from the away team. By assigning a higher priority to the home team substitutes view, VoiceOver reads the entire home bench first, then the away bench. Within each group, it uses the default navigation order. // LineUps View var body: some View { ScrollView { HomeTeamView(home: homeTeam) .accessibilitySortPriority(3) AwayTeamView(away: awayTeam, sortingPriority: 2) Text("Substitutes") .accessibilitySortPriority(1) HStack { BenchView(team: homeTeam) .accessibilitySortPriority(0.9) BenchView(team: awayTeam) .accessibilitySortPriority(0.8) } } } In this last video, VoiceOver reads all home substitutes first, then the away substitutes, in the correct order. Conclusion If Forza can make something as visual and complex as football lineups both accessible and fun to explore, then surely simpler apps can do the same — with much less effort. Accessibility isn’t just a technical checkbox — it’s a chance to make more people feel included, informed, and part of the game. I’m deeply passionate about both iOS development and accessibility. If your iOS team needs someone who truly cares about accessibility and great user experience, I am opened to new assignments. Drop me an email at [email protected]. How to handle accessibility reporting under the European Accessibility Act (EAA) Hampus Sethfors — Tue, 30 Sep 2025 09:04:12 +0000 If your company is covered by the European Accessibility Act (EAA), you’ll need to handle two types of accessibility reporting: a publicly available accessibility statement and a report to the national monitoring authority whenever you discover an accessibility issue. Here’s a hands-on guide to both. 1. Accessibility statement – what you must publish The Directive (EU) 2019/882 (Chapter 4) states: Service providers shall… explain how the services meet the applicable accessibility requirements. The information shall be made available to the public in written and oral format, including in a manner which is accessible to persons with disabilities. In practice, this means you need: Written format: A public accessibility statement describing how your service meets accessibility requirements. Oral format: Customer support staff trained to answer questions about accessibility from users. Your accessibility statement should be easy to find, written in plain language and updated regularly. Here are some examples of accessibility statements to draw inspiration from: IKEA’s Accessibility Statement. In-depth article about accessibility statement for the EAA. BankID’s Accessibility page. Eric Eggert’s long list of accessibility statement examples. 2. Reporting accessibility issues to authorities The same chapter also states: Where the service is not compliant with applicable accessibility requirements, service providers shall immediately inform the competent national authorities of the Member States in which the service is provided, to that effect, giving details, in particular, of the non-compliance and of any corrective measures taken. In other words, if you find an accessibility problem, you need to report it promptly. Some countries have already created online forms for this. For example: Netherland’s reporting form (acm.nl) Sweden’s reporting form (pts.se) Finland’s reporting form (saavutettavuusvaatimukset.fi) Expect more countries to follow with similar systems. What if you don’t report? Technically, you can skip it — but it’s risky. Authorities are expected to issue fines if reporting obligations aren’t met, even if you haven’t had a chance to fix the issues yet. Proper documentation is likely to be treated as a compliance requirement on its own. If you operate in multiple countries? You’ll need to report separately to each country where you offer services. There’s no unified system (yet), so your internal process needs to adapt to each country’s reporting requirements. While the forms are similar, they’re not identical. For instance: Finland asks for a date for corrective actions The Netherlands asks for an estimated number of affected consumers A good practice is to create a central reporting template that can easily be customized for each country. How leading companies handle reporting Companies that are ahead of the curve have built accessibility reporting into their normal workflows. Here’s how they typically do it: Tag accessibility issues in their issue tracking system (for instance using “accessibility” as a tag in Jira). Every ~14 days, an accessibility lead or consultant reviews new issues and adds them to a pre-prepared reporting template. The template includes estimated timelines per priority level – for instance “High – 4 weeks”, “Medium – 8 weeks” and so on. They submit the report to each relevant national authority. This approach keeps reporting manageable and ensures nothing slips through the cracks. Final thoughts Yes — this reporting requirement may feel a bit annoying at first. But there’s a silver lining: it nudges companies to do the things they should already be doing to make accessibility part of everyday work. It pushes teams to: Build regular testing, issue tracking and reporting processes Increase internal know-how about accessibility And most importantly, take accessibility seriously rather than treating it as an afterthought In the long run, these steps don’t just help you comply with the law — they help you deliver better, more inclusive products and services. Want our help with EAA reporting or accessibility strategy? We’ve guided many organisations through this process before and can make it a whole lot easier for you too. Check out our accessibility consulting services or just drop us a message at [email protected] – we’re happy to help! Beyond convenience: how smart tech can enable disabled lives Hampus Sethfors — Thu, 07 Aug 2025 07:02:53 +0000 Smart tech lets me be a writer, a cat owner, and a caffeine addict on my own terms. That’s not just convenience – that’s access. A few weeks ago, I had an interesting conversation with a friend. We talked about whether or not we identify with our tech. I’m sure I speak for all of us when stating that we at least have to admit to some level of attachment; I mean how many of us leave home without our phone in our pocket. But I also dare saying that this goes deeper for those of us who actually can’t imagine life without a technical aid. And I don’t mean that in the sense of not being able to check your Instagram feed for a few hours, but like in not being able to move. Literally. Or in some cases breathe. For my friend and I, our devices are pretty much the very foundation of who we are, and the lives that we can imagine ourselves living. I’m next to nothing without my Permobil, or – of course – my phone, which involves so much more than an Instagram feed. I will get back to my phone, and my friend, in just a bit, but first I would like to offer a brief introduction to something called independent living. What is independent living? Independent living is a theory/philosophy that states everyone’s right to live an independent life. Independent should not be understood as completely self-sufficient, but as no more dependent than anyone else. We are all codependent in a society – most of us use public transport, visit health facilities, have attended school or university, and so on. For some of us, this codependency on a societal level also involves other services, such as for example the right to personal assistance, or – of course – the right to specific technical aids. I’m obviously all about these rights, and a society without said services would not only go straight against basic human rights, but also be a society where – instead of living in a community as an equal citizen, I would probably end up in some sort of institutional facility, which would not only take away my complete freedom, but also, to be honest, most probably would shorten my lifespan quite drastically. Assistive tech: sometimes life-saving, always life-shaping I’m lucky enough (should be a basic right though…!) to have personal assistance, so smart home appliances may not be what keeps me out of institutional ”care”, but the fact is that many of my disabled friends are not so fortunate. For them, assistive technology which is possible to buy on an open market can really make all the difference. It may be the reason they are able to have a job, be a parent, a friend, a student, or a cat owner. But for me, it sure is handy too! Let me give you a few examples: During that discussion with my friend on whether we identify ourselves with the tech we use, we also started talking about neat functionalities that make things so much easier for us in our everyday lives. Stuff we either already have, or stuff we would like in the future. Coffee is a non-negotiable ritual for both of us. I use an app-connected capsule machine to get the perfect cup, whereas he uses a smart thermos that notifies him when the brew hits exactly 65 degrees. Yes, it’s that serious. Most of our homes are of course fueled by smart technology. We got all the obvious stuff, such as smart lights, robotic vacuum cleaners, humidifiers, and air cleaners. My friend is a big fan of his smart home hub, to which everything is connected, but I’ve yet to get one myself since my voice is rarely recognized by tech. (Maybe that’s something to keep in mind for those of you who develop these products: not all voices are loud and clear.) Fridges and washing machines as tools for freedom Some things on my list of to-buys for the future are a smart mattress, smart fridge, and smart washing machine. A smart mattress is pretty self-telling; we all wish for a good night’s sleep I guess. But a smart refrigerator and washing machine would for me not just be nice and fancy, it would also mean being in full control of my own home and house chores. My personal assistants are great and handpicked by me very carefully. Many of them have turned into close friends over the years. But relying on six to seven individuals when it comes to your own stuff can sometimes be a bit tricky. Especially when it involves things such as finding groceries in the back of your fridge. Or making sure that fancy T-shirt is indeed put on the handwash-program, rather than the regular 40 degrees. It would be great to have a fridge that can tell me when I’ve run out of milk, or beer for that matter. And to be in full command of my own laundry. As you can see, smart home appliances are not just about convenience. It’s about who gets to have agency in a home, and who gets to be safe, spontaneous, and in control. Because that’s what smart technology can do – extend the possibilities for autonomy. Design with, not just for Before I wrap this up, I would like to offer one piece of advice:  design with disabled people in the room. Not just as test users, but as co-creators, designers, developers, and decision-makers. Because what’s good for us tends to be good for others too. Voice control helps busy parents. Smart lighting supports elderly folks. Hands-free cooking solutions are great for multitasking busy people.  Inclusion isn’t a niche feature – it’s just good design. So maybe it’s not about reinventing the wheel – or the washing machine – but about asking who it’s spinning for. And if you’re thinking “huh, what if she’s right – maybe we should have more disabled people involved in our design process!?”, then great news for you! All you have to do is drop us an email at [email protected]! Axess Lab is full of brilliant, opinionated, disabled stars, and we’d love to work with you! Because inclusion isn’t just a niche feature – it’s just good design. Accessibility after 28 June 2025: what’s next? Veronica Cofre — Sat, 28 Jun 2025 06:47:38 +0000 The EAA has come into effect and many businesses and organisations have worked to meet the accessibility requirements set by the EU Accessibility Directive. For public websites and private organisations providing public services, this deadline means that their digital services must be accessible to all users, including people with disabilities. So what happens after this milestone? Will accessibility be “done” once the legal deadline has passed? The answer is a clear no. Accessibility is not a one-time fix or a checklist to be ticked off. It is a long-term strategy that must be an integral part of digital development going forward. What are the next steps after 28 June? Starting 28 June 2025, it is important to recognise that accessibility is not a one-off achievement. Rather, it is an ongoing process that requires continuous attention, monitoring and improvement. Websites and digital services are “living, evolving platforms” that change over time. They need to be regularly reviewed and updated to ensure they remain accessible to all users, especially given technological advances and changes in user behaviour. Accessibility as a long-term strategy Meeting the legal requirements is just the first step, accessibility is about something bigger. It is about creating a digital service that is usable and inclusive for as many people as possible – which makes it even more important to work on accessibility as a long-term strategy. By making accessibility a key pillar in your digital development, you will create a more sustainable and user-friendly service for everyone, not just those with specific needs. Why accessibility specialists are needed for the long term To ensure that your website or app remains accessible and usable in the long term, it is crucial to have accessibility specialists on your team. They can help to: Adapting solutions to new technologies and user interfaces. Ensuring that digital services comply with current accessibility standards Conduct user testing with people with different disabilities. Train internal teams and create a culture of long-term accessibility. This is just the beginning As 28 June 2025 passes, it is not the end of the accessibility journey, it is the start of an ongoing commitment to improvement. By making accessibility and inclusion a natural part of your digital work, and by collaborating with accessibility specialists, you will build digital services that are not only relevant today but sustainable and futureproof for everyone. Glassmorphism Meets Accessibility: Can Glass Be Inclusive? Nicko Syropoulos — Wed, 11 Jun 2025 00:10:27 +0000 Tech giants such as Microsoft and Apple are integrating glassmorphism into their design languages, aiming for a refined, unique, modern and engaging user interface (UI). However, the appealing nature of frosted-glass effects raises questions about accessibility, especially for consumers with cognitive and visual impairments. What is glassmorphism? Combining the words “glass” and “skeuomorphism”, the latter derived from the Greek words “skeuos,” (tool or vessel), and “morphe,” (shape). Stated otherwise, glassmorphism is a design technique inspired by glass as a physical material. Glassmorphism design trend has become rather popular on contemporary user interfaces, including Windows 11 and macOS Big Sur. These days, the trend is followed by Microsoft’s Fluent Design System and Apple via Liquid Glass intended for OS releases in 2026. Its futuristic yet tactile sensation comes from its elegant, frosted-glass form. Glassmorphism appeals clearly since it creates a visual richness, lightness, and elegance. It defines spatial connections among UI components rather successfully without depending much on shadows or borders. For many designers, it presents a convincing way to improve the polish and elegance of digital products. But this visual appeal begs a serious concern: How accessible are glassmorphic user interfaces? For consumers with visual, cognitive, or motion-related disabilities, this style offers great challenges even if it is aesthetically pleasing. Transparency may reduce text contrast; blur effects may cause sensory pain; layered depth may distort information hierarchy. These issues run the risk of excluding a sizable portion of the user population, especially those who use assistive technology or perceive visual information differently. Here we will look at the potential accessibility risks that glassmorphism poses and how we can eliminate them. Whether creating a bespoke design system, native OS UI, or a web application, you will find strong practical ideas to make sure the frosted glass effect does not unintentionally exclude users. What makes glassmorphism visually appealing? The goal of glassmorphism is to make digital interfaces look like frosted or translucent glass. By using depth, blur, transparency, and delicate shadows, it creates a multi-layered, nearly real digital environment that is both immaculate and sophisticated. Glassmorphism is defined by several key elements: Translucent layers: Usually with a gentle blur, elements show a portion of what is behind them. This creates the illusion of transparency and depth, similar to looking through frosted glass. Effects of blur: Background blur is essential because it highlights the “glass” effect while softening what is behind translucent elements, maintaining readability. Soft borders and highlights: Panels often have a bevelled, floating appearance that adds dimension when delicate borders and inner shadows are used. Bright backgrounds: Glassmorphism works best when it is applied on top of dynamic images or bright gradients that highlight the transparency. Minimalism: The effect works well with simple, minimalist designs, where the glass layers’ visual impact is enhanced by their simplicity. When used properly, glassmorphism can give interfaces a modern, flowing, and engaging feel. It exudes a feeling of high-end, superior visual quality that is captivating and dynamic. Additionally, it enables designers to create a visual hierarchy without the need for distinct divisions, resulting in interfaces that are more elegant and complex. Despite its obvious aesthetic appeal, its reliance on visual effects creates a delicate balance that is prone to breaking if accessibility is not incorporated from the beginning. Accessibility concerns As visually striking as glassmorphism can be, its core features (transparency, blur and layering) can introduce serious accessibility pitfalls. These issues are not just theoretical; they directly impact users with visual and cognitive impairments. Let’s break down the most common concerns: Low contrast One of the main concerns with glassmorphic design is low contrast. When text and icons are placed on semi-transparent backgrounds, especially over colourful images, the contrast ratios often fall short of WCAG 2.2 requirements. While larger text and user interface elements require a 3:1 contrast ratio, body text requires a 4.5:1 contrast ratio. As a result, reading the content is difficult for people who have age-related vision problems, colour blindness, or visual impairments. The truth is that many users find the text hard, if not impossible, to understand, despite the fact that designers may find the aesthetic balance appealing. Background interference Glassmorphic layers allow for the visibility of background elements such as colours, shapes, or motion even when blur effects are present. This may result in distracting visual clutter that obstructs the content. Additionally, dynamic backgrounds like videos, animated gradients, or scrolling elements are making this problem more noticeable, which makes it especially difficult for people who struggle with cognitive impairments or information processing and focus. Motion & blur sensitivity Animated effects like parallax and layered transitions are commonly used in glassmorphism, and they can make people with vestibular conditions feel lightheaded or queasy. Furthermore, the blurring effect can strain the eyes, particularly when used excessively or for prolonged periods of time. Furthermore, these effects demand significant system resources and Graphics Processing Unit (GPU) power, which may impair performance on devices with lower power. This situation disproportionately affects users who have financial or other constraints. Disrupted focus & information hierarchy The distinctive softness of glassmorphism adds a sense of elegance, but if it is not applied with discipline and with careful planning, it can also create ambiguity. Establishing distinct visual hierarchies is made difficult by elements’ tendency to blend into backgrounds. As a result, design elements might not be clear and evidently interactive, which could lead to users—especially those who use screen magnifiers or quickly scan for interactive regions—missing crucial controls. Incompatibility with assistive technologies Visual effects and semi-transparent layers do not always work well in high-contrast modes or by using screen readers. These elements may become obstacles to the user experience in the absence of semantic structure, appropriate labelling, and fallback designs. Designing accessible glassmorphism Glassmorphic effects can improve usability and aesthetics when applied thoughtfully and with empathy. The secret is to avoid making accessibility an afterthought and to design with inclusion in mind from the start. The objective is to tame glassmorphism, not to give it up. The following useful tips will assist you in maintaining the elegance of glassmorphism while making sure your user interfaces are accessible and usable by all: Maintain strong contrast The most important rule: never compromise on contrast. Ensure all text and essential UI elements meet or exceed WCAG 2.2 contrast minimums (4.5:1 for body text, 3:1 for larger or bold UI components). Use background overlays or semi-opaque fills behind text to separate it from underlying content. Do not rely solely on blur. It softens the UI, but it does not guarantee sufficient separation or legibility. Offer reduced transparency options Respect user system preferences with the `prefers-reduced-transparency` media query or platform-specific accessibility APIs. In most OS, users can reduce transparency in the platform. Your UI needs to comply to those user preferences. Control motion & blur intensity Use blur and animation sparingly and test across a range of user needs. It is suggested to: Avoid excessive blur strength (especially `backdrop-filter: blur(20px)` and higher). Reduce animation duration and complexity for interface transitions. Respect the `prefers-reduced-motion` media query and provide fallbacks. Reinforce information hierarchy Do not let form override function. Use visual cues that reinforce content structure. It is suggested to: Combine transparency with subtle borders or shadows to define layers. Use clear spacing, padding, and alignment to indicate hierarchy. Avoid placing critical information on heavily textured or animated backgrounds. Test with real users and assistive technologies What looks elegant in your designs might break down in practice. Ensure your designs are robust by testing them under real-world conditions: Use screen readers like VoiceOver, TalkBack or NVDA to evaluate accessibility. Test contrast and legibility across various levels of visual acuity and colour vision. Simulate device performance on low-power or older hardware. Consider scenarios like high-contrast mode, zoom/magnification, or dark mode Conclusion Once thought to be a passing trend, glassmorphism is now a fundamental component of modern UI design. Large tech companies use it because of its intricate and multilayered design. But this strategy requires careful thought. Visually appealing interfaces may unintentionally impact user experience and exclude users if motion, transparency, and blur effects are used without giving accessibility top priority. Thankfully, inclusivity and artistic excellence can coexist. We can produce experiences that are both contemporary and accessible by putting careful design principles into practice, such as maintaining contrast, offering choices for less transparency, and taking user motion preferences into account. As developers and designers, we have a duty that goes beyond aesthetics. In addition to being aesthetically pleasing, a truly excellent interface is also useful for all users. The future of ICT Viveka Sjölund — Thu, 15 May 2025 06:17:27 +0000 I see… ICT”, says Daniel while reading the tea leaves in his steaming cup. Let’s see what important message does the future bring? The overlooked side of modern convenience When we talk about accessibility in the future, we’re really talking about the everyday technology we already use: ATMs, ticket machines, self-checkouts. Things that work fine for many people – but can be barriers for others. Have you thought about how often you use a touchscreen in daily life? When you pay in a store, leave a tip at a restaurant, take the elevator, or check in at the doctor’s office? Touchscreens are everywhere – but not everyone can use them. Have you ever tried getting around a shop with a stroller? Then you might know how narrow some spaces can be. For someone in a wheelchair, that’s not just an occasional problem – it’s something they deal with every day. The law helps – but it’s not enough The new European Accessibility Act brings stricter rules to make products and services easier for more people to use. This includes things like self-service kiosks and payment machines – which often aren’t built for people with different needs. But following the law isn’t enough on its own. Accessibility isn’t just about rules, it’s about understanding people, and designing things that work for everyone from the beginning. Making accessibility real We believe these challenges can be solved – and often it’s not that complicated. The key is to involve real users early in the process. When people with disabilities help test and give feedback, the final result works better – for everyone. In the film, we see Nathalie shopping at a store that has added a second screen at a lower height. That small change makes it easy for her to pay from her wheelchair. We also see Claudio picking up a parcel from a PostNord locker. Instead of having to use a touchscreen, he can open the box through an app that works with his screen reader. These are examples of good solutions that makes a big difference when you think about inclusion from the start. The future is accessible We don’t need fancy new technology to make progress. We can start with what we already have. When we include people with different needs in the design and testing of services, we discover things we might not see otherwise. Accessibility isn’t extra – it’s a basic part of a fair society. And it starts by asking the right questions and really listening to the answers. Accessibility statement for the EAA Erik Gustafsson Spagnoli — Fri, 28 Mar 2025 14:43:02 +0000 It’s been annoying me for a very long time that accessibility statements are so damn bureaucratic. People take the templates provided which are made for legal compliance – and they suck. Why not make the statements a place for people to receive help and get easy to understand information on the things that might not work so well for them? TL; DR; The accessibility statement template is based on the demands from the public sector EU Web Accessibility Directive (WAD) and the focus is on assisting the user, rather than merely outlining legal requirements and shortcomings or failures. Even if you cannot do all the recommended things now – add it to your long term plan. Where do we want to be in 5 years? Psst… we also created a template! Why use an accessibility statement? It is a central place for documentation. The European Accessibility Act (EAA) says you need to document how you meet the directive. European Web Accessibility Directive (WAD) goes with the accessibility statement and many other countries have the same format. It’s not for everyone to read Some of you might argue, well the statement is not for everyone. It is just for monitoring agencies, or as they in the EAA refer to market surveillance, and procurement processes. Then why would it have a prominent position in the structure and include ways for the USER to report and receive help? You most often find it in the footer and for the European Web Accessibility Directive (WAD) it has demands for the public to be able to report to your company and the market surveillance. Transparency with public documentation With transparency you meet the requirements that the public can access the information. Why not also make it easy for your organisation? Everyone can reach a webpage that is open to the public and not everyone looking to buy something reaches out to you. Benefits of transparency: No need for the management to have access to ticketing systems such as Jira. No administrative costs for giving the public access. Easy to access for everyone investigating your compliance before engaging. A way to get feedback from the public if they see it is worth it. Everyone in the organisation knows how accessible the product is. It forces a way of working, you need to know and have processes to be able to know who is responsible. The ticketing system you use probably needs a special accessibility-statement flag. Customer services need to be properly trained on picking up errors from customers. What does the law state? Of course we need to do what the applicable law says as a starting point. But remember, the law is not the important part here. The intention of the law is to make products and services accessible. Laws and standards is just the bare minimum and you can do far better for the users. European accessibility act (EAA) CHAPTER IV Obligations of service providers Article 13 Obligations of service providers 2. Service providers shall prepare the necessary information in accordance with Annex V and shall explain how the services meet the applicable accessibility requirements. The information shall be made available to the public in written and oral format, including in a manner which is accessible to persons with disabilities. Service providers shall keep that information for as long as the service is in operation. Finland’s market surveillance Saavutettavuusvaatimukset require accessibility statements. European Web Accessibility Directive (WAD) Preamble to the European Web accessibility directive, Recital 44 (44) An accessibility statement should be provided by public sector bodies on the compliance of their websites and mobile applications with the accessibility requirements laid down by this Directive. That accessibility statement should include, where appropriate, the accessible alternatives provided for. Other laws and regulations There’s local legislation such as: Americans with Disabilities Act (ADA). Section 508. Accessibility for Ontarians with Disabilities Act (AODA). National anti-discrimination laws. If you work actively with the suggested format of this guide, you will most likely cover the requirements in each country. You do need to check if there are formal parts that need to be added, such as the program manager for section 508. Important parts to consider There are some things you should address in the statement. Many of them are for the user. Use HTML Avoid complex documents whenever possible. They are harder to keep updated and there’s a bigger risk that different versions circulate – compared to using HTML-pages which are accessible by default. Write in easy to read language The language should be easy to read for everyone. I have yet to see people say “Oh this was easy to understand – this sucks!”. Even people at the government agencies would appreciate less legal jargon. The link in the footer should probably include the name of the company such as “Accessibility at Axess Lab” instead of “Accessibility statement”. Make it easy for the user to give feedback Giving the possibility to give feedback in different ways makes it easier for you to get valuable information about what does not work. Think about anonymous feedback through forms, voice messages or calls, email and a chat service. Make sure that your staff that handles complaints through the selected channel have knowledge. Remember the pages you provide, the forms and third party providers of chat of course have to be accessible. Show that you care and fix feedback In general people just move on if something does not work for them. By being transparent with what you have fixed after the user has reported issues people are more likely to return and report more issues. Archive regularly To be able to keep the documentation relevant and fresh. Make sure you regularly save a copy – so that you can prove to the market surveillance, if needed, that you have done your homework. Add all channels Customers don’t care where they interact with your company and which are exempt from legal demands. For them, you’re a brand and they use whatever channel they come across. Treat your customers with equal respect wherever they choose to meet you at. Add physical accessibility Companies are more often both digital and physical. There are locations to visit such as stores and resorts. There’s the fusion of digital interfaces in physical self service terminals such as ticketing machines and payment terminals. Regardless of the legal requirements, people want to know if the services you offer are accessible for them. You can also include cognitive aspects as the excellent Swedish accessibility guide from Stendahls bil has done. They offer a range of descriptions such as scents and sounds, how their dealership can be accessed with service animals and for people with varying neurodiversity. “Good to know” things can be for example: When is it noisy in the restaurant? When is it quieter to check in? Can I get around everywhere with a wheelchair? Another good example from Swedish train operator SJ with information on travelling with a disability. List of issues Describe the issues and to make it easy, follow the format of the ticketing system you use. This part of the statement could be collapsed in an accordion. Since most users don’t really care about the individual issues. So why keep them on the page then, you might ask? Well, let’s circle back to having a central and transparent place to put all documentation – it makes sense. Disproportionate burden For the public sector the government agencies have been very strict in what they accept as disproportionate burden. In Sweden, Digg has stated that if a company risks bankruptcy by implementing accessibility fixes immediately, it is still required to make the fixes but may plan to do so over a longer period. Criteria for assessment of disproportionate burden The directive says that an assessment needs to be made and documented to be able to claim disproportionate burden. Sometimes you do have a lot of things to fix at the same time or it could be that fixes lead to a totally different product. Market surveillance in the country you’re active in decides if you can claim disproportionate burden or not. If you do claim it for economic reasons, you still need a plan on how to fix the issues over time. You need to make a documented economic assessment and send it to the market surveillance. More information about disproportionate burden can be read in the EAA. We have a template for the European Accessibility Act (EAA) Together with the W3C Nordic accessibility community group we have created a simple and diverse template. And we’re giving it away for free. Easy to use. Made for people. You can use the blocks you find fits your needs. Enables help when something is broken. Accessibility statement template on W3C Nordic accessibility community group Github. Need more than a template? Enlisting the help of our awesome accessibility consultants gives you ongoing support with accessibility issues, user testing, and making sure your documentation reflects real progress. Easily check for web accessibility problems in ten minutes or less Thea Walther — Fri, 13 Dec 2024 08:09:43 +0000 Does making your website accessible feel a bit intimidating or overwhelming? Are you unsure where to begin? Don’t worry, here are a few quick steps to look for low-hanging fruit, with no technical expertise required! Testing on a computer Keyboard Navigation Note: If you’re on a Mac, you may need to change some settings for the Tab key to work as described here. Adrian Roselli has helpfully compiled a few links to guides for this. Use the Tab key to cycle through the page you want to look at. Ask yourself these questions: Is there a visible focus indicator at all? If there is, can you spot it easily or is it too subtle? Does the focus move in the order you’d expect? This should typically be the same as the order you’d naturally read the page in, i.e. top down, left to right. Can you actually reach every button, link and interactive element you see? Can you activate the focused elements with the Enter or Space key? Mouse Navigation Point at the various interactive elements with your mouse. Can you see any visual indication that they’re interactive when you do? Zooming in Try zooming in on the website by holding down Ctrl (Windows) or Command (Mac), then pressing the + key. Zoom until the indicator says you’re at 400%. Can you still read and navigate on the website? Is it a reasonably pleasant experience? Testing on a phone Target size Have a quick look at the interactive elements on the page, like buttons. Do they feel large enough to comfortably press with your fingers, even if you’re on a shaking bus or similar? Pinch to zoom Touch the screen with two fingers, then move them apart to zoom in. Does this work, or is nothing happening? If nothing happens, is there a good reason to prevent users from zooming in? Hint: There usually isn’t. Landscape mode First, make sure your phone’s “auto-rotate” setting is enabled. Then flip your phone sideways and look around the site in this mode. Does it automatically adjust to your phone’s orientation and otherwise work properly? Can you see every part of it, or are there things “hidden” outside the screen? In the image above everything is visible and usable. That’s what we want! Sure, there is some wasted space and some may not like the look and feel of it in landscape mode – but that’s fine! And… that’s it for now! By spending ten minutes or so going through these steps, you can catch a whole lot of accessibility issues. Of course, this won’t catch everything (or even most things), but it’s a great way to look for low-hanging fruit without much effort. What’s next? If going through these quick tests made you want to fix and improve things, here are a few great options for further steps! Solving known issues A natural next step after finding accessibility issues could be to fix them. Maybe you and/or the people you work with can do that, or maybe you could use some help. We’d be more than happy to help with this! Conducting a full accessibility review As you already know, these quick tests won’t find all the accessibility issues on a website. One of the services we provide is accessibility audits, where we’ll thoroughly review your website and compose a clear, helpful list of the problems we find along with detailed descriptions, suggested solutions, estimates of each problem’s impact and the effort needed to solve it, and references to established accessibility guidelines such as WCAG. You could even combine this with the previous point, letting us help fix the issues we detect during the audit! Educating and up-skilling your staff If you really want to get a handle on accessibility, it needs to become an integral part of your workflow. We offer workshops, seminars and courses that can help your staff improve their expertise in accessibility, enabling you to identify and address issues autonomously as well as reducing the amount of accessibility issues that make it onto your websites and other services to begin with. If you’d like our help with any of this, have a look at our services! European Accessibility Act (EAA) – What you need to know Joel Holmberg — Mon, 01 Jul 2024 12:46:36 +0000 June 28, 2025. That’s the deadline for all banking services and e-commerce in the EU to be fully compliant with the European Accessibility Act (EAA). Here’s a straight-to-the-point summary of what you need to know! Background The EU combines two of their general goals in the European Accessibility Act. First, the EU wants people with disabilities to be included in, and get full access to society. Second, the EU want companies competing on the inner european market to have clear and fair rules, equal for all participants, no matter which European country you are based in. That’s the background for creating the new EAA regulation. In a nutshell, the purpose of the EAA is for products and services to be accessible for consumers: Without vision With limited vision Without perception of color Without hearing With limited hearing Without vocal capability With limited manipulation or strength With limited reach With risk of photosensitive seizures With limited cognition Who is affected? Six types of consumer services are affected, as well as eight types of consumer products. Any company selling or providing these are affected. For services, all ICT (information and communication technologies) used by consumers to access the services are covered – for example self-checkout kiosks used to pay for groceries in a physical store. It’s important to note that it is the service or product that is targeted, not the company as a whole. That means, if an e-commerce website has a page for consumers, and another page for business-to-business then only the page for consumers needs to comply with the new regulation. Affected consumer services Electronic communication services like network subscriptions, phone calls, e-mail, SMS, chat, video conferences. Media services like streaming services or program guides in TV-boxes. Transport services like websites, apps or electronic ticket kiosks needed to access the transportation service. Banking services, including websites, apps and queueing systems or kiosks in a physical bank office. E-books E-commerce including any website or app where a purchase can be made of a product or service. Affected consumer products Computers, including laptops, smartphones, tablets etc. Payment terminals including payment card readers. Kiosks for cash withdrawal Self service terminals, if the terminal is used for ticket sales, check-in etcetera for services covered in “Affected consumer services”. Interactive information terminals, but only if they are used for the services listed above, and are interactive. For example interactive screens used to present time tables at the train station are affected, but if the screen just presents the departure times (not interactive) then it’s not covered. Products used to access communication services, like routers, modems and smartphones. Products used to access media services, like digital TV boxes or smart-TVs. Reading tablets used to read e-books. What are the penalties? The biggest risk is that you might no longer be allowed to sell your services in the EU. Loosing the EU as a market is likely the biggest consequence for most companies. However, the more likely consequence for most is sanctions – the size depending on each contry. In many countries sanctions will be in the range $1000 – $1 000 000, and with multiple or recurring compliance issues there can be many sanctions. In some countries law makers have added prison sentences of up to 18 months to the penalty scale. Others, like Latvia, have added “confiscation or destruction of property” as a potential consequence. What do you need to do? You need to conform with relevant standards and guidelines. There are also some documentation requirements. Exact requirements and interpretations can differ between each contry, but the EAA sets a very clear baseline for all countries in the EU. This regulation is intended to be be consistently implemented – so the variance will likely be very small. Design for all Accessibility is about making something that works for people with diverse abilities. So the standards to follow are all focused on making sure your users with or without disabilities can use your products and services. The best way to accomplish this is probably to work together with users with disabilities and making sure in usability tests that they can actually use your stuff! If actual people with disabilities have a good user experience – you will comply with most formal legislation on the fly. However, the Directive that’s the foundation for the EAA, points towards standards that specify formal, testable criteria for compliance. EN 301 549 The EU standard EN 301 549 covers the formal requirements for products and services. The section about requirements for web and apps is mainly a copy-paste of the Web Content Accessibility Guidelines. There are a few WCAG criteria that don’t apply in EU – for instance you don’t have to caption live streamed videos even though it’s a WCAG requirement – and some that go beyond WCAG – like having to support dark mode. But apart from a few exceptions like those, it’s WCAG that applies. WCAG – for web content The Web Content Accessibility Guidelines list 50+ criteria for accessible web content. It’s divided into 3 levels; A, AA and AAA. The law requires conforming with level A and AA requirements only. As an example, the first WCAG criteria 1.1.1 states that all non-text content, like images, must have a text-alternative for users who cannot see the image. If your website has only text content – you already pass this criteria. Congratulations! WCAG is versioned, and as of writing this article, the latest version is 2.2. Some legal documents still point towards version 2.1, but you may as well start working with version 2.2, as conforming with version 2.2 also means you conform with version 2.1. Apps For iOS and Android apps, you need to conform with relevant parts of the WCAG. Out of the current 56 criteria in WCAG 2.2, only 44 apply to apps. There are a few more general requirements for ICT in the EN 301 549 that also apply to apps (read chapters 4 and 5). But as a rule of thumb – if you make sure you meet the success criteria in the WCAG (interpreted in an “app” way), you will come a long way! The WCAG beginners’ guide on appt.org is a good place to start understanding how to conform with WCAG in iOS and Android apps. Documents Documents (commonly PDFs), that are a part of the product or services covered by the EAA, also have to be accessible if they are intended to be read by your users as a part of the service. This includes “terms and conditions” and similar documents, but also interactive form documents like loan application forms in PDF. Any documentation of the product or service needs to be available in an accessible digital format like an accessible webpage (HTML), or an accessible PDF. Hardware, payment terminals, kiosks and physical devices The requirements for hardware differ depending on the type of service the hardware provides. On top of that – there are often other laws governing physical products that overlap the EAA or add to the complexity. Check out our indepth article on that theme: European accessibility act (EAA): kiosks, touch screens and physical devices Summary Making sure your software and hardware works well for users with disabilities is important, and now also legally required in the EU. You may want to get expert help evaluating if your current websites, apps and devices are compliant! Luckily there are companies like ours that can help you with that. The standards are great tools, but remember – the purpose of these laws are to make sure your stuff works well for everyone. A fully compliant piece of ICT can still technically be completely useless, so try to involve users in your efforts to test your product or service – preferably users with disabilities! Get some help along the way If you need help sorting out what your organization should do, in what order, and how to do it – reach out to us here at Axess Lab. We are specialised in digital accessibility, and stand ready to help your team! Here are a few of the things we can help you with when you are ready to start the journey: Accessibility review Usability testing with people with disabilities Accessibility statement – let us create it for you! Accessibility training, workshops and talks Or just drop us a message on [email protected] and we’ll take it from there. European Accessibility Act (EAA) – Kiosks, touch screens and physical devices Nathalie Pentler — Mon, 01 Jul 2024 12:34:47 +0000 In June 2025, the European Accessibility Act will be enforced. Most of the buzz is around websites and apps, but many physical devices will also be covered by the new legislation. Let’s look at that more closely and create some buzz around the accessibility of touch screens and other physical devices! Issues Nathalie face as a wheelchair user I’ll begin with some personal experiences. I use a wheelchair, and face issues with reaching devices all the time. Here are some photos I’ve taken when grocery shopping! By the way, if you’re just looking for what the actual law says, skip ahead to What are the actual requirements? This is a classic struggle: a touch screen for choosing what grocery I have on the scale. Way too high, and even if it would have been lower, there’s a table blocking my wheelchair from getting close. Another common issue: payment terminals on gas stations. Here is a newly built charging pole for an electric vehicle. It’s obvious that they haven’t considered accessibility here at all. Can you spot the issues? Well, the raised ground and two metal poles prevent me and other wheelchair users from getting to the actual charging post at all. And even if we learned how to magically hover above the ground and get there, the interactive touch screen is way too high to reach. This has been a problem for a long time with regular petrol pumps, but in those cases you often have the alternative to ask the people at the cashier to activate the pump and then pay inside the store. This is often not an option with electric car chargers, making it a more pressing problem. Sidenote: many cars are adapted so that people without use of their legs, or with other motor impairments, can drive them independently. Check out this video where Kathryn Granger showcases how she drives and gets her wheelchair in the car. Moving on: a lot of new “smart delivery boxes”, like the one below, cause problems for me. The first challenge is reaching the touch screen. Then the lottery starts. Is my package in one of the around 50% boxes I can reach? Or is it in one of the top boxes I can’t reach? Self-service check-in terminals at airports are often also difficult for me. Feels like a lottery every time! Will I be able to use them or have to look around for help. So a lot of the issues that me and other consumers with motor impairments face are about reaching stuff. Issues for blind users Another group that is heavily affected by inaccessible touch screens and other physical devices are blind folks. Here, most major exclusion comes down to the fact that you’re required to use a touch screen that does not have screen reader support. For instance, you often need to input numbers on the smart post box touch screen display. “Oh, but supporting screen readers must cost a ton of money to support”, you may think. Well, there are often creative solutions if you have accessibility in mind from the start of projects. Let’s look at a few.. Nice solutions are already out there Here in Sweden, our state funded postal service “Postnord” also has smart post boxes. But opening those boxes is achieved by using an app on your own device instead of a touch screen. The app supports the users own screen reader, and voilá: no problem opening the boxes! There’s still the issue of reaching the box for me and others with motor impairments, and I heard from a blind colleague that he often struggles with finding which door has opened. He listens for the click of the door and starts waving his arms close to the device to find it. A bit of subtle sound design would do the trick! The Postnord app shows that good solutions are already out there. Let’s look at a few more positive examples! In Norway, they let you choose if you only can reach the middle boxes (“Luker på midten”), or all of them (“Alle luker”), when choosing delivery methods. Very nice! When activating your tickets in public transportation in Stockholm, here a ferry, the devices are often available at different heights. Great for me! Great for kids who want to blip their parent’s ticket! Great for anyone! Another example of terminals at different heights. On a “Max Burgers” restaurant, I can press a button at the bottom corner of the touch screen to have the top part of the interface move down to a more reachable height. Creative thinking! Although I still found it hard to reach the top most buttons when the interface had been moved down, so they could probably do this a bit better. Look closely at this ATM: Notice the headphone jack? It makes it possible for the user to get spoken instructions, and not have sensitive bank details be shouted out through a speaker. Finally, a few years back we made a short article including a video of an accessible queue system that has a built in screen reader. So there are great solutions out there already, to get inspired by! What does the EU law actually require? I’ll now summarize some key points in the European Accessibility Act relating to the topic of kiosks, touchscreens and similar devices. This is mainly taken from the following sections of the actual Directive 2019/882: Chapter 1, Article 2 for which products are covered Annex 1 for the actual accessibility requirements Annex 2 for examples and possible solutions to fulfill the requirements Feel free to open the Directive and dig in yourself, but below are some highlights I’ve extracted. We’ve also got a general article on the European Accessibility Act that you can check out. What products are covered Some parts straight from the directive: The following self-service terminals: payment terminals the following self-service terminals dedicated to the provision of services covered by this Directive: automated teller machines (ATM:s) ticketing machines check-in machines interactive self-service terminals providing information, excluding terminals installed as integrated parts of vehicles, aircrafts, ships or rolling stock So in a nutshell: self-service payment terminals and basically any self-service terminal related to e-commerce or banking (services covered by the directive). When do we need to comply? The European Accessibility Act covers products that are “placed on the market after 28 June 2025”. So you will not have to trash all your current products! You’re allowed to keep them for another 20 years, or until they need to be replaced. So focus on the new products you’re shipping, not the ones already out there. Here’s the exact phrasing in the Directive: Given the cost and long life-cycle of self-service terminals, it is appropriate to provide that, when such terminals are used in the provision of services, they may continue to be used until the end of their economic life, as long as they are not replaced during that period, but not for longer than 20 years. What are the actual requirements? In a nutshell, the devices covered needs to be accessible by for consumers: Without vision With limited vision Without perception of color Without hearing With limited hearing Without vocal capability With limited manipulation or strength With limited reach With risk of photosensitive seizures With limited cognition The specific requirements are laid out in Annex 1 of the Directive. Here are some highlights I’ve extracted. the product shall avoid modes of operation requiring extensive reach and great strength What’s extensive reach and great strength? Well that’s detailed in the EN 301 549 standard, chapter 8 “Hardware”, which includes requirements like having interactive elements at a height between 38-122 cm: when the product uses visual elements it shall provide for flexible magnification, brightness and contrast So you should aim to have zooming features and similar controls in the interfaces. If you don’t, you have to instead meet quite rigid requirement of text sizes. For instance, if the normal viewing distance is 50 cm from the screen, the minimum allowed character height is 6.1 mm. Check out the specifics of text sizes in chapter 5.1.4 “Functionality closed to text enlargement”. when the product provides for communication, including interpersonal communication, operation, information, control and orientation, it shall do so via more than one sensory channel. Fancy language..! But in plain words: you can’t only show something visually on the screen, there needs to be another “sensory channel”, for instance sound, to give that information. Basically: support a screen reader or similar. when the product uses colour to convey information, indicate an action, require a response or identify elements, it shall provide an alternative to colour So users with color vision deficiencies also can understand the information you’re providing. Here are some requirements that are specific to self-service terminals: shall give the possibility to extend the time given shall allow for the use of personal headsets when the product uses audio or audible signals, it shall be compatible with assistive devices and technologies available at Union level, including hearing technologies such as hearing aids, telecoils, cochlear implants and assistive listening devices So those were some of the general requirements laid out in the Directive, with a bit of details from the EN 301 549 standard. There are many more, and a fair bit to wrap your head around. Most touch screens, kiosks and other physical devices are far from compliant, so there’s likely a big effort needed to make this sector more accessible in the years ahead. How do we prove compliance? As long as your products fulfill the requirements in the EN 301 549 you don’t have to do anything! However, if you do not fulfill all the above requirements in your product then you have to inform the appropriate market surveillance authorities in the EU country where the product is sold or distributed. When? As soon as possible, some countries mention within 14 days of identifying the issue. How? This differs between countries, and at the time of writing this, no list is available of the process for each EU country. In Sweden, an online form will be made available by the Post and telecommunication board (PTS). As soon as we have a list of each country’s process, we will link to it here! What to report? This may differ between countries, but be prepared to report things like: Product name and type/model, brand, and ID number (e.g., GTIN/EAN code, article number, or other identifier). Type of issue: Brief description of what doesn’t meet requirements (e.g., requires too much reach/strength, or lacks alternatives to biometric identification). When the issue was discovered: Date or time period when the issue was first noticed. Who is affected: If possible, specify if a particular group is impacted (e.g., certain user segment or users with certain disabilities). Actions taken or planned: What has been done so far to address the issue, and what is planned. Contact person: Name, email, and/or phone number of someone the authority can contact if needed. Want a helping hand? We can help you audit and user test your payment terminals, self-service terminals and other machines. You will get a detailed report document which will check the requirements against the standards in EAA. Regardless of if the machine is covered by the law we can help you make it better for all users. Also: if you want help from accessibility experts like me to analyze and recommend solutions for your specific product or service – you’ll find the contact details in the footer below. Thanks for putting in the effort to make these devices more accessible for me and many others with disabilities! Accessible QR Codes – The Ultimate Guide Daniel Göransson — Thu, 16 May 2024 06:14:02 +0000 You may think QR codes are great for securing your login, or letting users read more online about a product marketed in a newspaper ad. But there’s a high risk of creating barriers for people with disabilities unless you use QR codes correctly. This article is your ultimate guide to accessible QR codes! What is a QR code? “QR” stands for “Quick Response”, and you’ve probably seen the square pattern being used in “read more” parts of paper ads like this: Or in online bank login screens like this: And there are many other uses for them: Scanning a QR code on a new dishwasher to open up an installation guide video. QR codes in books to help people with dyslexia access audio/video versions of the text, like in this “Blipsay” example by Susanna Cederquist. (PDF) Restaurants linking to a digital menu or the restaurant’s app from a physical menu. Physical mail containing links where a QR code saves you from manually typing the URL into a browser. Smart TV interactions like login and payments using QR codes on screen. Advantages of QR codes A QR code can bridge the gap between the physical world and the digital world, and it can save a lot of time and hassle for many users. Most modern phones have QR code scanning functionality built into their camera apps, so users don’t even need to download an app. General problems with QR codes Instructions and help QR codes are still fairly new, and far from everyone knows what they are and how to use them! And even if users know how to scan a QR code with their camera app, that doesn’t always work! For example, two-factor authentication QR codes look exactly like other QR codes but shouldn’t be scanned using the normal scanning app or the built in camera scanner – users might need to use a specific identification app to scan these codes. It’s not alway obvious to users when to use which app or why there’s a difference at all, so instructions are vital! The solution is to write instructions of the steps that the user needs to complete in order to login with a QR code. Here’s a good example of instructions for a two-factor identification app in Sweden: Open the BankID app on your phone or tablet. Press “scan QR code” in the app. Point your phone or tablet at the QR code on the screen. Follow instructions in the app. You can also give some extra instructions for screen reader and other assistive technologies users, which we’ll go through later. When you use QR codes in printed media or in other devices such as TV-apps or gaming consoles, it helps to put the link (URL) which the QR code represents in plain text alongside with the code itself. Not only does this enable the user to manually type it if needed, it also hints at what the QR code will do – take them to another page. Time limit QR codes used in login scenarios often have time limits for security reasons, but short time limits mean that some users won’t have time to read the instructions or start the app and scan the QR code before timing out. These time limits are often set based on the assumption that the user is a strong reader with perfect eyesight, but following written instructions when using assistive technologies like a screen reader can require a lot more time than other users would need. The same goes for many users with cognitive disabilities like dyslexia or ADHD. According to the WCAG (Web Content Accessibility Guidelines), users need to be able to extend any time limits in digital interfaces at least 10 times. Users also needs to be notified at least 20 seconds before the time limit ends. So if you, like many others, use a 30 second time limit you need to notify the user after 10 seconds that they’re running out of time. That is, if you want to conform to the WCAG, which may be required by law. If getting interrupted once every 10 seconds with a warning prompt sounds annoying, you should try to increase the default time limit to be as long as possible. We recommend having at least 3-5 minutes as a time limit. You still need to give users the ability to extend the timer, and we recommend notifying the user when there are 30 seconds left. Give the users an easy way of extending the session, such as pressing a button or just pressing space on the keyboard. When you notify the user it’s important to use simple language and short copy, such as a message like “30 seconds left for login” along with a button labeled “Extend”. Alternative ways to sign in If you have limited motor skills or have a mobile device mounted on a wheelchair, it could be hard or even impossible to pick up the phone and use the camera to scan the QR code. We made this video with Jessica, who highlights how QR codes can be problematic for users with motor impairments and shows her “techy workaround”. It’s in Swedish but with English subtitles. To manage these issues you should offer alternative ways to sign in, for instance using username and password with two-factor authentication. There are such solutions that don’t require scanning a QR code. Here in Sweden we have software called “BankID on file” for this purpose. Problems for screen reader users As a person with a severe visual impairment, I often use a screen reader to convey text and other information on my screen. With QR codes being very much a visual thing, many accessibility issues arise from assuming that users are able to see what’s on the screen. Position of QR codes Not all users will know where on the screen the QR code is located. You can help us by making the QR code centered on screen, as that’s where most users will likely attempt to find it first. Obscured or cut-off QR codes Not all users will know if the full QR code is visible in their browser window or not. Here we see a QR code getting cut off when I’d accidentally made my browser window smaller. Tiny browser windows are quite common among our friends who use screen readers, because most of them don’t need it to be a specific size to access the content of the page. Cut off QR codes can also be caused by being zoomed in using browser zoom settings, but more on that under “Problems for magnification”. A common (but bad) solution to this is adding help text with shortcut commands to increase window size. One big drawback when implementing this solution is that you need to have system specific shortcut commands for all operating systems and browsers. There are also usability and accessibility problems with this approach: Long instructions of this type add additional cognitive load in an already stressful scenario, especially if time limits are in place. Users who need to increase the window size might not be able to use a keyboard as instructed due to motor impairments (try pressing “ctrl” and “+” at the same time with only one arm). This can be better solved by letting users activate the QR code by clicking or pressing it as well as activating it using the space or enter keys, and letting that trigger fullscreen mode using the Fullscreen API in the browser. Check out my CodePen demo or the demo with code to see how. That way the whole QR code will be visible, no matter which window size the browser was opened in. QR code outside of view Imagine this: the user has scrolled down on the page and the QR code is no longer in view, but they’re unaware of this issue due to visual impairments. This actually happens a lot while reading list instructions or navigating on the QR code page, the screen reader might scroll down and the QR code is then outside of view or cut off. How to solve it? Make the QR code sticky so it can’t get out of view! It’s OK that some content gets hidden behind the QR code when scrolling, if the QR code is the main actionable content on the page as in my examples. However, if possible, you should make the instructions at least partially visible when scrolling. Again, you can test my CodePen demo and try to zoom in and scroll. There’s no need to make the QR code huge, so set a maximum width and height if it helps ensure that instructions remain visible. Zoom in on my CodePen demo to see how it can stay small even if you use ctrl or cmd + to zoom in the page. Instructions and help This is one of those situations where it makes sense to give additional instructions for how to scan the QR code to users who use a screen reader. But they can be visually hidden since non-screenreader users don’t need these. Example of hidden screen reader instructions: Scan with your camera about 30 centimeters, or an arm’s length distance from the screen. Make sure your screen shade or screen curtain is off JAWS: JAWS-KEY + SPACEBAR + F11 NVDA: NVDA + CONTROL + ESCAPE VoiceOver: VO + SHIFT + F11 Ensure your browser window is large enough or maximized. Press the QR code button or maximize here (button to activate). Ensure your screen/monitor is turned on. This conveys in simple language how to manage the phone and the screen while scanning a QR code. It gives a guide for turning off the screen curtain (dark screen) on different variants of screen readers. It also hints at maximizing the browser window and preferably gives a quick button that does it for them. And it states, perhaps obvious but easy to forget, to turn the screen on. Remember that many screen reader users do not need the screen to be on for them to browse the internet. It helps screen reader users if you put these specific instructions under their own heading. This makes it easier to find and navigate to the instructions. Problems for magnification Cut-off QR codes Users with reduced vision sometimes browse websites using browsers’ built in zoom of 200% or more. QR codes easily get cut off when zoomed in, as shown in this image where 250% zoom is used: The solution again is to make the QR code sticky or clickable – or both. Here’s a 43 second demo of that in action on a Swedish insurance and banking site: This also works great in my CodePen QR code demo. Mouse pointer obstructing QR code Users might have a larger mouse pointer or be unaware of its position. This can result in the obstructed QR code losing its functionality. You can solve this by hiding the pointer after three seconds if it’s on top of the QR code, like the YouTube player does when watching a video. Just set the ‘cursor’ css to ‘none’ after 3 seconds, and make sure to change it back when moving the mouse again. Did I mention that I have a CodePen demo? Well I do, and you can try hovering over the QR code and holding still to see what I mean. Great resources Länsförsäkringar bank have implemented a lot of the feedback and ideas from my talk. You can test it by selecting the option “Mobilt BankID”. WCAG 2.2.1 Timing adjustable – Success Criterion CodePen demo by Daniel Göransson Recording of my Swedish talk about QR codes from 2022 at T12t Meetup. English subtitles are available. I’ve embedded the talk here below. In summary Craft great instructions on how to use QR codes Make the QR codes centered Make the QR codes sticky Allow users to open the QR code in full screen Write extra instructions for screen reader users Hide the mouse cursor after 3 seconds Allow for longer timout limits (3-5 minutes) Thanks for making the web better! I’m happy you read this far! It means you care about making the web a better place for all users. Spread the knowledge and keep being awesome! Want to learn more? We run accessibility workshops that help teams design and test digital flows against WCAG, including timing, keyboard, and screen-reader requirements. Apple Vision Pro – with 1% vision Daniel Göransson — Thu, 29 Feb 2024 11:13:13 +0000 I got a chance to try out the Apple Vision Pro for an hour. Having a vision impairment myself, I obviously dove straight into the accessibility settings to find out if this new, hyped technology would work for me. Let’s go through how it went. I was worried I usually trust Apple devices will work great for me. For instance, when the Apple Watch first came out, I preordered it without hesitating at all. And sure enough, it came loaded with VoiceOver, zoom and other features, so it worked great for me. But with the Apple Vision Pro, I worried. Not that it wouldn’t include the accessibility features I’m used to, but because of the foundation of the technology: it records eye-movements and makes the image clear where you’re looking. For me, that could be a problem. I have peripheral vision. So I don’t see at all in the middle of my field of vision. Here’s a simulation of that: So I “aim my eyes” to the side of what I want to see, to see it as clearly as possible. If the Apple Vision Pro makes the peripheral stuff too fuzzy, then I’d probably not be able to use it efficiently at all. Onboarding – great first impression You can trust Apple to include accessibility right out of the box. No surprises there. On the first screen you get to, there’s a prompt to tripple click the digital crown to activate accessibility features. I immediately got a short tutorial to the main VoiceOver gestures: Pinch left thumb and index finger to click Right thumb and index finger to step forward Right thumb and middle finger to move back With this, I could independently read the first few screens with instructions. I was most interested in activating zoom, but figured that I’d do that once I got into the main interface. The eye setup – unsuccessful but not a blocker The main step of the set up process consisted of having me look at a dot moving around clockwise in front of me. Since I had VoiceOver turned on, the experience was a bit different than the “regular” one. In the regular onboarding, it shows six dots at once and asks the user look and tap for each dot. It does this in three rounds, with lighter and lighter conditions. For me, with VoiceOver turned on, it only showed one dot at a time and asked me to just look at it, not tap it. After a second or so it moved to the next position. Here’s a low-quality video of me doing the eye setup, with my colleague holding up an iPhone so you might be able to see what’s going on. Also, kids running around in the background, a great illustration of situational cognitive load..! Round 1 was on a dark background, but then it got brighter and brighter. It felt like I could do the first round quite well, but the third, brightest round was almost impossible for me. I also didn’t get any audio feedback when the dot moved, which would have helped. Something like: “Dot position at 12 o’clock. Dot moved to position at 2 o’clock.” And sure enough, I got an error message “Eye setup unsuccessful”. Tried it again, where my colleague tried to help by telling me when and where the dots moved to, but with the same result. Luckily, there was a “Skip eye setup”, so I pressed that. And found that it worked fairly well for me without the calibration. It made me a bit disappointed though, and I felt unsure how much this would affect me moving forward. Accessibility settings to the rescue Getting into the main screen felt nice. I had gotten the hang of the basic VoiceOver gestures and could quite easily navigate to Settings and Accessibility. This experience was very consistent to iOS and MacOS. I found settings for Zoom, activated full screen zooming instead of window zooming, which is how I have it set up on my other devices. To activate and adjust zooming, I press the physical button on the top left of the device and rotated the digital crown. I found that the maximum default zoom level was too zoomed out. So I needed to activate VoiceOver and try to increase the zoom level. Which was a slider, and I didn’t instinctively understand how to increase that slider. So had to go online on a smartphone and read up on that. Finally I figured out some way to do it. It wasn’t intuitive to me, though. So with the maximum zoom set to 10x instead of 5x, I could much more easily use the interface. But it was still difficult to read a lot of the text in the settings screen. So I increased the text sizes (dynamic type). Then I found the increase contrast feature which was a game changer for me. Making things more “dark mode” helped a lot. With these settings I could start the dinousaur experience that you probably heard of, use zoom in that to get a great experience! Overall My feelings after having used the Apple Vision Pro for about an hour were optimistic. Even though the eye setup failed, it didn’t seem to affect my experience much. I think after getting used to the gestures and interface it would become quite a nice tool for me. Especially once I get the hang of scaling “screens” in the interface larger or smaller, to immerse myself in them, that could work really well for me. Like for anyone, it’s going to require getting used to the new gestures and functionality. Doing this with accessibility features turned on adds an extra layer to this learning process. It all reminded me of when I first got my iPhone 3GS, the first iPhone with VoiceOver on it. There were a lot of gestures and fundamentals to learn and it took some time. But we all know how that turned out, I use my phone everyday with gestures that now feels like second nature. I’m optimistic that I one day will feel the same about Apple Vision Pro! Inaccessible Marketing Emails Suck! Erik Gustafsson Spagnoli — Thu, 22 Feb 2024 14:45:12 +0000 I hate to see how many marketing emails that go to waste and frankly, suck! It really has irritated me throughout the years – so much it became my contribution to Axe-con 2024 and this article. Summary This is a rant about poor email communication that relies too much on embedded images being shown (they rarely are). Bad examples of newsletters and other types of email are shown (some are truly horrible) along with good examples to learn from. This is not an in-depth how to guide on coding accessible email but I will share resources to get you started. Introduction to my rant So across my many email accounts I get roughly 300 emails every week. Important stuff such as invoices and meeting plans, updates from the kids’ school and doctor appointments. Also, I get calendar reminders, updates regarding services, and countless marketing newsletters. Too many marketing emails rely on using images. But guess what, I never load images in my Gmail accounts! Images are deactivated by default and other email services and it takes a manual click to load them. When I travel abroad I have limited data plan I need to be mindful of the mobile data usage, even though I have unlimited data plan in Sweden. So, with a well structured email, a great subject and well described content you have perhaps half a second to get my interest so that I will open your email. Given these challenges and the resources required to communicate or sell through email, I just really hate to see companies mess up by relying too much on using images in their emails. You have customers who actually want to read your content – make sure they can by making it accessible for all of them. Do you have the time to listen to me whine? Let’s go Transparency I myself or colleagues at Axess Lab has worked or are actively working with with several of the clients listed. Often we work with departments that do not directly work with marketing and they often do not see improving newsletters as a priority. I hope this is a wake-up call for our clients and everyone else reading the article – that you need to get your stuff together! We or other professionals are out there to help. Reason to not load images There are many reasons to not load images, these are some of my reasons. Bandwidth restrictions You might have a slow internet connection, it might be to low speed in your home or while travelling on a train. Going hiking often poses threats to your ability to load before the request times out. Limited data plan There are many reasons not to have unlimited data plans. They might not even be available in your country or as I often find myself while travelling abroad they are capped to a certain gigabyte. It might be very expensive and even paying by megabyte (MB) usage. So really it could be for some to choose between food or buying mobile data. Privacy When you load external images, you give away data about reading the email. Putting that in correlation with clicks on links and previous data shared it adds into the vast knowledge bank put in the hands of multinational companies working for profit. Examples of emails Emails that suck ICA bonus update newsletter My main interest with this newsletter is to know how many bonus points I have from the grocery stores ICA. Or more specifically how much I get back in money which I can deduct when shopping. Almost everything in the image above is text, except for how much bonus I get… Aaahhh! They also have some inspirational content to help you with shopping and what to eat. ALT-text is showing same text as heading. Let’s head to the loaded images! And here comes the loaded image, visually showing bonus amount of 50kr. The duplicated text is visually showing image about the shopping app. The text in the image is also different, so I suspect they did have a plan here… Kry newsletter Quite good layout with different backgrounds, headings and non-image call to action buttons. ALT-text says 115×115, probably perfect for the one editor. Not very helpful for the thousands of recipients. The footer of the email has contrast issues and cryptic ALT-texts. 115×115 ALT-text shows an illustration of a foot. Also, missing information about the sender. The two logos that had no ALT-texts was beneath social icons. TallinkSilja Club One newsletter ALT-texts are different from the headings, I think… But they are cut-off, only showing half. Zoomed in on ALT-text example only showing half. In darkmode the light green button background make the changed white text unreadable. Two ALT-texts provided: Aktiviteter ombord FriendSHIP Images displayed are not matching ALT-text description. FKP Scorpio newsletter Really poor contrast values on text and all images says “image” in their ALT-texts. Contrast of 3:2:1 on very light grey text on white background. Zoomed in on alt text saying “image”. Loaded images, showing lineup poster with a lot of band names. ALT-text “image” on loaded image is a concert poster. Bengans friday newsletter A ALT-text on image in email from music store says “Friday releases”. On mobile the email is zoomed out to desktop version. Unreadable. First part of Friday releases visual image loaded. Consisting of a lot of band names and albums. Last part of Friday releases with a lot of band names and editorial pitches. Haupt Lakrits newsletter Example of desktop email with no huge issues. Example of same email in mobile, unreadable zoomed out desktop version. Quickpix4u newsletter Broken attributes “jobname” and image code that should have been something else. Coop membership survey In mobile the button line-breaks and overlaps. BokaDirekt newsletter Thanks to Amin Amini for finding this example! Using CSS to make extra link large and covering surrounding text. Even the text next to link looks depressed as a sad smiley. Kronans apotek newsletter A lot of ALT-texts written which is on a positive note, but there’s no space in between and strange fonts makes it very hard to read. Horror section Kronans apotek Welcome as member at Kronans Apotek! So I became a member when I tested the site and made a purchase. Nice with a hello and welcome… But… It was very empty, which I thought was a huge waste of opportunity to make me buy more stuff. It was suspiciously empty with unloaded images. I needed to ease my suspicious mind… And behold, there was a lot of information about their offering, services, apps and much more. Everything is image-based with image-map links. It almost made me cry! Campaign newsletter at Kronans Apotek Campaign newsletter missing ALT-text for main image. Main image with a lot of offers. Main image zoomed out with about 20 call to actions in the image. MyFujifilm Empty email with only a footer. Let’s look at it with loaded images, surprisingly it has a lot of call to actions. Ubisoft newsletter Check out the big news from Ubisoft Forward! Unreadable alt-texts and no headings. 2:8:1 Contrast ratio on blue ALT-text on dark background. ALT-text has really generic naming that probably makes sense to the editor. Unsubscribe link. Link not underlined, it looks like text. Grinch not happy! Zoomed in on one of many ALT-texts having a generic name saying 212TTC_Right_Image. There’s probably some content behind the puzzle of ALT-texts? Images loaded showing text in images with key information about the offer. More text in images showcasing different games. SF Anytime latest movie releases This is from a Swedish online movie streaming provider. The ALT-texts are really hard to read, dark blue on black background. ALT texts beneath heading “Finally you can rent:”. ALT-texts: Barbie. Book. Art. Advertisement. Face. Firearm. Movie posters not conveyed in text. Random words for ALT-texts were different movie posters. Example “Face” was for the movie Darkland 2. Kila möbler Christmas offerings Empty email from Kila möbler. Zoomed out full empty email with only a footer. My ALT-senses are tingling again! About 60 CTA’s in the email, not displayed for potential customers. Stadium Outlet Email with product categories and text that says the terms of the offering and a “Shop”. The title is the best, “You haven’t missed…” Well in fact… I have missed all of it… Yet another text in image marketing letter. Debaser concert news Concert information heading “Dont miss this” followed by two empty images. Don’t miss this, images loaded shows date, location and band names. To be fair they have improved their email marketing letters since. Eventim localised newsletter Eventim newsletter in Swedish with event suggestions. Eventim suggestions zoomed in, generic ALT-texts are written in German. “Unsere Empfehlung 1” “Unsere Empfehlung 2” and so on. Eventim suggestions loaded images, showing poster, location, date, band name, and call to action to buy a ticket. Random Christmas newsletter Christmas email sent out. Two column layout. Black text on dark blue to black background with stars, and a moon overlayed by reindeers flying a sleigh. Unreadable. Thanks to Homer Gaines for sharing this horrific example Better examples There’s a soothing light in the tunnel and it is not just a freight train coming your way. There are better examples out there. And by better, I do not mean perfect. There are parts in the same email that are good and some not so good. The examples I will describe are simply just better in providing content that does depend on images. Impecta fröhandel Newsletter with ALT-texts, normal text and CSS call to action buttons. Loaded images, looks a lot prettier but it is mostly added visual goodies. Ebay newsletter Ebay newsletter showing good structure with headings and text. Ebay could improve adding product suggestion image ALT-texts. Runkeeper yearly update RunKeeper has ALT-texts and text content. Text content instructs to click on 2023 image to load the data, which has corresponding ALT. RunKeeper images loaded, visuals could be added as text instead of text in image. Eventim newsletter Better example from Eventim where image content is conveyed in text. Eventim email with loaded images. Jula weekly newsletter Email from Jula, a Swedish retailer. Using Headings and text and layout with spacing. Easy to see titles and pricing without images. Email from Jula with loaded images. The image content is conveyed in text. Product brand name is missing, could be added. Concert news from Live Nation Concert update from Live Nation missing ALT-texts but the headings are sufficient. Unsubscribe links In all my newsletters I’ve seen a pattern. Make it as damn hard as possible, or even impossible to unsubscribe. Do you know what happens to these emails? They get marked as SPAM and that surely decreases your visibility even more. Getting flagged as SPAM, unwanted or fraudulent email is not good… Sad but true! Bingolotto Horrible example and this is not by changing colors due to dark mode. This is just one of the worst examples I could find, it has 1:2:1 contrast ratio. Foursquare Just linking the word “Click here” and with a really really poor 2:5:1 contrast ratio Foursquare deserves the SPAM folder. It is extra evil making the font very very small. FKP Scorpio If the contrast was good enough the content would actually be good. Headings and paragraph text. 3:2:1 contrast ratio on text Unsubscribe link, good clear wording but bad contrast. 2:4:1 contrast ratio on orange link. Just fix the contrasts, pretty please… Bahnhof Unsubscribe link in a different language and only the word “here” is linked. Demando Unsubscribe link in a different language. Most people in Sweden speak English, but this is also a strange context switch. Nintendo Unsubscribe link with the word “Click here”. So you need to read the full paragraph to know what they refer to. Readly Unsubscribe link in text content only shown as bolded text with the word decline. Thanks to Martin Falk Johansson for this example Ebay eBay example with underlined, good contrast unsubscribe link Amazon Amazon email example on desktop, yellow button background with black text. Good contrast. Amazon email example on mobile dark mode, yellow button background with white text. Unreadable. Resources If you want to know more about how to make email more accessible and consistent across platforms, then these resources will help you along! A good resource from Harvard University about who to compose your emails Creating Accessible Emails. In 2019 i went to SmashingConf in Freiburg. I met Rémi Parmentier and listened to his interesting talk Think Like An Email Geek about how to combat a well designed email in different email systems, such as Outlook or Gmail. When I was looking for the link to this talk I also saw that he returned to Freiburg in 2022 expanding the subject with issues in Dark mode in the talk Shining the Light on HTML Email Dark Modes. Really interesting and he finished off with announcing the great resource Can I email which is based on the well known Can I use. There’s also an in-depth article Essential Tips and Tricks for Coding HTML Emails. Hats off for Rémi for sharing! You can always register and watch my talk at Axe-con 2024 on demand. Conclusion Just by testing your shit in at least a few email clients regularly you can avoid loosing potential customers not buying your products or services. There are really small fixes in which you can be visible to all your subscribers and… …tadaaa! You also make it more accessible for people who can’t see loaded images. Avoid the SPAM folder and make an A11y Grinch happy! Top seven free color contrast checkers & analyzers Hampus Sethfors — Thu, 18 Jan 2024 09:05:40 +0000 Here are seven great free tools that help you measure color contrasts and create beautiful, accessible color schemes that fulfill the contrast requirements in the Web Content Accessibility Guidelines (WCAG). 1. Colour Contrast Analyser – by The Paciello Group Colour Contrast Analyser Perfect if you’re measuring contrasts a lot. Desktop application for Mac and PC Analyze any colors appearing anywhere on your screen with the “Colour Picker” Shows how contrast varies with different types of color blindness Screenshot of Colour Contrast Analyser 2. Coolors – online checker Color contrast checker (coolors.co) Perfect if you just want a quick and easy contrast measurement without having to download anything. Measure contrast quickly in this web app Very intuitive to use “Click to fix” feature suggesting new accessible colors Screenshot of Coolors 3. Tanaguru Contrast Finder Tanaguru Contrast Finder Perfect if you want to find a new accessible color combination if your combination fails. Web app that measures contrasts Suggests alternative colors if your combination fails Open source if you want to contribute Screenshot of Tanaguru Contrast Finder 4. Contraste for Mac Contraste (contasteapp.com) Perfect, simple tool if you’re a Mac fan! Simple and lightweight The most aesthetic tool in this line-up, if you ask me Multiple ways to pick colors, including a handy pipette tool Screenshot of Contraste for Mac 5. Color Contrast – iOS app by UserLight Color Contrast at App Store Perfect if you prefer working on iOS devices. App for iOS devices Test colors of apps, websites or screenshots Available in iOS Control Center (swipe up from bottom of screen) for quick live testing Screenshot of Color Contrast iOS app 6. Android Accessibility Scanner – Android app by Google Android Accessibility Scanner at Google Play Great if you work with Android apps. Scan apps with your Android device Points out other accessibility issues as well as contrasts Created and curated by Google. Screenshot of Android Accessibility Scanner 7. Leonardocolor.io Leonardocolor.io A powerful online-tool that let’s you create color systems for interfaces and data visualisation. Need certainty you meet WCAG? Our experts do a full review with assistive tech videos and prioritized fixes. Toggles suck! Joel Holmberg — Fri, 28 Jul 2023 17:21:52 +0000 You’ve all seen them, tiny switches that let you toggle a setting. And maybe, just like me, you sometimes pause, thinking “…Is it on or off?” That’s because toggles suck! The cookie monster It all started when I wanted to find the best price for a new headset that I needed to perform my online courses for our clients. I went to www.pricerunner.com but I got interrupted by a cookie popup. Knowing that free websites use a lot of dark patterns and tricks to make us users accept trackers against our will, I wanted to make sure I did not accept any cookies. This is what I saw: “Are they on” I thought? And does “on” mean I accept or decline the cookies? What’s going on here? This interface forced me to think! Now, I’m no coward! My usual strategy online is to try pressing buttons to see what they do! Problem is – nothing seems to happen when pressing these buttons, so that doesn’t work! All I can assume is that pressing these gray things will change the setting. But change to what?! It took me far longer than should be necessary to figure it out. My confusion had time to turn into frustration and by the time I figured it out that frustration had lit a tiny fire of anger in my chest! I realized this was not my first time raging against unclear toggles, but I couldn’t exactly explain why I hated them so much? So I decided to do some research and collect my thoughts and now I’m writing this article about Why Toggles Suck! Short version This is an in-depth article, so here are the main takeaways for readers in a hurry. Toggles fail to convey their current status without making users think! They also have very poor accessibility for users with disabilities. They are used inconsistently across the web, and they don’t have native HTML support. Use checkboxes or radio groups instead, or some of the other options described below! What’s a toggle? Digital toggles have existed since the early versions of smartphones. Especially common under different “settings” views on touch devices, they are used for things like turning WiFi on/off. They are called “toggles” or “toggle switches” since they switch something on or off, or “toggle” its status back and forth when activated. To truly understand why they suck, it helps to compare them to two other controls that accomplish the same thing, but that actually work well. Physical toggles and digital checkboxes. Let’s first list some reasons why they work well, and then later investigate if digital toggles fulfill those same requirements or not! Physical toggles We are used to light switches turning the light on/off in a room. And many electrical devices use toggles the same way Toggles work well for lights and electrical outlets for many reasons, some more obvious than others: They enforce a mutually exclusive state, on or off. They let users press the state they want. Pressing “on” many times in a row is not a problem. Labels are a bonus but not really needed since: Context makes the current state obvious. The last one is important. The results are obvious when turning on a light switch – the room gets lit! The results are also obvious when turning on the electrical junction box above because stuff connected to it starts working. The toggle also has a LED indicator lighting up when it has electricity so it’s obviously on because a LED cannot light up without electricity in the box. So you don’t really need to label these toggles. The junction box toggle above still has “O/I” labels though, for when it is not connected to a wall outlet, or if the LED in the button is broken. But the light switch has no label, since context is enough… most of the time! But if that switch were to be placed – oh I don’t know – outside of my bathroom instead of inside . Then the status of the switch is no longer obvious! Like when my fiancé is using the bathroom and I’m outside the door. In that situation, how can I know what its current state is? I can’t! So really – she has no right to be mad at me for making her poop-in-the-dark, when I’m just trying to help light up the room! With a label like the one on the junction box you can put your finger on the choice you want and press it in. If you press “I” you can be sure it’s turned ON. If you want to be very sure, you can press “I” very hard or several times. It will still be ON. Assuming of course that you know that “O” means “off” and “I” means “on”. I still mix them up regularly; “O mean ON, and I means IN? No… what was it again?”. But I digress! Same with the light switch outside my bathroom. If it had “on” written above the button, and “off” written under it like this: Then I would know the state from the control itself because of a principle called the “proximity principle” in visual design. I would press closest to the “on” label. In both cases, you simply press the thing you want! Pressing what you want is a natural human instinct and universal. There are no cultures in the world where the learned pattern is to “press what you don’t want”. Imagine a child standing by an ice cream stand pointing to all the flavors they don’t want. Doesn’t make sense, does it? Because we humans point with one finger, in order to single out one thing while excluding everything else! We point to the thing we want! But then – how come we understand checkboxes? Digital checkboxes You see a checkmark and you want the thing to be checked – so according to “press the thing you want” I should press the checkmark to get it? No! So how come we understand checkboxes? A checkbox has two modes, “checked” or “not checked” and is normally part of a form. The checkbox as a form component comes from the physical paper form where it has been used for ages, long before computers were a thing. You would get an empty form and be asked to post or hand over a filled in one. It’s obvious that things are empty before I have started filling in the form. Text inputs are empty rectangles, checkboxes are empty squares. I use my pen to actively add things into the emptiness. It would be absurd (but not impossible) to have it the other way around – imagine a form coming filled with stuff, and then having to erase stuff using white-out (like tipex) or an eraser to complete the form. That’s just not how we do things anywhere in the world! So this has taught us a basic instinct over hundreds of years: empty shapes are not filled in, passive, untouched. Filled shapes are filled in, active, touched, and ready to be submitted. And that’s why checkboxes work, cognitively! Same goes for radio buttons where the filled in shape is the active one. It even works for text input boxes! In our user tests, a majority of users will assume an empty text field is actually mandatory and expect an input to be made. So much so that we even recommend you to not use asterisks * to indicate mandatory fields, and instead mark optional fields as “optional”. The “filled in = active / touched / done” pattern is so well recognized that if a text input field is not empty, many users will believe it’s done and requires no more work. That’s why you should try to avoid placeholder text… … and labels that are positioned inside the input field like the commonly used Material UI component, even if it “moves away” on focus: Users often assume “it’s filled in, so it’s completed” and skip to the next one looking for something empty. Enter digital toggles Now that we have established a few fundamentals that make physical toggles and digital checkboxes work – let’s see if digital toggles fulfill these criteria! Press what you want Nope! If a toggle says “On” then it’s actually an Off-button! Allows multiple presses on the thing you want Nope! Toggles change what they do each time you click them. This is also true for a checkbox (but they work for other reasons) – while a radio group fulfills this criteria! Context makes labels unnecessary Nope! Well, at least not usually. Toggles tend to be used for settings that are invisible or only visible later or in some other place. That means there is no context to help you. Active cookies are about as noticeable as my bathroom lights when the door is shut. In that they are not! In these situations – labels on the control are very much needed and important! So you’d hope they follow the “Proximity principle” – right? Proximity principle Nope! Labels are often put far away from the control, and you often have to move the toggle “knob” away from the label representing what you activate. Not closer to it! Perhaps I can make my point clearer with this image: In the top toggle, users can understand that right means “no cookies” since it’s the rightmost label. While in the bottom toggle that looks like most toggles online with only one label on the left side, right means “cookies” all of a sudden. Proximity principle, schmoximity principle! Of course this can be changed by having the toggle first, followed by the label. But is that how people commonly use toggles? No! Empty = passive, Filled in = active Nope! A toggle has no “empty” state. Only left/right. There is no obvious “default” state when untouched, and there is no universal agreement of which side a “knob” should be on to be passive or active, on or off. Most western designers seem to assume that “right = active”. But that’s my point! “Most” designers, but not all! It’s completely up to the designer to do what they want with toggles on the web because a toggle is not even a thing in HTML (more about that later). So there is no established “out of the box” behavior, at least not for the web! Oh, and only western designers – in arabic speaking countries the designers often make “left = active”. Perhaps it becomes even more clear that direction is not a universally understood pattern for active vs. passive in this image: I held my phone on the side when taking this photo. But I decided to not rotate it. No matter how I hold my phone I can understand which checkbox is active in the first frame. But which of the toggles are activated in frame 2-5? I have no idea! You cannot rely only on direction for conveying status! Conclusion #1 The most common toggle on the web fulfills NONE of the criteria that make physical toggles and checkboxes understandable! So am I done now? Nooooo! I’m just getting warmed up! Let’s look at 3 more things that are awful about toggles! Toggles don’t exist! “By hey – if they are so terrible, why is the toggle even in the HTML language?” – you may ask. It isn’t! It’s been made up by designers! HTML is the language of the web, where programmers add elements like If native HTML elements are good enough for Amazon, why are they not good enough for you?! You can even use other HTML elements to toggle settings. A normal If native HTML elements are good enough for Slack, why are they not good enough for you?! Text labels on normal buttons indicate the action of the button, especially when using active language like “Turn on” instead of “On”. Now, I know toggles “exist” in iOS and Android SDKs, so this last argument is not as valid for native apps. But the cognitive issues remain for toggles used in native apps, so they still suck! They just suck a tiny bit less in native settings… So toggles are not real, at least not on the web, but some designers want that fresh look and feel of the toggle! What’s the actual problem with not using built in HTML elements? Accessibility is the problem! Accessibility problems HTML elements come with a lot of “hidden features” that help users with disabilities and their assistive technologies, like screen readers. HTML elements have invisible roles, states, and labels only read aloud by screen readers and other assistive tech. This is what makes users with disabilities able to interpret and interact with websites, even if they don’t see the screen, or can’t use a mouse, or if they use eye tracking, or voice control, etc. If you just style a “box” (an HTML element is commonly used) to look like a toggle, and add some “onClick” logic in JavaScript, then it will be unusable by people with assistive technologies. Making such a toggle fully accessible is not impossible – but it’s really hard! Haydon Pickering has a very good article about it here: https://inclusive-components.design/toggle-button/. There are some more good ideas in this one by Sara Soueidan: https://www.sarasoueidan.com/blog/toggle-switch-design/ with both “proximity principle” and “press what you want” support. And Adrian Roselli has a nice article here: https://adrianroselli.com/2019/03/under-engineered-toggles.html. So it is possible to make accessible toggles. The problem is – most web developers and designers don’t know enough about accessibility. So they copy some toggle code from the internet, and then that’s what their users get. And that’s often completely inaccessible to screen readers and other assistive technologies! The effect being that the toggle is unreachable for them, or not possible to activate even if they reach it. Unhelpful colors Because the toggle is known to be confusing, designers add colors to help clarify! That’s generally a good thing. But it’s not enough! 8% of male users have red/green color vision deficiency. That means it’s not much help for them using green as “on” and red as “off”. And, again because a toggle is not really a thing in HTML, designers can decide to use any look-and-feel, since they’ve made this component up and there is no “built in browser version” of it! Can you guess what the status is of this little gem I found? Well, when you have red as your company’s profile color – red means “ON”. Obvious – right? Making it easy for internet users to learn how to use this fancy toggle thing – right? …sigh Some designers make it darker on activation, some make it lighter! Some use gray as “off” – but also as “on but disabled”. Even the digitization agency in Sweden, who are supposed to make sure others follow the accessibility guidelines, have this terrible color scheme on their cookie toggle with hardly any perceivable difference in color: And even when colors are perceived and understood (“green = on”), there is still cognitive confusion; is this green color a status or an action? Is this an on-button or an on-status? It cannot be both! We can get guidance from WCAG point 1.4.1 – “don’t rely on only color to convey meaning”. And you know who doesn’t rely at all on color to convey meaning? Checkboxes don’t. Radio buttons don’t. Just say’n. Are there any situations where toggles are OK? Yes! The main problem is understanding the current state – so if the state is obvious to the user for other reasons – a toggle can be cognitively OK. As long as you make sure it’s accessible! Here is a toggle for filtering on Airbnb where a toggle button limits the amount of available houses. Users can understand by the reduced amount of houses that the filter is active, even if they don’t understand the toggle control. The number in the button is physically close to the toggle control, and many users will notice the change as it happens and draw the correct conclusion from context. Users using zoom tools or screen readers may still miss it though, so make sure to test for that! For multiple possible values that are mutually exclusive, a “toggle button group” can be effective. Especially if the state can be understood also from context! A good example is the “justify text” options in Google Docs: Having multiple mutually exclusive options means the active option is obvious, since it’s the only one with a different look from the others. It would not be as obvious if there were only two options: Which one is active? The user can also instantly see how the text moves around to become centered or left adjusted, so context allows users to understand the state even if they would not understand the icons in the control: Just don’t use it for 2-option settings: Personally, I think the “Ja” (yes) looks pressed “into the website”, so it should be active, just like the buttons on an old radio: Of course – again – I was wrong… The “toggles have instant effects” fallacy So you’ve heard about this huh? I understand, I mean it’s in the top results when you search “when to use toggles”, and even promoted by my heroes at Nielsen Norman Group https://www.nngroup.com/articles/toggle-switch-guidelines/. The claim is that “Toggles inform users that settings have immediate effect while radio/checkbox inputs will be followed by a submit button”. Let’s first assume this statement is correct (it isn’t). Let’s say 100% of users believe that toggles have immediate effect, that checkboxes and radio buttons cannot have immediate effect, and that 100% of websites use them that way (they don’t). Then by adding a toggle you will effectively have users who know something happened instantly when they pressed the toggle. But many of them still have no clue what happened. Congratulations! Now let’s prove it’s not even true! You’ve already seen how Amazon and Slack use buttons and radio buttons with immediate effect. There are countless examples of websites doing the same. Even the big ones! Here is a settings page in Windows 10 where all settings have immediate effect. Both the toggle and the checkboxes. No “submit” button anywhere. So how can you claim that every user knows that checkboxes and radio buttons are always followed by a submit button, when even Microsoft’s Windows teaches them otherwise? Next, almost every cookie manager uses toggles followed by a submit button like “Save & exit” or “Submit my preferences”. And another one: And another one: So how can you believe that all users will know that toggles have an instant effect, when every cookie manager in the world teaches them otherwise? This idea is simply not true! And there is nothing code-wise that would motivate this belief! Remember, toggles are not a thing in HTML, so they are often coded as a checkbox, button, or radio button under the surface. So whatever you can do with a toggle, you can also do with those HTML elements! Recommendation Just use a checkbox or radio group! It’s quick to implement, accessible from the start, and doesn’t make the user think. If you want to save the setting instantly – then do so! And inform the user either by making the effect obvious from context, like changing colors of the interface immediately when the user checks “high contrast mode”. If no visual or obvious effects exist, then inform the user with a toast or status update message like “setting updated!” or a loading indicator with the text “saving…” like Google does: If users complain about the design (unlikely) or your design lead or boss demands a toggle at any cost (more likely) then follow this advice: Don’t do it! But if they insist… Prepare to spend (waste) a LOT more time than you think to get this right Make the current state obvious from context Place the toggle close to what it affects Don’t add a state label into the clickable button itself, as it may be interpreted as an “on-button” instead of a “button that is on”. Don’t rely on color Don’t assume everyone thinks “right = active” Test the accessibility, preferably together with users with disabilities Read up on accessibility and follow the linked articles Summary This table sums up the topics in this article: I’ll leave you with this “great” example from an anonymous Swedish ferry company, where I still to this day have no idea what I have selected. Toggles suck! Feel free to tweet us at @AxessLab and share your own examples of confusing toggles! Or let us know why we’re wrong! Screen reader quick guide Joel Holmberg — Wed, 01 Feb 2023 13:57:22 +0000 Looking for a free quick guide, a “cheat sheet” or a “one pager” for screen reader testing? You’ve come to the right place! There it is! Or an image of it at least, the actual document is linked further down. So why did we create this? We meet teams every day who are new to digital accessibility. Teams who need to start small and learn how to test their software using some basic assistive technology. Most guides are in depth and it’s hard to know what parts to focus on if you are a beginner. This document attempts to solve that! It describes the simple commands that let you find the absolute majority of accessibility issues, without having to know much about the ins and outs of screen reader usage! The one we show here is for Windows Narrator, but of course we have one for JAWS, NVDA, VoiceOver and Talkback too. Let us know and we can send one over, or get them all in our bundle of checklists! This checklist and others like it are part of our checklist-bundles that we offer any organization who just started their accessibility efforts, and who need a quick and simple kickstart! They include to-the-point, one page checklists like: Screen reader cheat sheet Browser settings cheat sheet A11y checklist – front end developers A11y checklist – UX-designers A11y checklist – text & language A11y checklist – content and media A11y checklist – legal (EU) A11y checklist – legal (US) All designed to be a first simple step and get your team going! We know checklists are not a final solution to true inclusion in software development or long term digital accessibility work! Testing with real users is probably the most important thing to make sure everything works, which you can read about in our article User testing with people with disabilities. You can also contact us to get help with accessibility audits, accessibility training and more. With that said, we believe there is a time and place for checklists like these too! Enjoy Quick guide for Windows Narrator Quick guide for VoiceOver on macOS Text transcript of the checklist Screen reader Windows Narrator Start / quit Ctrl + Windows + Enter Next / previous item Caps lock + arrow key right / left Next / previous clickable item Tab / Shift + Tab “Click” Enter / spacebar Scan mode on/off Caps lock + spacebar Next / previous landmark Scan mode → “D” / Shift + “D” Next / previous header Scan mode → “H” / Shift + “H” How do I test? Close your eyes or turn off your monitor! Do you find your way around the UI, or do you get lost? Are there landmarks and headers where you expect them? Can you complete normal use cases without looking? NOTE! Scan mode sometimes activates automatically so if the commands above don’t work, inactivate scan mode! Psst! Ctrl = Stop talking 143.75% font size sucks Hampus Sethfors — Wed, 16 Mar 2022 11:48:40 +0000 Interacting with our fan base is a fulfilling part of my job. Yesterday I got a request to write an article on why the font size on this site sucks. So let’s not waste any time and get straight to it! The humble request Nice font size 143.75% on that page. Maybe next they’ll have an article about why that sucks. This graciously worded request was actually not sent directly to me, but to a fellow accessibility guru Nicolas Steenhout, who forwarded it to me in this tweet. TFW a client asks about disabled inputs, and as part of the conversation, you send a link to "Disabled Buttons Suck" by @hampelusken (https://t.co/u8vAmxxbZN) and the response is… #a11y pic.twitter.com/PRnxtnjxlQ — Nicolas Steenhout (@vavroom) March 15, 2022 So sadly I don’t know who this mystery fan is, but I’ll write this article, and like a message in a bottle I hope it finds its way to you somehow! Why our 143.75% font size sucks 1. Your eyes don’t get the training they need Having a font size that’s too easy to read is like lifting 100 gram weights at the gym. Your eyesight, like your muscles, need to be challenged to become stronger. A large font size isn’t challenging to anyone, not even people with low vision. So nobody is getting the training they need, not even people with disabilities. #abelism 2. Large is not as aesthetic as small Look at this tiny painting: Super impressive right? So much better than if that same painting had been on a regular sized canvas. This obviously also applies to letters on a webpage. Smaller letters are more impressive than larger ones. Simple logic. And we all know that users mainly visit webpages and read articles to experience beauty. Ergo large fonts suck. I suggest pausing this article to browse the Pinterest page All things miniature for about 30 minutes, and then returning. Welcome back! 3. Font size isn’t a requirement in WCAG The Web Content Accessibility Guidelines (WCAG) is the holy grail of accessibility. And surprise, surprise, WCAG doesn’t include a single success criteria on font sizes! That means that font sizes don’t matter to anyone because WCAG contains every single important consideration when it comes to accessibility. You can make font sizes 1 px. As long as they have good contrasts, anyone will be able to read them. It’s just like people running around thinking that making interfaces intuitive and testing them with real users would somehow be important for accessibility reasons. It’s not in the WCAG so it’s not important. Glad we got that sorted out once and for all. 4. 143.75 is a stupid number Who specifies font size with two decimal places? That’s just dumb. Also, it’s hard to remember such a long number for the programmer who writes the CSS code. This discriminates against programmers with memory impairments. #abelism 5. Other crappy sites use large fonts CSS-tricks, IFTT and A list apart use font sizes that are in the same ballpark as the ones on this site. They, like us, know nothing about usability or web design and are shooting themselves in the foot with this poor choice of font size. 6. Relative font sizes let users control too much Having your font sizes in relative units like %, EM or REM, instead of absolute units like pixels, makes it possible for users to adapt the font sizes as they wish. This jeopordizes the whole look-and-feel of the site. Users don’t know what makes a site look aesthetic, and shouldn’t be given the chance to mess it up. It’s like giving everyone who visits the Picasso Museum a paint brush, and encouraging them to adapt the paintings if they don’t like them. Picasso is the expert in paintings, not the museum visitors. Programmers are experts in web design, not the site visitors. I could go on forever… But I think you get the point! So thanks for the great article suggestion and hope this was what you were looking for. And just for legal reasons, this is a joke. We think larger than normal fonts are quite great! If you liked this article… You might also enjoy: Disabled buttons suck How icons are ruining interfaces Fonts don’t matter Testing is a scary word Hampus Sethfors — Mon, 24 Jan 2022 13:03:40 +0000 Can you keep a secret? Here’s why you should keep testing your product with users, but not say that’s what you’re doing. Basically – how to test with users without anyone knowing! There has been some discussion in the UX community the last few years on what to call the activity that’s arguably the most important one in the UX-toolkit. Ten years ago basically everyone said “user testing”. Then someone thought: Hey! We have a problem with users feeling uncomfortable being tested. Calling it user testing makes this worse! A great observation indeed. But the solution – in my opoinion – not as brilliant: Let’s switch from user testing to usability testing. The idea is to point out that we’re not testing the user, we’re testing the usability of the product. But the problem is that the word “test” is still there… Ponder a while on the word “test” What comes to mind? Maybe you work in the tech sector, and you think of all your awesome colleagues in the testing department. But if you consider what other people might connect to the word “test”, or think back to when you were in school, you probably realise that test usually is a scary word. Tests in education can involve grades, disappointment and mental blackouts Tests in sports can involve a lot of sweating or running until you puke Tests in recruitment processes can involve tough questions and a fair bit of anxiety Tests in healthcare can involve long needles – or worse! All-in-all, the word test is probably negatively loaded for most people. Now let’s take an accessibility perspective At Axess Lab, we constantly urge people to involve people with disabilities in the design of products. It’s awesome for a bunch of reasons that we’ve listed in the article: Skip the WCAG! User test with people with disabilities instead. But if you’re asking users with disabilities to join a “user/usability test session”, you’ll probably invoke even stronger negative feelings than with others. Why? Well, society is still really inaccessible and discriminatory. Many people with disabilities: have a lower success rate in tests in sports and education, due to the tests being inaccessible, the training poor, the opportunities fewer and so on. have a lower success rate in recruitment tests, due to recruiters being abelist, recruitment processes inaccessible and so on. dislike healthcare tests… I could go on for ages in that last healthcare bullet…but let’s just agree on that – at least historically – people with disabilities have been treated terribly when it comes to tests disguised as healthcare. So if you’re aiming to get input from a diverse audience, the word test is probably not the best one to use. What to say instead So whether you call it user test or usability test, the people you’re trying to recruit probably hear the word “test”. Let’s consider some options that are less likely to invoke stress and anxiety for the users you’re trying to recruit: “We’re looking for feedback on our product…” “We’d like your opinion on our design…” Then you can go on to explain what the session is about. Like: “We’re looking for feedback on our product. Would you be willing to meet with us – either in person or on a video call – where we show you a work-in-progress, ask you to walk through it and tell us what you think? It’ll take around 45 minutes and you’ll get $60 as thanks for your time.” It’s so much more likely that people will find this description more enticing and less scary than if they’re asked to be part of a test. But it’s not correct! If you’re in the UX field, you might think that calling usability tests something like feedback session is incorrect. “There’s after all a big difference between asking for users’ opinions/feedback and a qualitative usability test!” And you’re completely correct. I’m not saying we must change the term when we speak amongst each other in the field. All I’m saying is that we shouldn’t use the same language when we recruit or talk to the users. When I’m at the dentist, there are usually two dentists in the room, and when they speak to each other I barely understand a word. It’s like: “11-3 bilateral dust CDS”. Then one of them turns to me and says: “Everything looks fine, we’re just going to make your teeth a bit whiter with this brushy thing.” And I’m completely fine with that. The dentists use their own terms and jargon when speaking to each other, then translate that to non-dentist language when communicating with me. So keep saying usability test, user test or whatever when talking to others within the tech field, but as soon as you’re inviting others to join these sessions, keep the word test a secret! If you liked this article… …you might also enjoy these: The foot-in-door-somersault-strategy. Making accessibility laws your superpower Disabled buttons suck Seven tips for user testing with users with disabilities What’s new in the European EN-standard update from 2.1.2 to 3.2.1? Hampus Sethfors — Tue, 21 Dec 2021 15:40:23 +0000 In the EU, the laws on digital accessibility for the public sector all point to a standard called EN 301 549. It’s been updated, and here in Europe a lot of people who work with web sites and apps are asking what this means for them. Most news are probably not relevant to you If you work with web or apps – which most people who read this article probably do – I’d say about 95% of the update is completely irrelevant to you. Instead it affects other types of ICT (information and communication technologies), like: Two-way voice communication, like intercoms Software, like if you build Microsoft Word Tactile buttons on physical devices, like ATM:s and ticketing machines People generally forget that the EN-standard aims to cover all types of digital products, so just a part of it is relevant for web and apps. If you work with the web I’m not going to walk through all the changes that relate to things other than web or apps. You can read about those yourself in the documents linked in the end of this article. So lo and behold! Here are the relevant news regarding the web! PDF:s and other documents that users download are now covered If you publish a pdf-file or other document as a downloadable file on your site, those now also need to be accessible according to the law. “Is this really news?” you might ask yourself. Yes, there seems to have been a loophole in the law, where the only types of documents covered were “documents that are web pages” and “documents that are embedded in web pages”. Now they’ve added “documents, including forms, that are downloadable from web pages but are neither embedded nor rendered together with the web page from which they are provided”. So basically, everyone – including me – probably already thought the downloadable documents were covered. They were not. But now they are. Nothing really changed in practice, but a loophole was covered. Come to think of it, it’s actually nice to have a clarification that documents include forms! So if you build forms in Word or pdf:s the law affects you too. Subtitles need to be “styleable” and “speakable”, but not really..! Two new requirements affect subtitles/captions. They are: 7.1.4 Captions characteristics: “Where ICT displays captions, it shall provide a way for the user to adapt the displayed characteristics of captions to their individual requirements, except where the captions are displayed as unmodifiable characters. Defining the background and foreground colour of subtitles, font type, size opacity of the background box of subtitles, and the contour or border of the fonts can contribute to meeting this requirement.” 7.1.5 Spoken subtitles: “Where ICT displays video with synchronized audio, it shall have a mode of operation to provide a spoken output of the available captions, except where the content of the displayed captions is not programmatically determinable.” My first thought was: “Great! This means subtitles burned into the video are not allowed, because only subtitles created with the standard formats can be spoken and adapted.” But then I read the “except”-part a bit more closely. And the exceptions basically seem to say that if subtitles are burned in, these requirements don’t apply. So to my understanding, nothing has changed for video creators. But if you build video players, or are deciding which video player to use on your site, you need to take this into account. Very nitty-gritty-specific-cases There are a lot of small additions to very specific cases relating to websites. Let me take two examples: If your site has a way to activate specific accessibility features – which usually is a bad idea in the first place – you need to have a method of activating this feature “without relying on a method that does not support that need.” So my interpretation is that if you have a high contrast mode, that activation button needs to be high contrast. Or if you have a screen reader friendly mode, you need some kind of shortcut that’s announced to screen readers to activate it. If your site has two-way voice communication features – like support call embedded in the website – there are a bunch o requirements about having real-time texting, speaker identification and so on. There are a few more like these. If you’re interested in all these specific “edge-cases”, go to the heading “Requirments in EN 301 549 and relevant to the WAD, but not in WCAG 2.1” in this article: Latest changes to accessibility standard (europa.eu) Check out the documents If you want to check out the updates for yourself, here are the two versions of the standard: New version: EN 301 549 v3.2.1 (pdf on etsi.org) Old version: EN 301 549 v2.1.2 (pdf on etsi.org) Also, the article on europa.eu that I linked to earlier is a more formal summary than this article. Here it is again if you want to dive deeper: Latest changes to accessibility standard (europa.eu) I may have missed stuff Here are some necessary disclaimers! I’ve done my best to compare the two versions, but I may have missed stuff. The document is around 200 pages long, and I’m not a lawyer. So don’t use this article in court. See it as a regular accessibility guy telling the world, in plain language, what he understands the updates to be. If you find something I should add or change, get in touch and I’ll update the article: [email protected] or @hampelusken on Twitter. Thanks EU Even though this update wasn’t a game changer, we in the a11y (short for accessibility) community are thankful for all the great work the EU does to lift this important topic! If you liked this article… you should check out these ones as well: The foot-in-door-somersault-strategy. Making accessibility laws your superpower What is a screen reader? Disabled buttons suck Accessible datepickers The foot-in-door-somersault-strategy. Making accessibility laws your superpower Hampus Sethfors — Mon, 04 Oct 2021 07:57:20 +0000 Accessibility is exciting, user-centered and should make you jump out of bed each workday morning with a proud grin on your face. Accessibility legislation is boring, text-centered and makes you snooze your alarm at least four times before getting up. But let’s see how to use the boring laws to get to do exciting, high impact work! The cool kids on the block You know all those movies where the main character first is a nerdy nobody and transforms into someone amazing or popular? Sandy in Grease. Peter Parker in Spider Man. Harry Potter. You get the point! That’s kind of how we feel like at the moment in the accessibility (a11y) community. A few years ago, only dorky public sector organisations wanted to hang out with us. Suddenly, now we’re at the cool table with people from industries like gaming, e-commerce, fashion and entertainment! And. It. Feels. Great! We actually owe a lot of this new found coolness to something quite uncool: accessibility legislation. Here in Europe at least, we’ve had some awesome new legislation the past few years, and more is on the way in the years to come. This has really put accessibility on the radar. Suddenly we – the a11y nerds – are invited to red carpet events and everyone wants to talk to us. Thanks politicians! However, when we start talking, most of the cool kids want to talk about how not to get in trouble, while we have much more interesting things to discuss! The regular starting-in-the-wrong-end-strategy Most organisations approach accessibility from a legal standpoint and begin asking things like: How do we avoid getting sued? What’s in the Web Content Accessibility Guidelines (WCAG) and what’s the lowest acceptable level we need to reach? Can we get a list of issues so we quickly can fix them and get our “accessibility approved” stamp? Is there a plugin we can buy that makes our site compliant with the law without us having to do anything? How do we get a top score from automatic testing tools that we can brag about to top management? This is a poor, counterproductive way to approach accessibility and inclusion. Having people who are new to accessibility learn about it from the WCAG is like me teaching my baby to walk using my university physics book. All the theory is in there, but it’s a bit too much to digest at the moment. We should aim to find another way to approach accessibility, and a great source of inspiration is looking at the methods of the user experience (UX) field. Both UX and a11y are about understanding the interaction between humans and technology. But even though there are some checklists and heuristics in the UX field, if you ever worked seriously with it, you know there’s a much bigger focus on methods instead of checklists. Methods to do user research, methods to test prototypes with users and so on. So how do we get the accessibility field to shift focus from checklists to methods? Especially now when the laws point to standards – which are essentially fancy checklists with a bunch of different criteria. The new foot-in-door-somersault-strategy The key is actually to use the boring accessibility laws and regulations! They are a great way to get your foot in the door to the board room and management meetings. Where the allocation of resources like time and money are decided. Epic super crucial step! However, once you’ve used legislation to get in there, it’s time for the foot-in-door-somersault-strategy! Let’s walk you through a hypothetical scenario: “Alright, you’ve convinced me” the CTO tells you. “We need to do this accessibility thing. How do we go about it?” Your instinct might be to say: “Well, there’s an accessibility standard called the WCA…” But let’s stop you right there! It’s time to turn this conversation on its head. Take a deep breath, and get ready to somersault. Instead of talking about the exact requirements of the law, say something along the lines of: “I’ll tell you exactly how!” Pause for tension to build up. “We just need to make some small adaptions to our current processes, making sure accessibility is baked into them.” “That sounds both easier and cheaper than making a big, separate accessibility project!” the CTO exclaims. “Which processes and how?” “Well, maybe most of them in the long term, but a good starting point is to include users with disabilities in our user tests. We’ll start with screen reader users, since a lot of legislation covers that target audience. We can also add accessibility training as part of our onboarding program, and workshop with some of our teams on how we can sprinkle some accessibility into our current working processes!” “Hey, you really do seem to have this thing covered! But just to make sure, is this really what the law tells us we need to do?” “By approaching accessibility this way, we’ll create a way of working where we comply with the law in a sustainable way. We’ll take small inclusive steps, everywhere, all the time. Continually improving instead of making this a one-time project. That also happens to be human-centered, more impactful, less expensive and really fun for our teams!” Bam! Instead of going back to your computer and setting up a spreadsheet with each WCAG criteria, you’re set up to recruit people with disabilities to user testing, adapting training courses and booking workshops with your colleagues. Somersault done and you’ve just changed the ball game completely! Recap! The strategy in three simple steps Use laws to get your foot in the door of important meetings Somersault and talk about methods when you get asked how to comply with the laws Smile as you work with accessibility in an exciting, high impact and user centered way! Good luck, have fun! Parent accessibility Hampus Sethfors — Wed, 11 Nov 2020 14:55:09 +0000 I’m a dad since a few weeks back. This means I spend my days trying to keep a tiny, helpless lump of life alive. Scary stuff! I’ve also realised that this dad-thing comes with a ton of accessibility needs. First a short future message to my kid… Hi kiddo! If you find this post in ten years time or so, I’m sorry for the negative tone. I love you very much! But I’m tired and want to make a point about inclusion. Hope you understand! Look! No hands! The image above shows how my newborn master wants to be carried a large portion of the day. Apart from losing access to one or both of my hands, this type of carrying around is very boring. The thing is – my newborn is very irrational. When carried, he rarely allows me to bend my legs 90 degrees and sit down. He wants me to continually walk around. So watching Netflix from my sofa is out of the question. But my entertainment-craving brain has figured it out! I still have access to my voice. So I’ve activated the accessibility feature Voice Control on my iPhone. When my headphones are connected I can open my audio book or podcast app and press play, just using my voice. Even though I’m an atheist, I find myself praising the Lord for this accessibility feature primarily meant for people with permanent motor impairments. Here’s a demo of this in action. First in an accessible app BookBeat, where buttons are properly named and I can start the book by saying “Tap listen”. Then in an inaccessible app, where buttons have strange names, and I need to say “Tap Mini Media Bar Play” to start the book. Another handy voice interface is my home assistant, that I can ask to dim the lights and play lullabies on Spotify, to increase the chance of the baby finally falling asleep. I also have this amazing thermos that can be operated one-handed, which gives me the superpower of filling up the kid’s bottle while holding him at the same time. Here’s a clip of me opening and closing it just using my left hand. The lack of motor abilities for parents is a classic example of a situational disability, included in most introductions to accessibility, like Microsoft’s inclusive design toolkit: But I’ve realised that becoming a parent means more impairments than just the access to my arms… Other parent disabilities 1. Sleep deprivation I was expecting to lower the number of hours of sleep each night. But I was not prepared for all the times I have to wake up during that period. Having a shorter, more fragmented sleep has lead to my brain feeling like an old, uncharged Nokia 3310 phone. Slower, lacking memory, low on energy and just simply unable to do a lot of the stuff most modern brains can. That’s why parent brains need intuitive, lightweight interfaces with good error handling! 2. Swollen, numb hands This one only affects me indirectly, but it’s very frustrating. My wife got this thing called Carpal Tunnel Syndrome – a super annoying, and common, condition that affects a lot of mothers during and after pregnancy. She explains it like the numbness you get after sitting on your hand for a long period of time. Except she gets it after any use of her hands for a few seconds. So cooking, eating, changing diapers, typing, scrolling on a smartphone – all activities that lead to numb, swollen, pulsating and hurting hands. It’s been going on for over 10 months now, and my wife actually needs surgery to (hopefully) fix the issue. Again, many accessibility features that support people with permanent motor impairments – like voice control, auto completing forms and similar – have been really helpful. 3. A ticking baby bomb I didn’t know this, but babies can apparently switch from a state of deep, relaxed sleep to screaming like it’s the end of the world in less than a picosecond. That means, as a parent, I never know how much time I’ve got before I have to drop everything I’m doing and, instead, do everything in my might to comfort the kid. So if I’m in the middle of something, like filling in some important form online, it’s super annoying if there’s a time limit that kicks me out if I’m idle for a few minutes. Which happens to be something that’s covered by the WCAG (Web content accessibility guidelines), because time limits don’t just hurt parents, but loads of people with permanent disabilities too. 4. Baby attention deficit Harp seals take care of their offspring for 12 days, then they’re fully able to care for themselves. Sadly, human babies are not as low-maintenance. Human babies are completely helpless for what, 12 years or so? Maybe a bit less, but still far longer than 12 days. I’m so jealous! This huge responsibility of keeping a helpless human alive and well leads to a big portion of my brain – that earlier could be used to solving all sorts of interesting, important problems – being blocked up with questions like: Is the baby breathing? When was the last time he pooped? Why the hll can’t I find any of his 242 pacifiers? Do I really need to shower again after him vomiting all over me or can I just pretend it didn’t happen? So I spend my days with a large attention deficit and cognitive impairments, which is amplified in combination with point 1 and 3 above. 5. Hearing loss at night I got a ton of advice before becoming a parent. The best and most genuine one was from a father of four: Never wake a child that’s sleeping So when the baby is sound asleep, and all I’ve got energy for is to crash in the sofa in front of Netflix, I’m super thankful for the closed captions that makes it possible to watch with little or no sound. Minimising – although by no way eliminating – the risk of point 3 going off. Parent friendly design To sum up: accessible design is parent friendly design. So the next time you manage to make an accessibility improvement to your product, pause for a moment, stay completely silent and listen very carefully. You should hear millions of parents thanking you for your efforts. If you liked this post, you might also enjoy these I used switch control for a day Hand tremors and the giant-button-problem What is a screen reader? Takeaway apps: Do they deliver accessibility? Josefin Wessman — Thu, 23 Apr 2020 11:30:40 +0000 The world has changed due to Covid-19. A lot of people are in quarantine, voluntary or involuntary. Shops and restaurants are closed or have new rules to restrict crowding. One way to support local restaurants is to buy prepared meals in takeaway apps. But, how are these takeaway apps in terms of accessibility? Our 5 top tips for more accessible takeaway apps! The overall idea of a digital service to deliver food to your house is very inclusive, and at Axess Lab we love it! But for the idea to work it also has to be implemented in an accessible way. So we decided to pick three of the larger takeaway apps in Sweden: UberEats, Foodora and Karma and test them out. From that experience, we give our tips to these types of app services to help them become more accessible: Tip 1 of 5: Make sure color contrast are good A common issue in these apps is that text and background colors are too similar in contrast. According to the Web Content Accessibility Guidelines the ratio between these color contrasts must be above 4.5:1. Which they often are not in these apps. Poor color contrasts are an issue for users with low vision and users that look at the screen in harsh lighting conditions. This is often the case when you use mobile devices, especially outdoors. Here are some examples of text with too low contrasts that we found in the apps: Make sure to check all your contrast values and aim to be well over the limit of 4.5:1. Especially since these are apps that are being viewed on small screens. If you need testing tools, check out these Top seven free color contrast checkers & analyzers. Tip 2 of 5: Combine icons with descriptions The screen space is smaller in apps than on desktop. Therefore some functionality is only presented with an icon.Icons are great in combination with text descriptions but on their own they can be confusing and users often find it difficult to understand their meaning. For instance in the header of one app we tested we found these icons that represent two buttons. But, what do the two icons mean? The user has to explore in order to understand the meaning of them. Keep in mind that some users are careful in their approach to technology and don’t want to click on things to find out what they do. The icon to the right in the image above is the checkout where there currently are two meals. The icon to the left looks like a user profile but opened some kind of menu with random actions like “settings”, “contact us” and “invite your friends”. Don’t make the users guess what different objects are for, explain it in short descriptions. If functionality is difficult to describe, it might be a sign that you should organize the content in a more logical way. If you want to learn more about icons and proper descriptions to them, check out our post: How icons are ruining interfaces. Tip 3 of 5: Make sure your buttons and links work with screen readers The apps we tested generally did not work well with screen readers. A screen reader is an assistive technology, primarily used by people with vision impairments. It converts text, buttons, images and other screen elements into speech or braille. In these apps, buttons and links often lack descriptions in the code for the screen readers. In the example below, the screen reader was unable to find the register button. So the user we tested this with couldn’t even enter the app and as a consequence couldn’t order any food. In other cases, the buttons leading to the checkout are impossible to understand. In the example below, the button leading to the order checkout had “view your cart” as a visual label but was read by the screen reader as the less helpful: “button”. In some cases there where descriptions read by screen readers, but they were not very understandable. Such as this icon where the screen reader said “Tablist over icons”: Or this icon that had the description ”Navdown”: This video clip shows a page with several buttons and objects that are not properly described, in Swedish: So, make sure to test the app with a screen reader during development. Today, screen readers are built into smartphones so everyone can test it. If you’d like training from our colleague who’s a screen reader user himself, just let us know at [email protected]. Besides testing it yourself, make sure to test the app with real screen reader users to know what to prioritize. The real user’s opinion of the overall experience is what you should to focus on, after all. As a good example, one of the apps had implemented helpful descriptions to screen readers on objects that visually was just an icon. For example the dollar sign in the following image was described by “Price: average or below”. This video clip shows how it is read by a screen reader, in Swedish: Tip 4 of 5: Reduce content For many users, large amounts of information, both in terms of text and non-text content, can be a deal-breaker. So it is always a good idea to minimize content and focus on what is most valuable. Clean interfaces are especially important for users with cognitive disabilities. In some of these apps we found that there was too much content. That makes it difficult to distinguish what information is primary. Especially for users that have difficulties with maintaining focus or who finds it energy-draining to read. Here is one example of a checkout that was cluttered with information: It has small text and lack clear headings and spacing in the presentation. Some information could benefit to be placed in later stages so the user can complete the checkout step by step. The payment method for example is not really relevant until the user decides to order. Tip 5 of 5: Test with users! In order to achieve an inclusive design it is fundamental to test with real users. Real users have a wide range of abilities. Focus on users that have the most difficulty in certain areas to find improvements that are beneficial to all users. For example, tests with users with cognitive disabilities to understand UX issues in terms of cognitive load. Test the technical aspect with users that use different interaction methods, such as screen reader or voice input. When testing with users the goal should be to find out if they can complete the process. Not just certain steps or objects. The user must be able to complete the whole process to be able to place an order. Need help with user testing? Let us know, we do a lot of user testing! Also available as a remote service, during corona-times. You can do it! In conclusion, take small steps in several areas towards the goal of including more users. You can accomplish a lot by taking an interest in the users’ needs and by learning what accessibility really is. Let us know if we can help you in your mission! Thank you for reading this blog post, take care, especially these days. Neumorphism – the accessible and inclusive way Hampus Sethfors — Thu, 09 Apr 2020 08:38:51 +0000 There’s a new kid in design town: neumorphism. It’s predicted to become a big design trend ahead. Let’s look at what neumorphism is, the potential accessibility pitfalls and how to use it responsibly. Neu…what now? Neumorphism is a fancy word for a user interface design trend. It derives its name from skeumorphism – a way of integrating real-world objects into user interface design. The classic example is the trash can. Neumorphism is basically “New Skeumorphism”, so skeumorphism with a modern twist. It’s got a bit of a “soft” look and feel that reminds a bit of flat design. For a good in-depth article on neumorphism, check out: Neumorphism in user interfaces (uxdesign.cc) Anyway, it’s causing quite a hype in the design community at the moment, which was sparked by a design created by Alexander Plyuto, posted on November 5th, 2019 on the design community Dribbble: This design went viral, with over 220 000 views and 4000 likes. It also set off a whole bunch of designers who had a shot at the new design technique. Here are some of the most popular designs to date on Dribbble: You can find a lot of more designs on Dribbble with the tag Neumorphism. Hey look, we’re trending! Many people are pretty excited, predicting neumorphism to be a big trend ahead. https://twitter.com/LudusEstArs/status/1215243113247232001?s=20 https://twitter.com/webwide_io/status/1208763520424304643?s=20 Gary Simon, who has half a million subscribers to his Youtube channel DesignCourse, made a tutorial video named Could this be the BIGGEST UI Design Trend of 2020? #Neumorphism. Could this be the BIGGEST UI Design Trend of 2020? #Neumorphism – https://t.co/FvYFwMTodA pic.twitter.com/tZMTzloEnO — Gary Simon (@designcoursecom) December 23, 2019 The great thing about Gary Simon is that, even though he’s not an accessibility expert, he always has accessibility in mind and regularly talks about the importance of inclusive design. Like in the video above, where he mentions the importance of color contrasts. Which leads us perfectly to… The potential problems with neumorphism The main problem with this trend are the poor contrasts in almost every design out there. As you probably noted when scrolling through the neumorphism designs above, most of their color schemes are very light grey on white. Many of the interface elements are barely possible to see, even if you have perfect vision. Now imagine what this does for someone using their device in sunlight or users with vision impairments. Let’s use the disability simulator Funkify – a browser extension that we are proud to have been a part of creating – to view the original design through a low vision filter: Even though you can still glance much of the text and icons, it’s still quite frustrating to barely be able to identify any of the interface elements, like buttons, cards and charts. Neumorphism is often referred to as “soft UI (user interface)”. Looking through the designs on Dribbble, it would almost be better to call it “ghost UI”. Apart from the contrasts, two other accessibility issues are: Lack of labels. Many of the designers seem to remove labels for icons when having a go at neumorphism. Maybe because they’re doing all they can to create a soft, stripped off interface. Icons without labels is something that hurts both the accessibility and usability of interfaces, which we’ve written about earlier in How icons are ruining interfaces. Understanding what’s clickable. Users should not need to guess what is clickable and what is not. This is extra important for many elderly users, who will often avoid clicking things that they are not totally sure are clickable. This is the same problem flat-design battles a lot. Get out of your bubble Yesterday, an 80-year-old man told me he was stressed. He’d been trying to understand how to pay for parking his car on the street outside here in Stockholm, Sweden. He tried really hard but could not read the text on the parking machine interface, not even with his reading glasses on. He ended up getting a 750 kr (80 dollars) fine. I believe I’m speaking for most people in this world when I say: we don’t need less legible interfaces. We should go in the other direction. Judging by the designs on Dribbble, the world’s top designers don’t agree with me. So it’s time to get out of the designer bubble and realize a few important facts. Most people in this world are not young, tech-savvy with perfect vision. Most people don’t experience your interface on 32-inch ultra HD monitors. And you might want to sit down for this last one: most people don’t even care much about how your app looks. They just want to get something done. And to do that, they need to see what’s on the screen. Even if they’re out in the sun. Or use a small, old phone. Or have low vision. Is accessible Neumorphism possible? Definitely! There’s nothing in neumorphism that forces designers to use light grey on white all over their designs. Or that prohibits text labels by icons. In fact, many of the dark mode designs on Dribble are much better (although not perfect), like the dark version in this one. Here’s another dark design where contrasts are better. And I even found a bright with okay contrasts – although the borders around the buttons could be made clearer. So if you’d like to design accessible neumorphism, make sure to comply with the Web Content Accessibility Guidelines (WCAG 2.1) criteria on contrasts. Specifically this one: 1.4.11 Non-text contrast. It basically requires icons, borders and other interface elements to have contrasts of at least 3:0:1. It’s a bit lower than the requirement for text content, which needs a contrast ratio of at least 4.5:1. Here are some great free tools you can use to measure contrasts: Top seven free color contrast checkers. In addition to sufficient contrasts, make sure that your design makes it clear what’s clickable and that you label your icons. Then you’re all set! Wrapping up The overall goal of creating a soft and clean interface is super positive from an accessibility point of view. Especially when you consider all the users with cognitive impairments who are extra sensitive to cluttered designs. This could be users who are stressed, tired, are on the autism spectrum and so on. To go all the way, and make neumorphism really inclusive, make sure that: Contrasts of text is at least 4.5:1 Contrasts of button borders, icons and other interface elements is at least 3.0:1 It’s easy to understand what’s clickable Icons have text labels. Then you’ll have done your part to steer this design trend in the right direction! If you liked this article… You may also enjoy these: Trends That Exclude How to make your site accessible for screen magnifiers Disabled buttons suck Becoming a climate positive company Joel Holmberg — Thu, 16 Jan 2020 16:21:19 +0000 At Axess Lab we strive to make the world more accessible for people with disabilities. But what’s the point of an accessible world if we can’t survive in it? 2019 was the year where 16 year old Greta Thunberg helped make the environment the number one issue on peoples mind. The media primarily focused on countries and their politicians. Conscious individuals tried to do their part in reducing emissions by flying less, eating less meat etc. Here in Sweden “flight shame” and “shop shame” become new words. But the largest environment impact come from companies, and as a company we have an important part to play in creating a sustainable world! Company footprint All businesses have an impact on our environment. It’s easy to see that if a company produces and sells goods they use raw materials and they use energy to transform them into products. You may even see the emissions with your own eyes coming from industrial chimneys and factories. But for companies selling services, or software companies like ourselves it can be more difficult to see where the environmental impact comes from. We decided to learn what it would take for us to become a climate positive software/consultancy company, and we want to share it in this short article! To become climate positive we needed to answer a few questions: 1. What is our organization’s yearly emissions – our ecological footprint? 2. What actions can we take to reduce this footprint? 3. How can we compensate for the remaining emissions? As a small company with 10 employees we cannot spend a lot of time and money figuring this out though, so here is how we did it the “quick-and-dirty…hrm…quick-and-clean” way. Calculating ecological footprints Luckily there are simple calculators online that can give you a rough estimate of the yearly emissions of your organization. We used one from “Zeromission”: Zeromission footprint calculator They have average values for companies that you may use if you don’t know your exact numbers, and you get your emissions broken down into it’s major components: Taking actions Looking at our breakdown we see that “Mobility” is by far our largest culprit, but it may be different for you. Here are steps we have already taken that may affect our results: We only serve vegetarian food at all our events. We all happen to use public transportation to get to work. We do most of our meetings digitally and rarely travel to see clients abroad. These steps may or may not be possible for you. Even considering these steps, “Mobility” is still a large part of our emissions. We sat down and discussed the numbers, and here are steps we consider taking to reduce them even further: Use long distance train instead of flying when possible. Give employees subsidized public transport cards to avoid traveling by car. Invest in better software and hardware for digital meetings Compensating for damage done Now that we knew what our footprint was we wanted to find the most effective way to contribute financially to compensate for this. Luckily there is a movement called “Effective Altruism” and a book called “Doing good better” that explains it well. We found an organization called “Cool Earth” that works to prevent deforestation of different rain forests, and it is described in this article about Cool Earth on givingwhatwecan.org Cool Earth is the most cost-effective charity we have identified to date which works on mitigating climate change through direct action…We estimate that Cool Earth is able to reduce emissions by 1 tonne of CO2-equivalent for every $1.34 donated, for directly protected forest specifically (although this figure may be as low as $0.65). If indirectly shielded forest is also included, this drops to $0.38 per tonne of CO2-equivalent. This is 25 times less expensive than most carbon offset providers, which typically reduce emissions by 1 tonne for roughly every $10 spent. We also found the Rainforest Coalition, a non profit organization that works on a political level. They were deemed very “high impact per dollar” according to this article on “Founders pledge” about climate change. According to our cost-effectiveness model, a donation to CfRN will avert a tonne of CO2e for $0.12, with a plausible range of $0.02 – $0.72. Equivalently, a $100 donation to CfRN would avert ~857 tonnes of CO2e with a range of ~138 tonnes to ~4,600 tonnes. These estimates are highly uncertain. For context, the average person in the UK causes the emission of around 10 tonnes of CO2 per year, and it is generally considered to be difficult to avert a tonne of CO2e for less than $2. We now calculated what we needed to donate using the “worst estimates” of impact per dollar to be on the sure side to compensate for our emissions. The number was still relatively low, maybe because we are digital accessibility consultants and as such we don’t have factories or production lines. One part of working at Axess Lab is that all employees get to decide on how to use any profits each year. This year, based on the discussions above, we decided to use a part of the profits to donate equal amounts to the above mentioned organizations. Enough to put us on the “climate positive” side. This is in no way a guarantee that we now have a positive impact on the environment. Estimates may be wrong, and most clever people recommend reducing our impact before compensating for it. But with the limited time and resources a small company has, this is something we can actually do right now! The challenge How much would it cost your company to become climate positive? What does your company already do to reduce your ecological footprint? What steps are you taking this year? We hereby challenge other companies to calculate their footprint and let the world know what they are doing to reduce their impact, sharing it using the hashtag #climatepositive #climatepositive Thanks for reading, even if this article has little to do with digital accessibility! If you’re looking for a tech job in Stockholm, and you agree with our goal of holistic impact, please get in touch at [email protected]. If you liked this article… …We don’t have any other similar articles :O Here are some about digital accessibility instead: Videos of people with disabilities using tech How to make your site accessible for screen magnifiers Axess Lab just got a 5 star rating on Clutch What is a screen reader? Daniel Göransson — Fri, 15 Nov 2019 15:27:56 +0000 A screen reader is an assistive technology, primarily used by people with vision impairments. It converts text, buttons, images and other screen elements into speech or braille. Let’s go through what a screen reader is, how it works and see blind people in action! Screen reader basics I use a screen reader on my mobile device every day, so it’s a technology I’m very familiar with. But I know it’s new and strange to most people. So let’s go through the basics! Screen readers are mainly used by people with no or limited vision to get information in a way accessible to them: braille, speech or both. The best way to understand is to watch it in action. So here’s Marc Sutton showing a desktop screen reader. At the end of this article, we’ve added a few more videos with screen reader users, showcasing different screen readers on different devices. So scroll down and check them out if you’d like! Fasten your seatbelt – they are quick! The first thing most people comment on when meeting a screen reader user is the speed at which the synthetic voice speaks. The Finnish developer Tuukka Ojala has his set at 450 words per minute. Here’s a 5 second audio clip of what that sounds like: https://axesslab.com/wp-content/uploads/2019/11/450-wpm-online-audio-converter.com_.mp3 Pretty awesome huh! For reference, most sighted people read at about 150 words per minute, so he’s able to read at 3 times that speed. You should check out Tuukkas own article on this topic, where you’ll also find a longer audio clip of the screen reader speaking at lightning speed: Software development at 450 words per minute How are screen readers used? One thing that most people I meet haven’t thought about is that many screen reader users, like myself, have some remaining vision. So we often use a screen reader in combination with sight. For instance, I’ll sometimes rely on my sight for general navigation using a screen magnifier. Then I’ll turn on the screen reader when reading longer texts. On smaller devices I’ll rely more on the screen reader and on larger devices more on screen magnification. A great resource to understand screen reader users better is the Screen Reader User Survey by WebAIM, which over a thousand people respond to about once every other year. The survey goes through things like: Screen readers most commonly used Web browsers Operating systems Reasons for inaccessibility And much more! So head on over to that site and learn all you need to know. But below is a summary of how desktop and mobile screen readers are used. Desktop screen readers On a desktop, users will usually navigate using their keyboard. Either stepping from object to object or by jumping between different types of components, like headings, forms, links or landmarks. Thanks to the awesome Screen Reader User Survey mentioned above, we know that most desktop screen reader users navigate between headings when they arrive at a new page. For instance by pressing the h-key in JAWS – one of the most used desktop screen readers. There are many keyboard shortcuts for screen readers that lets you do everything from searching content to identifying the font of the text you currently are reading. Here is a list of around 100 shortcuts for the JAWS screen reader. Mobile screen readers Even though it’s possible, most screen reader users don’t connect a keyboard to their mobile devices. Instead, we navigate by moving our finger on the screen in one of two ways: Touch navigation: dragging our finger across the screen, and getting what’s under our finger read to us. Swipe navigation: Swiping left and right to move to the next or previous item. Kind of like using the tab-key on a computer keyboard. It’s very common for people to switch between these modes of navigation. I myself prefer using the touch method most of the time, but then I’ll switch to swipe navigation if I suspect I’m missing something on the screen. Swiping is a more thorough way of navigating, since it sets the focus on every item, even on the smallest of click targets. But it usually takes a bit more time than the touch method. A super handy feature for people who know braille is the braille keyboard in iOS devices. Here’s a video showing how that can be used. Try it yourself A great way to learn about screen readers is to try one yourself! It takes a bit of training though. Rob Dodson has made a few great 7-12 minute tutorials for Mac, Windows, iPhone and Android! Let’s start with the iPhone! Moving on to Talkback for Android. VoiceOver on MacBooks. Finally NVDA for Windows! Making screen reader friendly interfaces Creating screen reader accessible interfaces is a lot about coding correctly. However, you also need to think about making it intuitive, usable and easy to navigate. These ”softer” factors is something many people forget about. But only focusing on the technical aspects will not by default make your interface accessible to screen reader users. So let’s start with some usability tips! Make touch targets large Large touch targets are crucial for people who navigate on mobile devices using the touch method that we explained about earlier. If touch targets are too small, there is a big risk of the user missing them. Limit the number of links in the site banner A lot of screen reader users get stuck trying to get through what feels like a million links before the main content of a page. These links are usually in menus, headers and social media share functions. Keep these to as few as possible to enhance the user experience of a screen reader user – and everyone else! Include skip links Even if you limit the number of links in the site banner, it can be nice to provide a skip link. A skip link is a way for all keyboard users – including screen reader users – to jump straight to important parts of a web page. Skip links should be the first focusable elements on a page, and can be visually hidden but shown on focus; in other words: show when the user tabs to them. Here’s an article we wrote all about skip links and what could go wrong with them. Keep paragraphs short Short paragraphs make it easier for a screen reader user to go back and read something on a page again. The most common way to read with a screen reader is one paragraph at a time. So huge paragraphs at a time will be harder to skim through. Use a lot of headings and subheadings While on the topic of skim reading, it’s important to divide content into many headings and subheadings. Screen reader users will often jump from heading to heading. In fact, the majority of the respondents to WEB Aim’s Screen Reader User Survey say that jumping between headings is their primary way to navigate when they encounter lengthy web pages. If there are too few headings this method will not be effective. Short paragraphs and a good use of headings and subheadings will also help many people with reading impairments like dyslexia. Of course, there are more things to think about when it comes to screen readers and usability, but this is enough for this introductory article. Let’s move on to the more technical arts! Code headings correctly For screen reader users to be able to jump between headings, the headings must be coded as h-elements according to the HTML-specifications. That is: , and so on. If you’re an editor, the thing to remember is to choose headings from the dropdown in your content editor. Do not create headings by styling normal text, like increasing the font size and making it bold. Also, make sure the heading structure is correct. We see mistakes with this all the time. A screen reader will tell the user what level the heading is at. So don’t follow a heading on level 1 (h1) with a heading on level 3 (h3). It can confuse the users: “Did I miss a heading on level 2?”. And don’t make all your headings on the same level. Think of it as an essay you’re writing in Microsoft Word. If you’d make a table of contents, you need to make sure the heading structure is correct. The same goes for webpages. Give images alt-texts When coming across an image, the screen reader will read the alt-text of that image. This is supposed to be a description of the image that editors or developers have added. Sadly, many don’t write alt-texts or add keywords to the alt-texts hoping to increase their search engine optimization, which becomes an accessibility problem. We’ve got an article all about alt-texts you should check out if you’re interested in this topic: Alt-texts: The ultimate guide Careful with modals It’s almost frightening how many times I’ve seen modal windows exclude screen reader users from interfaces. What usually happens is that a modal window opens up but doesn’t receive focus, so the screen reader user is trapped behind it and can’t find it. These modal windows are often crucial confirmation dialogues, asking things like “Are you sure you want to go through with this purchase?”. So not being able to access those components can completely shut users out. Luckily, there are great resources out there to help you build accessible modals. Here are two: Accessible Modal Dialogs – A11ycast (YouTube) Creating an accessible modal dialog (bitsofcode.de) CAPTCHA’s Don’t use them. Just don’t. Why? We have dedicated a whole article to that topic: Captchas suck. Follow coding standards A really great way to make your interface accessible is to use standard components and follow coding standards. For instance, if you make a checkbox, use the input element with type checkbox, just like the HTML-standard says you should. It seems really straight forward, but people create custom components like checkboxes all the time. If you create a custom component – for instance by styling a div and adding an onClick-listener with javascript – you don’t get accessibility built-in. You can add it yourself, but it’s often tedious and you need to know what you’re doing. So just use standard components as much as possible. Learn to test with a screen reader As a developer, it would be unthinkable to release a website without first looking at it in a browser. Take this notion and apply it to screen readers as well. Learn the basics of screen reader usage, for example by following the video tutorials earlier in this article. And make a habit of always testing your product with a screen reader before releasing it. Videos of screen reader users in action Last but not least, the best way to learn is from screen reader users themselves. So here we have collected a few great videos for you to enjoy. Gayle Yarnall showing how braille displays work. Saqib Shaikh shows us how he codes using Visual Studio and a screen reader. Molly Burke showing all her Apple products with the screen reader VoiceOver: For a concrete example of how we help children with visual impairments learn the keyboard, see the project Typing in the dark. Thanks for reading, and if you need any support on this topic, we do training, workshops and other accessibility services that can help you take an inclusive leap forward! Get in touch at [email protected]. If you liked this article… You might also enjoy these: Videos of people with disabilities using tech How to make your site accessible for screen magnifiers Assistive Technologies – The Switch Videos of people with disabilities using tech Hampus Sethfors — Fri, 08 Nov 2019 15:51:16 +0000 There is no better way to understand the importance of accessibility and inclusive design than learning from actual users with disabilities. Here’s a collection of our favorite YouTube videos where people showcase how they use assistive technologies like screen readers, eye tracking, zoom and switches. We’ll start off with former BMX star Stephen Murray showing how he controls the computer to run his business just by using his eyes. Brad from All Access Life also uses an eye tracker. Here he is playing World of Warcraft. One of the most expensive things you can do in marketing is run a commercial during the Super Bowl. Big thumbs up for Microsoft on their 2019 commercial, showing kids with motor impairments using the adaptive controller for Xbox. On the topic of the adaptive controller, here’s comedian Zach Anner using it to totally humiliate his buddy while gaming. One last gaming video! Here’s Sven who plays Street Fighter at professional level without sight. Cred to the audio designers behind the game who have made this possible in the Street Fighter series since the early 1990’s. Molly Burke, who at the moment has almost 2 million subscribers on YouTube, made a few great videos on using technology with her screen reader. Here’s Molly showing a frustrating shopping experience trying to purchase a pair of Converse shoes online. Here’s James Rath explaining how he uses a computer with zoom in combination with synthetic speech. Tommy Edison shows an app that helps him and other people with visual impairments identify objects like currency, sock colors and tin cans. One last video on visual impairments. This is Saqib Shaikh, a blind developer showing how he uses a screen reader to code. This is a longer lecture, where Emily Shea explains how she codes Perl using only her voice due to her Repetitive Strain Injury. You should definitely watch the first part and where she starts coding. Apple has a nice video series of short clips with assistive technology users. Here’s one video in that series on motor impairments. Want to see more similar videos, here’s a playlist with all the videos in the Apple Designed for Everyone series. Todd from the previous clip was invited to an Apple event to demonstrate in more detail how he navigates using switches with his tongue. Last but not least, here’s another switch control user, Chrisopher Hills, has some great videos where he demonstrates how he uses it in his work as a video editor. We made a playlist You can find all the videos in this post in a single YouTube playlist. How convenient! YouTube playlist: People with disabilities using technology Do you know something we don’t? We’d love to hear from you if you know of other videos with assistive tech users showcasing how they use their technology. Send them our way on Twitter @AxessLab or to [email protected] and we might add them to this article and the playlist! If you want this kind of perspective on your product, hire a digital accessibility expert experienced with assistive tech. If you liked this article… You might like these too: Accessibility according to actual people with disabilities Hand tremors and the giant-button-problem How to make your site accessible for screen magnifiers I used switch control for a day Hampus Sethfors — Fri, 01 Nov 2019 09:43:14 +0000 Stephen Hawking used something called a switch to communicate, author books and surf the web. Just like Stephen, millions of people around the world with motor impairments use switches to access technology. Sadly, the awareness and knowledge about this assistive technology is generally low. So it’s time to switch the spotlight on switch users! Short note before we start: This article was first written for the great initiative 24 Accessibility – an accessibility article each day in December before Christmas. Switches can look very different, but in the image above I’m holding a classic one – basically, a big button that you press to navigate your computer, smartphone or tablet. I’m an accessibility nerd. I organize accessibility meetups, run a company focused on accessibility (Axess Lab), can recite the accessibility guidelines in my sleep and own 6 different accessibility T-shirts. But even though I live and breathe accessibility, I realize I have a very limited knowledge about switches. I know way more about screen readers than I do about switches. When you think about it, that’s really strange. Looking at pure numbers, there are far more people around the world who have motor impairments like Cerebral Palsy, ALS and Parkinson’s disease than who are blind. So why do we hear and read so little about switch accessibility? I don’t know! But whatever the reason, I feel it’s time to switch it up! Time to learn more about this assistive technology and what we as developers and designers can do to make our technology switch accessible. So I used a switch control for a day and I’d like to share the insights it gave me with you! My setup I used a classic type of switch, basically a big colored button. It’s the one I’m looking suspiciously at in the first image of this article. This type of switch can be placed in the users’ hands, by their head, elbows, feet or wherever they feel most comfortable with it. I held my switch in my hands. I should mention that there are many other types of switches: Sip-and-puff switches. They are “clicked” by sipping and puffing into a straw-like-component. Sensory switches. Stephen Hawking had a sensor attached to his cheek that he activated by a small movement with his cheek up or down. Camera switches. On iOS products, you can activate a switch by tilting your head to the side. There are many other variations of switches, but they all work similarly to the original button-switch, so I used a button. It should also be mentioned that I used a single switch. You can set up multiple switches for different actions – for instance, you could assign one to take you to the home screen, one to move the cursor forward (like pressing the tab-key on a keyboard) and one to click. However, it is possible to use a single switch to fully interact with technology. Which I think is pretty cool so I wanted to try that! Also, I know of people who use a single-switch-setup, for instance, the YouTuber Christopher Hills, whose channel I strongly recommend you check out. I used the built-in setting Switch Control in iOS products — on an iPhone 7, MacBook and Apple TV. It is, of course, possible to use switches on a PC or Android device, but I felt it would be enough of a challenge for me to try it out on one operating system this time. Insights Let me share the insights I got from my day of switch usage with you. Technology is awesome Even though I experienced a few obstacles along the way which I’ll go through below, the main thing that stuck with me is how awesome this technology is. All you need is control of a tiny part of your body so you can activate a switch, and suddenly the whole world opens up through technology. You can surf online, pay bills, order pizza, communicate with friends and unlock doors, all through a single switch. Imagine the difference in independence and quality of life this means for people with severe motor impairments living today compared to — say — 40 years ago. Even though the technology is awesome, there are still things that could improve a lot to give a more equal access and experience of technology out there. Typing is slow Typing with switch control is much, much slower than I’m used to. Here’s a video where I type “Hello World.” If you don’t want to watch the video I describe what happens in it in the text below the video player. https://axesslab.com/wp-content/uploads/2019/02/hello-world-typing.mp4 Video description:* A focus indicator jumps across the keyboard and you need to wait until it’s at the letter you want to type. It takes me over a minute to write “Hello World.” After having practiced a fair bit with typing, I measured how quickly I could type a happy birthday text to my mom. As a comparison, I first typed it with my fingers like I normally do, then a second time with switch control activated. The message was 18 words long. Here’s the result: Without switch control: 43 seconds With switch control: 8 mins 52 seconds (or 532 seconds) So it took me over 12 times as long to type with switch control activated, even though I made very few mistakes and used word suggestions as often as possible. Calculating my typing speed, I was able to type just over 2 words per minute. 2.2 to be exact. As a reference, this article is around 2700 words long, so at 2.2 words per minute, it would take me 20 hours 27 minutes to write it. I asked a colleague of mine to try out typing as well. She had not had the same amount of practice and was able to type at about half my speed, around 1 word per minute. These speeds are in line with sources on Stephen Hawking’s typing speed, which state Hawking could type around 1 word per minute before adding word predictions which doubled his speed. The slow typing speed came with a couple of insights for me: Word predictions when typing is super useful. But word prediction could improve a lot. For instance, I wrote “switch control” twice in one sentence, but my onscreen keyboard didn’t suggest it to me any quicker the second time around. Autocomplete in search fields is very helpful. Time limits – getting kicked out of a form if you don’t complete it in a set amount of time – is a severe accessibility barrier. Forms that prefill automatically save tons of time and energy. Dictation — speaking your message — would make typing much quicker. However, many people with motor impairments also have a speech impairment that makes dictation impossible. So I decided not to use dictation in my one-day-experiment. Scrolling is sometimes painfully slow I think everyone would agree that scrolling is something you do quite often, especially on smaller devices like smartphones. So it surprised me that it was painfully slow to scroll on an iPhone. Let me break down what switch users have to do to scroll: 2 quick clicks to bring up an interaction menu 1 click to select the row with scroll button 1 click to select the scroll button 1 click to select the row with scroll down button 1 click to select the scroll down button 1 click to go back to the main menu 1 click to close the interaction menu So in total 8 clicks to scroll down. Here’s a short video that shows the interaction described above when I scroll on Twitter. https://axesslab.com/wp-content/uploads/2019/02/scroll-twitter.mp4 Video description: Scrolling one screen on Twitter with switch control. 20 seconds was needed to bring up, navigate and close the interaction menu. On Android, the scroll gesture seems to be much more effective, as illustrated in this YouTube clip: A11ycast with Rob Dodson – Switch Device (Youtube). Here it just takes two clicks to scroll: one when the whole page is selected, another one when the scroll down button is selected. What about on Mac? Well, it was much quicker to select the scroll gesture than on an iPhone, but the page scrolled so little with each click that it felt like a joke. Here’s a video that shows this in action. Each click of the scroll gesture scrolls the page approximately 5% down. https://axesslab.com/wp-content/uploads/2019/02/scroll-mac.mp4 Video description: Using switch control to scroll a webpage on a Mac. A focus indicator automatically travels quickly across an interactive menu at the bottom of the screen, 7 steps before it reaches the scroll button. After pressing it, the page just scrolls down slightly, and the cursor starts from the beginning of the interactive menu again. I later realized that I could tap multiple times on the scroll gesture, which helped speed things up a lot. But it would be much smoother if one click on the gesture started scrolling the page down and the next click stopped it. On Apple TV scrolling was much easier. Here’s a video of that in action. https://axesslab.com/wp-content/uploads/2019/02/scroll-apple-tv.mp4 Video description: A scroll bar shows up on the side of the page in the YouTube app on a TV. I just select that to scroll down and the focus stays in the scrollbar until I decide to leave it. Then I enter a horizontal scroll instead, which works in the same way. Finally, I activate the video I want to view. All in all, I think that teams designing switch interfaces for operating systems should focus a lot on improving scrolling. There’s a lot of room for improvement of the user experience in this aspect. For everyone who builds websites and apps: what we can do is make sure important interactive elements and information are at the top of the page. The classic principle of “above the fold” (viewable on the screen without scrolling) is very relevant for switch control users. Scrolling requires more time and energy for switch users. In the words of usability gurus Jakob Nielsen and Don Norman: the interaction cost of scrolling is high for switch users. Mistakes increase I found myself making mistakes a lot. It was mostly due to me pressing the switch too late, resulting in me activating something I didn’t want to click. The number of misclicks would probably decrease with practice. However, with more practice, I’m pretty sure I would increase the speed of the cursor that moves across the screen, and higher speed would mean a bigger risk of mistakes. So a well-designed error handling is really important. Twitter had a feature I really appreciated. I was replying to a tweet when I accidentally pressed the back button. I had spent a good five minutes writing the reply so I got quite frustrated. But luckily, Twitter had saved my work-in-progress so when I clicked the reply button again I could continue from where I was when the mistake happened. Great stuff! Notifications steal focus, literally Whenever I received a notification on my phone, focus switched from where I was to the notification. That might sound like a good feature, making it easy to quickly open the notification. However, I found it quite frustrating, especially when I was typing something. It takes a while to get the cursor to select the correct key on the onscreen keyboard, and if I received a notification while typing I had to start all over again. Here’s a video showing this in action: https://axesslab.com/wp-content/uploads/2019/02/annoying-notification-.mp4 Video description: I’m writing a Tweet on my phone and have waited 7 seconds for the cursor to get to the “m” when I receive a notification. Focus jumps away from the keyboard, up to the notification at the top of the page and I have to start over typing. I – like most people – get quite a lot of notifications from email, Slack, Facebook, news apps and more, so this disruption while typing happened frequently. Here are two different ways I think Apple could go about to improve the user experience of notifications when switch control is activated: Solution 1: If the user has focus on the keyboard, don’t switch focus to notifications when they appear. Instead, let the user finish typing and go to the notification center when they’re done. Or even better: Solution 2: Delay showing notifications until the user is done typing. Then they get the chance of both finishing what they’re writing and click the notification. Of course, there would have to be some time limit in place, so notifications show if the user has a keyboard open for long periods of time. Item mode versus point mode There are two main modes in switch control on iOS devices, and I’m pretty sure it’s something equivalent on Android: Item mode – the cursor jumps from object to object on the screen. Kind of like pressing the tab-key over and over again on your keyboard. Although it’s a bit smarter than the tab key since it groups elements together to allow users to be more efficient. Point mode – like a virtual mouse pointer. First, a vertical line swipes from left to right on the screen, you activate your switch to stop the line. Then a horizontal line swipes from top to bottom and you activate your switch to stop that one too. Where the two lines intersect, a click is triggered. Here’s a video that first shows me using item mode to navigate BBC’s website. I then switch over to point mode, so you can see the difference. https://axesslab.com/wp-content/uploads/2019/02/object-vs-point-mode.mp4 Video description: First a focus indicator jumps across different objects on the website. Since there are quite a lot of links and buttons, it takes a long time to get through everything. I then bring up a menu and switch to point mode. I first stop a vertical line, then a horizontal line, where I want to click. This is much faster than the first item mode. I found item mode to be easier and more efficient when navigating apps and my phone interface – like the home screen, settings and so on. However, on websites, it was hard knowing which order things would receive focus in, and strange grouping of objects often confused me. So I found that changing to point mode when surfing the web made things much easier. Surfing the web in point mode is something that YouTuber Christopher Hills explains that he also does, for the same reasons. Websites could make item mode navigation simpler by having cleaner interfaces with less clickable things on each view and by making sure the order that objects receive focus is logical. Then switch users might not have to change to point mode, which would be nice since it takes some time to switch between the modes. I struggled with connection issues Finally, I want to say something about connection issues. For some reason, I had a hard time connecting the switch to my devices. Quite a few times, it appeared in the Bluetooth menu but wouldn’t connect. I’ve had this issue earlier too, and sometimes it has been because I’ve forgotten to unpair it from another device, but this time I swear it was just messing with me for the fun of it! I had to wait for the switch to drain its battery and restart since there’s no way to restart it manually. Then the switch worked fine again. But it took over a day to get this fixed. I talked to a friend who has a sister who uses switches, and she experiences the same issue with another Bluetooth switch she’s using. It keeps unpairing for some reason. I see a pattern emerge if you consider other assistive technologies as well. The last few months I’ve met three different blind screen reader users who have had to restart their devices when they froze in the middle of usage. So it seems to me like assistive technology bug far more often than mainstream technology. Which is a huge problem considering that many assistive technology users rely heavily on their tech working. Try it yourself There are a few ways to try switch control yourself: The easiest way to try this out if you don’t own a switch is probably to use an Android phone. Find the phone’s accessibility/ease-of-use settings and go into Switch Access. The reason Android is great is that you can assign the up and down volume keys as switches and get going really quickly, without having to buy a switch. If you own a Mac you can assign any key on your keyboard as a switch, which is great. So go into Settings and Accessibility to try this out. On iOS products you can set the phone’s screen to be a switch. This is scary since when you’ve activated this, any tap on the screen is like clicking a switch, instead of what usually happens when you tap the screen. You can also use the camera as a switch, so when you tilt your head left or right it activates the switch. But this wasn’t very stable when I tested it. If you want to try a real Switch you can get one for around €100. Just Google “buy switch assistive technology” and you’ll get loads of hits. My key takeaways To summarize, this experience left me with three main takeaways: Switch technology is awesome. Even though most things take longer time, I could still do everything I otherwise do – just using a single switch. What a great leap towards an independent life this must be for people with limited motor abilities! There’s a lot that switch interface producers like Apple could do to improve the user experience for switch users. For instance more efficient scrolling, less annoying notifications and improved word predictions. Designers and developers of apps and websites should mainly keep their interfaces clean, avoid time limits and have good error handling. So basically work on creating a good user experience for all users. Those are the main things that stuck with me, but… …don’t rely on my experience! My experience of using a switch for a day is by no means comparable to someone using it every day of their life. So I want to end this article by pointing you to resources where you can learn about switch control from actual switch users: Christopher Hill’s YouTube channel Apple’s 2 minute videos Ian M and Todd S Different switch users, YouTube playlist @AbleGamers on Twitter @OneSwitch on Twitter Switch gaming blog Last impressions first – a flipped approach to web design Hampus Sethfors — Thu, 17 Oct 2019 10:07:41 +0000 Web teams usually spend a tremendous amount of time, money and energy on designing lovely, beautiful start pages. Let’s apply the psychological concept known as the peak-end rule to question that and introduce a flipped approach to web design. Why we care so much about start pages If your parents are like most parents, you’ve probably been raised to care a lot about first impressions. How to introduce yourself, shake hands in the right way, dress properly and so on. I remember my parents repeating “first impressions last” and “you never get a second chance at a first impression” to me as a kid. Then time ticks on and kids with this mindset grow up. Some of us go into the web world and become designers, developers, content creators, scrum masters and so on. It’s natural for us to apply this first-impressions-matter-mindset to the projects we work on. So we focus on the start page and make sure our users get the ultimate first impression when using the interfaces we create. The start page is also probably the thing that is displayed in marketing materials, on important board meetings and what you show friends or family members who ask what you actually do during the days. But I believe it’s time to start questioning the importance of first impressions in digital products. Let’s use Nobel Prize-winning psychology to argue that we’re overrating the impact of start and landing pages, whilst at the same time underrating other aspects of the user experience. It’s time to shift focus if we really care about how our users experience, feel about and remember the sites and apps we build. The peak-end rule I don’t know Daniel Kahneman, but I feel quite confident saying he’s a smart guy. Kahneman is a psychologist who won the Nobel Prize in 2002 and has written the masterpiece Thinking Fast and Slow. He is an expert in the way we think, make decisions and experience the world. He and his colleagues have shown that two things matter a bit more than everything else when people judge an experience: How they felt at the peak of the experience (best or worst) How they felt at the end For instance, let’s say you go through a medical procedure. Every minute you’re asked to rate how painful it is from a scale from 1-10. In the beginning, you don’t feel much pain at all, so you rate it a 2. But at its height there was a very painful moment that you rated a 10. And at the end of the procedure you rate your pain as a 6. When you’re asked about the experience a few days later you’re likely to rate it at an 8. In other words, the average between the peak 10 and end 6. It doesn’t matter that your first experience was a 2. When thinking back on an experience, most people will only consider the peak and end. Here’s a more in-depth article about the peak-end rule (medium.com). Applying the peak-end rule to web design If you want positively affect the user experience your site or app, don’t focus a lot of time and energy on designing the first experience your users encounter. Instead, consider how you can make sure that the peak and last experience of using your site is awesome. So let’s go through: How to create an awesome peak experience How to create an awesome last experience Of these two, creating an awesome last experience is most important. I’ll get to why soon. But let’s go through them in order. How to create an awesome peak experience A great way to create awesome peak experiences is to think seriously about how you can make your users smile. I’ve written a whole article on charming interfaces, but in essence, it’s about working with microcopy (tiny words with a huge UX impact) – and illustrations to create pleasant experiences. Let’s look at my favorite example of how microcopy can be used to create a peak positive user experience. It’s from Prezi’s sign up form, which makes it even more impressive since forms are usually really dull. The form complements the user with brilliant microcopy after entering the details they ask for. Genious! If you want to become a wizard in microcopy, I’d recommend: Microcopy and UX-writing (Facebook group) Good UX Writing (Instagram) Microcopy – the complete guide (book) Apart from microcopy, working with illustrations and animations is a good way of creating positive peak experiences. Here’s a very cute login form from readme.io, where an illustrated owl peeks when you’re typing your email but covers its eyes when you type your password. An important detail in the peak-end rule is that the peak experience, good or bad, is what will define a users overall feelings of the experience. So for all of us who design digital products – or any product or service for that matter – it’s very important that our users’ most positive experiences create a more intense reaction than their most negative experiences. If a user finds most of your site pleasant, but their peak experience is frustration of filling out a CAPTCHA three times – well, sadly, the pleasant experiences won’t matter much at all. As you probably experienced yourself multiple times: confusing or frustrating experiences easily create strong reactions. On top of that, these types of negative experiences are very common in digital products. So you need to work hard on minimizing the risk of strong negative experiences. On that topic, I have two tips: User test regularly. Nothing beats watching people use your site and seeing where they react strongly, get confused or get stuck. And while on that subject, consider testing with users with disabilities. Work on your error messages. It’s the one place where users are most likely to experience strong, negative feelings. When it comes to error messages, the most important thing is to make sure users understand what’s gone wrong and how to fix it. This article on best practices for error messages is a nice read. But on top of that, error messages are often a good place to use some charm and humor to minimize the negative emotions they cause. So before moving on to the last experience, let’s summarise how to create an awesome peak experience: Make your users smile. For instance by working with microcopy and animations. Avoid negative peak experiences. For instance by user testing and focusing on error handling. How to create an awesome last experience So let’s now shift our focus to the last experiences. This is a hugely overlooked opportunity to positively affect how your users remember your site. One of the best UX-hacks I know is to do everything you can to create an awesome last experience, thereby merging the last experience with the peak experience. It would look something like this when applying Kahneman’s peak-end model: So if the user’s memory of an experience is based on the average between the peak and end experience, and you make sure that the last experience is a 10, then most users will remember the whole experience as a 10. I suggest moving a lot of that time and energy that you now spend on start pages to creating a fantastic last experience. That will most likely have a huge impact on the user experience and what people tell their friends about your service. To do this, start by identifying where your users are when they stop interacting with you. It’s often at one of these places: Confirmation messages or order summaries – after having bought something or completed a form Offboarding processes Footers – after having read through your content Then make sure these places are awesome! Let’s look at some examples. Spotify does this really well by providing an offboarding process with great microcopy and a charming playlist called “Can we still be friends?”: Disney also gave some love to their offboarding: Gov.uk focused on A/B testing the last experience of one of their thank-you-pages. They made it so good that each year, an estimated 100 000 more people sign up as organ donors each year through one link on that page. Nice! It’s not only the digital world that can work on last experiences. When leaving the dentist as a kid, I remember always getting a sticker and some cheerful words. Some hospitals have taken this a step further, with an end of treatment bell: Finally, back to the digital space! More sites could put some effort into their footers. It’s difficult to find many good examples of this, but some have at least added illustrations to their footers which I think is a step in the right direction: A flipped approach to web design So to sum up, if you’re serious about your user experience you should stop worrying about the pixels on your start page and begin focusing on the last experience. “First experiences last” is an overrated saying. “Last experiences first” is the new black. If you liked this article You might also enjoy these ones: How icons are ruining interfaces Hand tremors and the giant-button-problem Charming interfaces – make your users smile Apple’s new feature a step towards digital apartheid Hampus Sethfors — Thu, 28 Mar 2019 18:24:11 +0000 To be honest, I don’t really have time to write this article. I’ve got loads of other things I should be doing. But it needs to be written. Now. So I’ve popped up my laptop on the bus and am angrily typing away. Sounds so serious…what’s going on? So Apple just released a new accessibility “feature” called accessibility events. Here’s how they explain the feature: Accessibility events allow websites to customize their behaviour for assistive technologies, like VoiceOver. Enabling Accessibility Events may reveal whether an assistive technology is active on your iPhone. Here it is in action on an iPhone: So this feature lets web developers recognise when an assistive technology is active on the user’s device. Sounds great, right? Gives developers a chance to improve the user experience for people with disabilities. But think a step further and you’ll realise that it’s actually a terrible idea. Why? Well, accessibility guru and screen reader user Marco Zehe explains it well in his article Why screen reader detection on the web is a bad thing. Here is the most important part in my opinion: Letting a website know you’re using a screen reader means running around the web waving a red flag that shouts “here, I’m visually impaired or blind!” at anyone who is willing to look. It would take away the one place where we as blind people can be relatively undetected without our white cane or guide dog screaming at everybody around us that we’re blind or visually impaired, and therefore giving others a chance to treat us like true equals. – Marco Zehe Another accessibility guru Léonie Watson also wrote a great piece on this topic: Thoughts on screen reader detection. In it she argues that screen reader detection could lead to her and others being directed to text-only versions of sites: I don’t want to be relegated to a ghetto. We’ve spent years encouraging people to move away from text-only websites, and with good reason. If there is one thing that history should have taught us by now, it’s that social segregation is a bad idea. – Léonie Watson From my own experience, one of the most common questions I get as an accessibility consultant is “Can’t we just create a special site for people with screen readers?” I say that you can’t, and even if you could it would be a really bad idea. Inclusive design is about inclusion, not separation. The problem is that with this new tool from Apple, well-meaning people with this common, but terrible idea of separate “disability-sites” now can implement it, whereas in the past they couldn’t. The accessibility community is not pleased Other accessibility folks are not impressed either: This new Accessibility Events feature for VoiceOver in iOS 12.2 might possibly be the worst idea ever (especially as it is enabled by default). Sure, let’s give devs ways to identify blind users & serve alternate versions of content. That worked really well in the past. pic.twitter.com/gDTSvQqNKp — Denis Boudreau (@dboudreau) March 27, 2019 It's been possible in native apps for a while, but now @Apple has enabled disability fingerprinting in Safari on iOS. https://t.co/b7ahixqbke #privacy #fail — Léonie (@LeonieWatson) March 27, 2019 https://twitter.com/aaronkhowell/status/1110650865180790784 Yikes.. sounds like the perfect excuse to build "accessibility" in exactly the wrong way — Facundo Corradini (@fcorradini) March 26, 2019 I also discussed this accessibility events feature with my friend who is a screen reader user herself. She said it feels like it’s a first step towards a well-meant digital apartheid. To give you a magnitude of the impact this type of detection might have. As if things weren’t bad enough…it’s on by default First I thought users needed to opt-in on the setting. It would still be bad but tolerable. But alas! It’s activated by default! So users who just turn the screen reader on have it enabled. Yes, they can turn it off: How to disable "Accessibility Events" the VoiceOver and other AT tracking feature on iOS update 12.2 pic.twitter.com/RC5W8a0e1t — Ross Mullen (@MrRossMullen) March 27, 2019 But everyone knows most users will be completely unaware of this feature. There’s barely any information This feature dropped like a bomb on the accessibility community and there’s basically no information out there on it. Nothing in the release notes, nothing on Apple’s site. It just appeared in the accessibility settings, and someone noticed and wrote a short article about it on Apple Vis. My good friend Kolombiken (who writes the best accessibility newsletter out there, you should check it out) went searching for answers in a huge Slack group for accessibility nerds and found nothing: I’m soo confused over this new “accessibility events”-thing in iOS. I came here to look for answers but seeing that people here are equally confused. But there must be some documentation somewhere? No? Apple, you can’t just roll out a feature like this with no information! Come on, this is not like you! Hopefully this is just a hiccup I think it’s safe to say that Apple has some serious explanation to do here. Both around the feature and the non-existent documentation around it. Hopefully it’s just a mistake, wasn’t supposed to be rolled out or something similar. Until that is confirmed though, I think it’s time for the accessibility community to protest rather loudly. Update Yay! Apple has now removed the accessibility event feature, about a month after it was released. All is well and I’m not angry any more! Accessibility T-shirts! Look like the a11y nerd you are Hampus Sethfors — Sat, 23 Feb 2019 22:09:10 +0000 It’s well known in the accessibility community that the road to an inclusive digital world is through awareness. And what better way to raise awareness than wearing an awesome, head-turning accessibility t-shirt? Before we begin, you might be wondering how much we get paid to write this post. It’s zero. Zip. Nada. Just hopefully the admiration from other fellow accessibility nerds! So let’s dive in! A11y cats Flaunt your love for accessibility, cats and puns (alley cats..get it?!). Put this on your Tinder profile and you’re good to go! Get A11y cats t-shirt on Bonfire The future is accessible t-shirt Thinking about the future is can be scary these days. Finally, you have the chance to spread some positivity! Get this future t-shirt on Redbubble You can get a more sparkling version of the same statement. Get the sparkling future t-shirt on etsy Moose in wheelchair t-shirt We might be a bit partial since we’re based in Sweden, but moose are just irresistible! Almost as irresistible as everyone who’s working with accessibility. Perfect match! Get your moose t-shirt on Teepublic (there are also versions on the site with other animals like giraffes and even dinosaurs!) WCAG t-shirt Perfect for walking around the office quizzing colleagues. Do they know where the words come from? If not, send them off to accessibility training! Get your WCAG t-shirt at Redbubble Inclusive coder t-shirt Display your passion for accessibility alongside html, css and javascript. Get your inclusive coder t-shirt from Scott Vinkle Accessibility matters t-shirt It’s not easy to find t-shirts raising awareness of hidden impairments like autism. But luckily we found this one! A great reason to go get it is that “50% or more of the proceeds from this design are donated directly to disabled individuals who are fundraising for a mobility aid or other accessibility device.” Get the accessibility matters t-shirt at Bonfire Closed captions t-shirt Videos lacking closed captions is one of the major accessibility issues on the web. This cc t-shirt gives you a great chance to talk about closed captions with everyone who asks what the “cc” means! Get your cc t-shirt at Redbubble Sign language be kind t-shirt While on the topic of hard-of-hearing-awareness, check out this great message in American sign language (ASL). Get your sign language t-shirt at Amazon Wheelchair trick t-shirt Finally, let’s challenge the classic sitting-still-in-a-wheelchair-disability-icon with this great print! Get your wheelchair trick t-shirt on Teepublic Whether or not you decide to buy this t-shirt: take a minute of your life to check out the guy who probably inspired it: Aaron “Wheelz” Fotheringham. Keep spreading awareness! Hope you found something to upgrade your wardrobe with, at the same time spreading some accessibility awareness. If you know of any other prints that you think we should add to the article, please tweet us and we’ll add them! Meanwhile, if you’d like to dig deeper into digital accessibility, check out our other articles. We guess that if you’ve made your way down here you’d appreciate some of our more nerdy posts. So here are a few of those: Disabled buttons suck Text splitting causes screen reader problems How to make your site accessible for screen magnifiers Your skip links are broken Axess Lab just got a 5-Star rating on Clutch Joel Holmberg — Thu, 21 Feb 2019 15:23:59 +0000 Axess Lab is a team of IT professionals who want to make life easier for everybody. And it seems to be working! As you may know, we do everything from development projects for everyone to specific digital efforts to help people with a variety of mental and physical disabilities, and we strive to show the world that accessible development only helps, never hurts. In an effort to further the cause of accessible development, we can now be found on the B2B ratings and reviews platform, Clutch. Clutch uses in depth market research and verified client reviews to identify top service provider across a number of industries. We are featured on several directories on Clutch, including alongside some of the top software application testing companies in the world. We hope that our increased visibility by joining the platform will help firms find us and consider making their software and services more accessible for everybody. In addition to expanding our visibility, our presence on Clutch helps us gauge how we are performing for our clients. Although our profile has been active for only a short period of time, we already have our first review! When asked what they found impressive about our work on their project, a job matching platform for people with disabilities, our client remarked, Their skills and accessibility are impressive. They’re interested in people, and they take time for everyone involved in the project. There’s always good communication, and they’re nice people. We care about every project and every person we work with, and we are glad that our clients have taken notice. It is a wonderful feeling to be praised by our clients, but we are even more excited to receive their honest feedback. We may only have one review, but we look forward to using future feedback to help us improve our services. Clutch’s sister-site, The Manifest, has also featured us as a top firm. The Manifest is a business resource that helps teams identify and address their business challenges, providing how-to guides and industry insights. We were included on their list of the top web developers in Sweden, cementing our reputation as a reliable partner, and a skilled team of developers. In spite of the praise that we have received, we believe in letting our work speak for itself. We will be posting some of our best projects in a portfolio on Visual Objects, a space for user experience designers and other firms to share their work with potential clients. It is always exciting to be recognized as a success in your industry, and we are thrilled to be celebrating the recognition we have received from one of our clients. And speaking of our clients, thank you to everyone who has supported us on our journey. We have always wanted to help people, and we cannot express enough gratitude for the help we have received ourselves. Have you worked with us in a development project, or received accessibility reviews or user test analysis? Please give us a review on the Clutch site, and let us know how we’re doing! Real Facts about the Elderly and the World Wide Web Joel Holmberg — Wed, 23 Jan 2019 05:22:24 +0000 There are lots of stereotypes about the elderly and tech or the world wide web. Many portray the over-sixty crowd as being unable to cope with modern tech. But is this stereotype correct? That’s what Dr. Nikola Djordjevic, from the site medalerthelp.org set out to learn. His team compiled all of the information into a comprehensive infographic and the results may surprise you. We got their help to break it down into smaller, more manageable pieces and transcribe the contents for our non-visual readers. Let’s go through the stats one by one. Usage Those of the baby boomer generation spend around 27 hours weekly online. Of the group aged over 65, seven out of ten will go online daily. 82% of those in both groups run searches online related to what they’re interested in. So, in terms of usage, seniors are a lot more active online than you may have suspected. Why do they use it? 78% of seniors say that they like going online because it enables them to find the information that they need easily. 60% of them believe that you can stay up to date when it comes to policy and political issues by surfing the web. For around about a third of seniors, the internet is considered a trustworthy source of information and news. So, the internet is viewed by many of the elderly as a valuable resource. The types of information they access Two-thirds of seniors use the web to access weather and the news. 57% shop online. 44% want information about food and cooking. 43% use it to play games. And, boy, is that breaking a long-held stereotype! Just keep in mind that people who pioneered computers and the internet are now in their sixties, so the generation that started it all is actually quite active. Almost half go online to check for coupons, daily deals, and discounts. What can the internet be used for? 20% of seniors communicate with their friends via email. 75% of the elderly go online to communicate with their family and friends. More than half of those who are classified as seniors follow an organization on social media. 40% of seniors who watch videos online do so in order to keep up to date with breaking news. 53% of the elderly research medical or healthcare issues online. 54% of seniors watch videos online for purely entertainment purposes. Half of the seniors say that it’s very important to play games in order to remain sharp. A further 26% state that playing games is extremely important for this reason. Internet usage by category Two-thirds of queries that seniors make online are related to medical or health info. Coming a close second is visits to federal, state, or local sites. A small percentage of seniors do take classes online, but that’s only about 18%. Social media usage A lot has been said online about Facebook being more popular among older users. As one commentator put it, “Facebook is for the parents, Instagram is for the kids.” The stats seem to bear this out here as well. 61% of those aged 50–59, prefer Facebook. For the over-sixty category, Facebook still comes out on top with 36% of users using it. Compared to Facebook, the other main social media sites don’t fair very well with seniors. Of the group aged 60 or over, 5% use Instagram, 6% use Twitter, and only 1% use Snapchat. Some general statistics For the age group 65 and over, 66% of seniors in the United States go online, and only 10% have smartphones. That’s compared to 87% for those in the 50–64 age group, where around 16% of people have a smartphone. The results also highlighted an interesting phenomenon – both seniors with and without disabilities used the internet. You would expect the seniors with disabilities to use it more. You’d be wrong. Seniors in the age bracket of 80 years old or more tend to use the internet and smart-tech the least. The activity that comes out on top on a daily basis for 91% of seniors is to send or read email. 70% of seniors will also run searches at least once a day online. Across all of the older age groups, cell phones are put to good use. Even in the over eighty category, around about 58% of seniors have cell phones. Smartphone adoption, however, decreases with age. In terms of smartphone usage across various categories, seniors do account for the smallest numbers, which indicates that they are not as comfortable with smartphones as they are with regular mobile phones. If you’re aiming to sell to this target group, the conversion rate is highest on the desktop platform at 72%. In this area, seniors come out trumps. Tablets and phones don’t, however, fair nearly as well in terms of conversion rates. Watching TV online is popular with the 50–59 age group. Furthermore, around about 63% in this age group access streaming services online. 22% of disabled adults in the UK have never used the internet. Who doesn’t use the internet? That’s not to say that all seniors do use the internet. 34% of those who are over 65 don’t go online at all. This is a massive difference when you consider that that figure drops to just 3% for those aged 30–39. Why don’t some seniors use the internet? One of the challenges is poor health or a physical condition that doesn’t allow them to easily access the internet. This affects about two out of five seniors. Almost a quarter of the older generation does not believe in looking online for news, etc. They don’t feel as though they are missing out at all. But, the most prevalent reason by far, in fact in 77% of cases, is simply the lack of knowledge. They need someone to show them exactly what to do and help them until they get the hang of it. In about another quarter of cases, online harassment is cited as the reason to stay offline. About 22% of those in the United States who are fifty or older have been harassed online before. So, there you have it – have you changed your thinking as far as the elderly and the internet is concerned? URL: https://medalerthelp.org/elderly-the-world-wide-web-infographic/ Instagram – You’ve been Axessified! Daniel Göransson — Thu, 03 Jan 2019 14:57:58 +0000 Hi Instagram! We’re thrilled to see you’re improving your accessibility by making it possible to write alt-texts for images. As a token of appreciation, we’ve made you part of our Axessified-series! This means you get some top-notch, tailored inclusive design tips to help you take the next step on your accessibility journey! First off – we really like you! There’s rightfully been a lot of praise from the accessibility community about Instagram’s new alt-text features. Now, an Artificial Intelligence (AI) engine gives each image an automatic alt-text, and also makes it possible for user’s to improve that image description by writing custom alt-texts. This is simply awesome, making one of the most popular social media platforms so much more inclusive to people with visual impairments. We see this as a sign that you’re interested in making Instagram more inclusive for users with visual impairments. So Instagram: don’t stop now, keep moving forward! Here are three tips on what we think should be your next accessibility improvements for users with visual impairments.. Tip 1 of 3: The more-button In the feed, sometimes you show a more-button when a description is too long to be displayed. This button is completely inaccessible for screen reader users like myself (if you aren’t familiar with screen readers, here’s a great 7 minute introductory video on YouTube: Assistive tech: VoiceOver on iOS). The more-button is actually read by screen readers – a great start! But the problem is that there is no way to activate it. When you try to click it, you’re redirected to the user’s profile page. Not at all what you’d expect! Here’s a video when I show this in action: First off, a short sidetrack. Did you notice the great start of the video: “Image may contain text that says Accessibility is for everyone.” This is the new AI-engine in action, making image of text accessible to screen readers. Whoopee! But later in the video the screen reader reads half a sentence and then the word “More”, like this: “I think that’s a…More”. When I click I land on the profile page’s back button, instead of having the description show. To solve this conundrum, you can do one of two things: You probably already figured this first one out: Make the more-button clickable. Get inspired by your best buddy: Facebook. There, the whole description is read by the screen reader even if it’s collapsed visually. Meaning screen reader users don’t need to click the more-button to hear the full text. Super convenient! Of these two solutions, we’d recommend you to go for number 2! Tip 2 of 3: Stories When viewing Instagram stories, basically nothing works for me and other screen reader users. To navigate Stories you tell us to press and hold to pause, tap to continue to the next story and so on. But you see, with a screen reader activated, none of those gestures work in Stories. Everywhere I try to click on the screen I just hear a sound telling me that there’s nothing there to click. Here’s a video of me trying my best to click anything at all on the screen, and failing. All I can focus on are a few icons on the screen, but no content. So I don’t get any content read to me. But the worst thing is that I can’t pause the slideshow. If you have a vision impairment like me, you need to be able to pause the stories to have time to look closely at the screen (yes, most people with visual impairments still see a little bit), zoom in, read alt-texts and so on. Now each story just swishes by too quickly. To make things even worse, I often use an iOS built-in zooming feature where you tap with three fingers to zoom in to images, which works poorly in Instagram Stories. So what I’ll do is turn off the screen reader when entering Stories, and instead rely on zooming and my limited vision. But the problem is that tapping with three fingers in Stories is often registered by the app as a single tap, which switches to the next story. Really frustrating! So to conclude, right now Instagram Stories is a bit of a mess for a lot of users with vision impairments. A simple fix would be to include a setting or a pause button that disables the autoplay feature and instead gives users control of when to switch to the next story. Tip 3 of 3: Naming of your icons This last one is not a “show-stopper” for screen reader users like the two earlier sections. However, it is an easy fix that would improve the overall user experience and make it more pleasant to spend time in your app. You can compare this issue to having visually ugly icons. You could still use the interface, but it would feel unprofessional. So the problem is that many of your icons are read as something like: “Ig icon direct outline 24 direct message” “Ig icon more horizontal outline” “Ig icon x outline 24” That’s probably the file name of the icons, which is not something your users should be exposed to. Here’s a video of that experience with my screen reader. So even though each icon’s description contains the meaning of the icon, it’s hidden between a bunch of nonsense. It’s like being forced to play a game of Where’s Waldo… Luckily, this is something that should take you a matter of minutes to fix. So a really low hanging fruit! Yay! That’s enough for now! We have a lot of other input and ideas, but let’s start with these issues. Remember to give yourself a pat on the back when your done! Then take the next step. Accessibility is not something you do once and then are done with. Just like you’re never done with usability or performance improvements. Always strive to take small steps forward. Everywhere. All the time. But do contact us if you want us to elaborate on this post and help out. There are a lot of tools you can use to catch these errors before they are in production. Who’s next? This was the first post in our Axessified-series where we give accessibility tips to teams behind important digital products that affect the life of many. Accessibility tips for specific products is something we usually charge for, and it’s a big part of how we make our living as a company. But the sites and apps we look at in this series have such a big impact on so many users that we want to share these tips free of charge in hope that they reach the product teams, and inspires them to make their products more inclusive. Hopefully it also gives some nice insight to all readers on how to succeed with accessibility. Which service do you think we should check out next? Tweet us or send an email to [email protected]. Slides from Accessibility Scotland Hampus Sethfors — Thu, 08 Nov 2018 11:03:16 +0000 Hey Accessibility Scotland! I like you guys even though you invented golf… Here are the slides from my talk: Have you tried to dab some coconut oil on your spine (PowerPoint on Dropbox) Enjoy! And while you’re here, you might as well check out our other articles on accessibility. Accessible Comics Hampus Sethfors — Tue, 07 Aug 2018 08:47:48 +0000 A lot of the accessibility initiatives today are focused on web sites and apps. But there’s of course more to the digital world than that. In this article we’ll look at a case where a team has done great work to make their digital comic accessible to people with visual impairments. Let’s start with a small experiment! Imagine a blind person. What image pops up in your head? Is it a young person? Is the person at their work? Doing sports? At the cinema? Buying an Apple Watch? Reading a comic? Probably not. There are many preconceived ideas out there about what people with disabilities do, or rather don’t do. If you don’t have a visual impairment yourself or some blind friends, you probably don’t think of blind people in the above situations. Most people tend to think of an old person with a cane, not doing much. Which of course is a problem that for instance affects how people are treated, job recruitment and which products are made accessible. So we need to get more people to see people with disabilities as a diverse group with all sorts of jobs, interests and hobbies. And we need to get more people to understand that their users have disabilities, which is what the article “Our users have no disabilities” is all about. Making a comic accessible With this in mind, I was pleasantly surprised when the team behind a comic contacted us, asking for advice on the style of alt-texts for their comic: 100 Demon Dialogues. Sidenote: this might seem like a sponsored article, but it’s not. We’re just thrilled to see the great job this team has done and want to share it with you! Most people would never think about making a comic accessible for people with visual impairments. After all, comics are very visual. But the author Lucy Bellwood – in the image above – is more inclusive than most people. She wanted to make her comic accessible to comic lovers with visual impairments as well, and brought a team together to get it done. So they asked us to review a couple of alt-texts they had written. It turned out that they’d already grasped the concept very well so our advice was basically: “Great job, keep doing what you’re doing. And can we write about this when it’s out?” And now the comic is out. We tested it with a screen reader – an assistive technology that speaks alt-texts to the user – and the experience is awesome. So below are two short, short videos. An inaccessible experience of a regular comic where the screen reader just says “Background” when it tries to read the content. The accessible 100 Demon Diaries comic that reads the well crafted alt-texts, which both explain what’s happening visually in the comic and what’s written in text. Direct link to inaccessible version demo (Youtube) Direct link to accessible version demo (Youtube) It’s so great seeing people making their products accessible, especially when barely anyone else in their field are doing it. Hopefully it motivates more people to do the same thing and opens more people’s minds as to the diverse interests of people with disabilities! If you’re as happy with this initiative as we are please spread the word about this and give the author Lucy Bellwood (@LuBellWoo) and her team with Kate Brednow, Andy McMillan (@andymcmillan) and Jason Alderman (@justsomeguy) a shoutout on Twitter. I also strongly recommend the Tumblr A11y Wins – a site that’s dedicated to showcasing positive accessibility examples. If you want to check out the comic, you can find it in the following places: Search for “100 demon dialogues” in iBooks. Amazon Gumroad LGBTQ-inclusive web design Hampus Sethfors — Thu, 02 Aug 2018 14:29:27 +0000 It’s pride week here in Stockholm, Sweden! So we thought we’d celebrate by sharing a few tips on how to create a LGBTQ-inclusive digital environment. Here at Axess Lab we specialise in accessibility and inclusive design – which is about making sure as many people as possible feel great about using your products and services. Accessibility and inclusive design is often focused on people with disabilities, but let’s look at two concrete things you can do to make your digital products awesome from a pride perspective! 1. The gender question Many forms include a question about the user’s gender. Do you really need to know this information? If the answer isn’t a clear “yes”, then the best idea is probably to just remove it. A lot of services ask for users’ gender without really needing it. Simply not asking for gender is great because of a few reasons: You reduce the length of your form by one field. And it’s a fact that reducing the number of form fields increases conversion rates (searchenginepeople.com) Your users don’t start questioning your intents. A lot of companies ask for gender information to be able to send you specific marketing. Many users know this and get suspicious. You don’t risk excluding users who has another gender identity than the ones you specify. If, however, you really need gender information you can ask for the information in an inclusive way. The examples below are from the article Designing forms for gender diversity and inclusion by Sabrina Fonseca and the talk All inclusive design – excluding no gender by Sara Lerén (@HeedTheNeed). The first step that many have already adapted is to add an alternative for “Other”. This is better – or should I say “less bad” – than the binary “Male/female”. But people who identify as male or female get their own categories while everyone else are mashed together to “other”. We can do better! Sometimes the simplest solutions are the best: a custom input field where the user can type whatever they want. Also note how you can explain why you need the gender information below the field. You could include a custom input field after a male and female radio buttons, like this: Including a “Rather not say”, like in the example below, is great as well. It gives people the chance to skip the field, and many who identify as something other than male or female are extra cautious about sharing that information online. Seeing the huge problems with for example transphobia around the world, everyone will not want their gender identity registered in some online database. Combine the “Rather not say” alternative with a custom input field, and you’ve come a long way with little effort! If you want to go all-in, check out Facebook. They’ve done a lot of work with their gender questions. There’s a huge list of gender identity “tags” to choose from, and if you don’t find the correct one you can add to the list yourself. Also, they ask for your preferred pronoun, making it possible to prefer a gender neutral pronoun with examples on how it will be used: “Wish them a happy birthday”. 2. Choose inclusive images and illustrations Our second tip to becoming more LGBTQ-friendly is to work with your images and illustrations. A lot of people can rarely or never identify with the people that are represented in images or illustrations on websites, social media and the like. What you choose to display there says a lot about who your target audience is, so make sure it’s as diverse as possible to feel relevant to all your potential users. Break as many norms as possible in your imagery. Show women playing sport, men taking care of kids, a person in a wheelchair coding, a family with two dads and so on. And make sure not everyone in your images are white. Below are some great examples of inclusive images you can get inspired by. The Swedish army fight for LGBTQ-rights: Facebook shows icons of two men instead of a man and a woman when two men get married: I recommend everyone to check out this Swedish guide: Images that change the world. Even if you don’t know Swedish, just flip through the guide and look at the great images, you’ll get the point! Here’s one of the images featured in it, pointing out that older LGBTQ-couples are extremely rare to see in images. Here’s a great banner image on Stångåstaden a Swedish site for renting apartments: The Swedish youth clinic site has some awesome, inclusive illustrations on their site. The great thing about the one below is that it’s on a page about friendship. It’s not on a page about dating with disabilities. So they picked an inclusive image without making a point of it. This is a great way to help widen the norms we live by. Sometimes it can be difficult to find inclusive images, especially on regular stock photography sites. But luckily Jenny Hellenberg (@jenhell) shared some good tips with me, so here are some great places to look for images with diversity: LGBT section at Twenty20 (the screenshot above is from this site) Unsplash (free) Tetraimages Photoability Getty images lean in collection Natural Woman Photos Hope this inspired you to keep improving your inclusive design! Happy pride everyone! Your skip links are broken Hampus Sethfors — Thu, 21 Jun 2018 08:16:59 +0000 Many websites have an accessibility feature called skip links that help some users navigate the site. However, there’s a problem with basically all skip links on mobile devices, which hurts your site’s accessibility instead of improving it. What are skip links? Skip links are a common accessibility feature on websites. They are simply shortcuts to important parts of the webpage that makes it easier and quicker for some users – especially users with disabilities – to find their way around. Skip links are usually hidden visually by default and appear when users navigate to them using the tab key on their keyboard. “Who would ever use a keyboard to navigate?” you may ask yourself. Well, lots of people actually! For instance many users with motor or sight impairments will rely on keyboard navigation. But more on the use cases under the next heading. If you want to try out a skip link using your laptop, go to Starbuck’s website and press the tab key after you have entered the site. Here’s an attempt at illustrating what happens. So when you “tab into” the site the skip link appears, and you can activate it with the Enter key to skip to where it points. On Starbuck’s site you can (in theory) skip to either the main navigation, content or footer. Skip links work well on desktop. Here’s a short video where I’m using them on a few sites with the VoiceOver screen reader on Mac. It might be a bit difficult to follow along if you’re unused to hearing a screen reader in action, and to make things worse mine switches between Swedish and English. But the important thing to notice is how the focus indicator jumps into the content area after I press the skip links: Skip links are great when they work, and this type of functionality is recommended in the Web Content Accessibility Guidelines (WCAG): 2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. – WCAG 2.1 We can sanity-check your skip links across iOS/Android and desktop as part of a WCAG review. Who are skip links for? Skip links are mainly used by: Users with motor impairments who navigate with a keyboard instead of a mouse. Users with motor impairments who navigate with switches. Users with severe visual impairments who use screen readers on desktop or mobile devices. Users with low vision who use screen magnification software in combination with keyboard navigation. Instead of having to spend time tabbing through the logotype, links in the header, menu, etcetera, on each page you visit, skip links provide a handy shortcut to jump straight to what you’re after. They’re also quite popular among users. In the latest Web AIM screen reader user survey – which almost 1800 people responded to – over 30% said they always or often use skip links when they are present. We’ve seen in user tests that skip links are even more used by novice screen reader users. Tech savvy users tend to use shortcuts on their keyboard or special gestures to skip between different parts of the page. But less “techy” users are not always aware of those features, and will instead often use the skip link to find their way to the main content. Update april 2020 The problems we describe below have been fixed by many (all?) of the browsers/assistive tech/operating systems. So skip links seem to work as intended in most devices right now. The problem We became aware of a major issue with skip links after seeing it in two user tests a few months apart, where two different screen reader users struggled with the same type of problem on two different websites. One of our clients was kind enough to let us share a video clip from their user test in this article. So thanks, Council of the European Union, for that . The user in the test has also given us her consent to spread this video. So take a look at this clip (sorry for the blurry start), then we’ll tear apart exactly what’s happening. So in the clip we see a screen reader user trying to use the skip link with her iPhone. This is what happens: She activates the skip link. The page scrolls down visually – which she and other blind user will not be helped by. She swipes right to go to the next object – you can think of it like pressing the tab key on a desktop. The screen reader puts focus on the cookie message, not the main content. She naturally gets quite confused and annoyed. We started investigating the problem and found the same issue on every single skip link we tested. You can try it yourself if you know how to use the screen reader on your smartphone at these sites: www.starbucks.com www.slack.com www.gov.uk Or just check out this video where we try to use skip links with VoiceOver on an iPhone on the sites above. You’ll see the sites scrolling, but as soon as we swipe the screen to go to the next item, we’re back at the top of the page. Skip links are almost always constructed in the same way. They are simply anchor links pointing to a part of the page. Something like this: `Skip to main content //Menu and other stuff users might want to skip..` … For some reason, these simple anchor links don’t work as intended on iOS. We tried in Safari, Firefox and Chrome – all have the same issue. To be clear, this problem exist on mobile when the user navigates by swiping to go from one object to the next. There is another way of navigating (explore by touch – moving your finger over objects on the screen), and then it works fine on iOS. Affects Android as well, but in a different way Regular skip links don’t work with VoiceOver on iOS as shown above. Sadly they don’t work with Android’s screen reader TalkBack either, but this time it’s not the anchor link that’s causing the problems. In Talkback, skip links don’t even show up when the screen reader focuses on them. Here’s a video where you’ll hear the skip link being announced, but it’s not showing on the screen like in iOS. We try to activate the link when it’s announced, but nothing happens. This is caused by a bug in Android that stops the focus event from being triggered. It’s probably easiest to understand if you look at this video comparing what happens when tabbing on desktop, using VoiceOver on iOS and using TalkBack on Android. You’ll see that when tabbing on desktop or using an iOS screen reader, the focused links turn orange. On Android, you never see the orange focus style. For some reason, Android doesn’t trigger the CSS focus event with TalkBack. This is the reason skip links never show up visually on Android, since they are programmed to show up when they receive focus. This is a bug reported to Google, so hopefully they’ll fix it soon. But shouldn’t it still be possible to use the link, even though it’s visually hidden? Sadly, that’s not possible. If you click on a hidden link with TalkBack, the link will not be activated. So, we guess that Google will need to fix this focus issue before skip links will work at all on Android. Interesting enough, some Android phones have a version of TalkBack called VoiceAssistant. With VoiceAssistant, skip links work exactly as intended! What can you do? Solving this bug is mostly up to browser and screen reader vendors. So we hope you’re listening Google, Apple, Mozilla and the rest. But there are some things you as a site owner can do while we wait for a more robust solution. We created and played around with this codepen where you can test skip links that reference different types of elements like headings, `<main>` ,`<div>`, and more. We found cases where including the attribute `tabindex="-1"` on the element you reference would solve the issue, but unfortunately only for iOS users. Here’s how: `Skip to main content //Menu and other stuff users might want to skip ...` … So simply adding `tabindex="-1"` to the element you’re skip link points to is the best solution we can offer at the moment. It won’t make your skip links work for all your screen reader users, but at least you’ll have catered the needs of the majority of them. See update 3 below for problems with this solution and other, better ways to solve this Update 1 – a better solution! A lot of clever people read our articles, and it turns out that there’s an even better solution. Paul J. Adam (@pauljadam) uses javascript to move focus to the first heading. Like this with jQuery: `$('#skip-link').click(function(e) { e.preventDefault(); $(':header:first').attr('tabindex', '-1').focus(); });` It works splendidly! Check it out on Paul’s website. Update 2 – Vanilla javascript solution Ben Buchanan made a regular “vanilla” javascript solution from Paul Adam’s solution above, since many people don’t use jQuery. And he was also kind enough to share it with us and the world, so here it is: Codepen – Working skip links using vanilla JS Mike Foskett also made a really nice Codepen: Mike Foskett’s skip links codepen Update 3 – A comment from gov.uk Anika Henke e-mailed us some great input: I’m a developer working in the accessibility team at GDS (the people behind gov.uk). I was made aware of your article about skip links and that it mentions gov.uk. We investigated the very same issue on gov.uk last year and I created a bug report for the iOS issue as it’s clearly a browser or screen reader bug. Your suggested solution introduces worse barriers, though. See our Pull Request about removing tabindex from main to understand why. To quote: “When clicking anywhere in the page focus will return back to the top. Consider a user interacting with an input field who clicks away from it to remove the focus style. Should they then hit tab they will be taken to the top of the page.” The JavaScript solutions are a bit better because they focus on a smaller element. But it is too specific. It is dependent on certain elements or IDs being present. Since ages I’ve been using a better fix in my personal projects which fixes all in-pages links, not just skip links, and removes the tabindex the moment the focus moves away. Thanks for that great input Anika! Hand tremors and the giant-button-problem Hampus Sethfors — Mon, 09 Apr 2018 07:37:36 +0000 In this article we’ll examine an overlooked accessibility problem that mainly affects users with hand tremors. It’s in almost every interface out there, but barely ever highlighted in accessibility guidelines or discussions. It’s also super easy to fix! We’re writing this together with Erik Zetterström of ICT Enablers. Erik has worked with accessibility products, services and standardization since graduating in 2003, with a Master of Engineering in Computer Science. A few years ago Erik was diagnosed with Parkinson’s disease. Have you ever clicked something by accident? Most of us have. Maybe as you tried to scroll on your smartphone while on a bumpy bus, train or car ride? Annoying, right! For a lot of people with hand tremors – caused by for instance Parkinson’s disease or essential tremor – unintentional clicks happen all the time. Especially while scrolling on a touch screen. If you think about it, touch screen scrolling requires a lot of fine motor control. You need to place your finger on the correct part of the screen, flick it at the right speed and in the right direction, and most importantly: keep it on the screen at all times during this gesture. Oops! I clicked it again Many web and app interfaces are designed in a way that causes big problems for users who have a hard time with this scroll gesture. Luckily, there are simple ways of making your interface more hand-tremor-accessible. Let’s dive in! A lot of sites and apps contain lists of clickable things, for instance products or news articles. These are usually placed back-to-back, with no space between the touch targets. Like this: Here is a video showing a user with Parkinson’s disease trying to scroll through such an interface during a user test we carried out a while ago. He speaks Swedish, so turn on the captions if you’re not one of the 10 million people who understands our fine language! If you look closely, the user is trying to place his finger between the news stories. He’s hoping the space is unclickable, so that an accidental tap while trying to scroll will not activate a link. However, every part of the screen is linked. It’s like the whole interface is one giant button – hey what a clever comparison, let’s add that to the title of this article! Here’s a quote from the video that explains the essence of it: They should add some space between the different objects so that I can put my finger down without activating something. – User with Parkinson’s disease The simple solution It would help enormously if there was just a little bit of space between each touch target in the list. Like this: Now users can place their finger in that unclickable space and accidentally tap without flying off to another page. A little space between the touch targets also makes the interface feel less crowded. Win-win! This is how it looks on our site, scrolling through our articles. Not too shabby, right? Hey browsers! You can help out too Another way of solving this scroll-conundrum would be for browsers to make it possible to have a scrollbar visible at the side of the screen on mobile. The scrollbar could be activated through the browser’s settings menu – or in some other smart way – so it doesn’t have to show all the time for all users. But wait! Why isn’t this in the accessibility guidelines? We don’t know. The Web Content Accessibility Guidelines (WCAG) do not include this problem. We can only speculate as to why. It might be because: Touch screen scrolling has only been around since the smartphone revolution, like ten years. Seems like long enough, but the WCAG is a standard and standards move at glacier speeds. The 2.0 version WCAG was released in 2008 and it’s not until the summer of 2018 – ten years later – that WCAG 2.1 arrives. There’s a lack of knowledge about accessibility issues that affect users with motor impairment. The WCAG is primarily focused on vision impairments and assistive technologies. Motor impairments are sadly not covered as well, which they’re trying to change but not succeeding with. For instance, for a long time it was looking like they would add a minimum touch target size criteria to the new 2.1 version of WCAG, at level AA. But sadly, last minute this criteria was bumped up to level AAA, basically meaning nobody will care about it since all legislations and requirements are concerned with level A and level AA. Whatever the reason, the lack of focus on motor impairments in accessibility guidelines is a big problem that needs to be addressed. Hopefully the folks working with the 3.0 version of WCAG are listening! Also, this illustrates the point we make time after time: you need to user test with people with disabilities. No checklist or guideline will ever be able to replace meeting actual users and watching them use your product (tell us if you need help with this). Let’s make the web more hand tremor friendly Thanks for showing an interest in accessibility by reading this article. Hopefully you’ll help out in making the web a little more inclusive. Make sure there’s some unclickable space on each screen, it’s as simple as that! Do you need help with your project? An embedded accessibility consultant can join your design or dev team to continuously test with real users and guide accessible solutions from prototype to launch If you liked this article, here are some others you might enjoy: Accessibility according to actual people with disabilities Practical examples of accessibility improvements Assistive technologies – The switch Text Splitting Causes Screen Reader Problems Daniel Göransson — Sun, 04 Mar 2018 15:41:18 +0000 I am a screen reader user, and I am annoyed! I repeatedly encounter the same problem on websites. It’s about text splitting up. Let me share my agony with you! The problem First a short background if you’re not familiar with screen readers. When navigating a web site on a touch screen, my screen reader – VoiceOver – will read what’s under my finger. It enables me and other people with visual impairments to use technology. What I should hear when touching a link with my finger is: The name of the link. What type of element it is: “link”. For instance: “Contact information, link”. However, sometimes I just get to hear what type of element it is, not it’s name. Just “Link”. Not very helpful. The 16 second video below is from a Swedish site, but I think you’ll get the point even if you don’t know Swedish. Notice how it just reads “Link” if my finger is on the right side of the elements – a bad user experience. If I touch the left side of the links, I get to hear the names together with the type of element – a good user experience. What’s going on here? Well, let’s take the last link in the example above. It’s made up of two parts: The name “Arkiv” and the link icon. `Arkiv` In the code, the icon is placed in its own span-element. A perfectly fine way to code your links. It should be read as one object, as the link-element is wrapping both the link name and the icon-span. But VoiceOver interprets it as two different objects if I touch the right span, rendering me confused. OK, so Apple should fix this? Yes, I wish. But I reported this error in 2012 and it’s still not fixed, so my hopes aren’t great. While we wait for Apple, there’s an easy workaround for developers to fix this on your sites. The solution: role=”text” We had a similar problem on our site with headings, but the solution I used will work for links as well. Let’s look at it. Here I’ve got an h1-element that looks like this in the code: `Digital accessibility, for everyone.` As you can see in the video below, the br-tag causes the screen reader to interpret the title as two separate objects, just like the span did in the previous example. I want it to read the whole heading to me at once. So to force a screen reader to interpret the heading as one object, I wrapped the text inside the heading in a span and added role=”text”. `Digital accessibility, for everyone.` And voilá, here is the result: Beware! Don’t put role=”text” in the heading-element. This would erase the h1-semantics, so it would not appear as a heading in a screen reader. Every element inside the role=”text” will lose it’s semantics. So you need to add a span within the element and put role=”text” in that span. Apple, if you’re listening, please fix this. But until then, developers, please do the visual impaired community a favor and check your elements with a screen reader and fix them if necessary. Update – questions and answers This post went a bit viral! Which is great, but I’ve gotten a few questions that I want to clarify. Can’t we just use aria-hidden on the icon? Yes, we can, in some cases! In my first example, the link-icon is unnecessary to understand the purpose of the link, so you can just use aria-hidden=”true”. But we’d like the recommended technique to work in as many scenarios as possible. So imagine the following case. You have a link or heading with three words, where the middle one is stylized. For instance: `Buy t-shirts now` Here, VoiceOver would announce them as separate links: “Buy link”, “t-shirts link”, “now link”. Now we can’t use aria-hidden since that would hide a word for the screen reader user. It would just say “Buy now link”, skipping the t-shirt part. However, using the role=”text” technique will work great in this scenario as well. Is this just a problem with explore by touch? To navigate with a screen reader you can either touch parts of the screen and have the objects you’re touching read to you – explore by touch – or swipe your way across the interface from object to object. I use explore by touch in my videos. One person asked if this problem only occurs if you explore by touch. However, sadly it happens both on explore by touch and when swiping. Why don’t you keep writing to Apple? Apple have actually answered me. They think this is a feature. It makes it possible to recognize that different words are styled in different ways. I think it’s a nice thought. But in reality, it’s not practical. For us screen reader users, it’s more important to get the whole sentence read than to recognize that something has a different styling. One idea would be to make the styling differences clear in some other way, like changing the pitch of the voice. Assistive Technologies – The Switch Hampus Sethfors — Mon, 19 Feb 2018 14:26:53 +0000 A switch is an assistive technology primarily used by people with motor impairments to access and control computers, smartphones, electric wheelchairs, smart home appliances and more. Let’s look at some switches in action and go through how you design switch friendly interfaces. So what is a switch? At its core, a switch is simply a way for a user to activate a control. This can be done in multiple ways, and different users prefer different switches. The classic example of a switch looks like a big round button: This type of switch can be placed in the users’ hands, by their head, elbows, feet or wherever they feel most comfortable with it. On the screen, there’s usually a focus indicator moving automatically across the different objects, and the user clicks by activating the switch. Some users have multiple switches and can use one to move the cursor forward and another for clicking. Video editor Christopher Hills has multiple switches placed on his head rest. Here’s a video where he shows how he uses his switches together with Apple Switch Control. World famous theoretical physicist Stephen Hawking used a handheld switch, or “clicker”, earlier in his life. But as his control of his hand muscles decreased due to his Amyotrophic lateral sclerosis (ALS), he now uses a “cheek-switch”. If you look closely, you can see it in the video below. It’s a black sensor just below his glasses. So he moves his cheek to activate the switch. On Stephen’s screen, a focus cursor will move across his computer’s interface automatically, and he moves the cheeck-sensor to activate the object in focus. Most operating systems integrate with switches right out of the box, with no need to download special software or apps. For example, Apple devices have a setting called Switch Control (Settings, General, Accessiblity, Switch Control) and Android devices have Switch Access (Settings, Accessibility, Switch Access). You can use a Bluetooth keyboard with an iOS or Android device to try it out yourself. Or buy a switch, the cheapest ones cost around € 100. Another type of switch is a “Sip-and-puff”. In this case, the users activate the switch by either inhaling – sip – or exhaling – puff. Usually these types of switches come with a lip-controlled joystick that moves the mouse cursor on the screen. Here’s how one of those products look, the Integramouse: Not only people with motor impairments use switches. Some people with intellectual or learning impairments can find keyboards or game controllers too complex. They use switches to play simple games, communicate using digital boards or quickly access their favorite sites. How to design switch-friendly interfaces Here are some things for developers and designers to think about when designing digital interfaces for switch users. Make your interface keyboard accessible. That is, make sure you can control it only using the tab, space and arrow keys of your keyboard. If that doesn’t work, then switch users most likely will run into trouble. Place key information, buttons and links “above the fold” – visible without scrolling. Scrolling usually requires a lot more time and effort for switch users. With iOS Switch Control, a user needs to activate the switch seven times to scroll: 2 clicks to see the interaction menu, 3 clicks to navigate and activate the scroll and 2 clicks to remove the menu. Don’t require hover, click-and-drag or other advanced gestures. Although most switch interfaces have functionality for these gestures, they take a lot of effort to carry out and many less tech-savvy users will not know about them. Use a large text size as default. Many switch control users physically can’t lean close to a screen to read tiny, italics text. Avoid time limits. It will take most switch control users longer to complete a form or navigate your interface. So avoid using time limits. But if you do, make sure to give the user a way of increasing the time and give them a warning long before time’s up. There are – of course – more things to consider when creating switch accessible interfaces, but I think that is enough detail for this introductory article. Get in touch if you want a more complete checklist on switch accessibility: [email protected]! Want to experience assistive technologies like screen readers, switches, and eye-tracking in action? Sign up for our interactive accessibility workshop! Hope you learned something new! Thanks for reading and leveling up your accessibility know-how! Title Texts Suck Hampus Sethfors — Thu, 08 Feb 2018 15:15:51 +0000 Many people I meet think title texts, also known as tooltips, improve both the accessibility and usability of their sites. They don’t. In fact, they can even cause problems. Let’s see why! What’s a title text? Here below is a link with a title text. Hold your mouse pointer over it for a while and a small text will pop up. That’s the title text. It’s added with the title-attribute in the link. Demo link with title This is how it looks: “Wait a minute” a lot of you will be thinking. “I’m on my phone, I don’t have a mouse pointer.” Great observation! It brings us perfectly onto our next topic… The problem with title texts 1. Title texts don’t work on touch screens Title texts only show up on hover, and you can’t hover on 99.9% of all touch screens. I think most people would agree that a design pattern that doesn’t work on touchscreens kind of sucks. 2. Title texts cause problems for screen magnifiers For users with screen magnification, title texts will often be somewhat of a bully. The title text can be cut off the screen because the user is zoomed in so far. When the user moves the mouse pointer to be able to see it, the title text will often disappear. More on this in our article How to make your site accessible to screen magnifiers. Another problem for users with screen magnification is that the title text can cover essential parts of the content. In the example below the title text for the image covers the link below it. You might be thinking: “Well, just move the mouse cursor.” Sadly it’s often not possible for users who are zoomed in very far and need to have the cursor where they are reading. As icing on top of the cake for this group of users, title texts will not be enlarged when you use browser zoom (control +). So yeah, title texts really suck for people with visual impairments. 3. Title texts don’t work with keyboard navigation Apart from not working on touch screens, title texts don’t show up for users who navigate with the keyboard or with the many assistive technologies for users with motor impairments. There are ways to make the title text show on keyboard focus, but it’s not there by default and almost no developers will add that feature. 4. Title texts require users to guess There is no way to tell if a link, icon, form field, button or other element has a title text before hovering over it. Most users will not bother to waste energy hovering over something to possibly get help. In the words of usability guru Jakob Nielsen: the interaction cost is too high. 5. Title texts require users to wait Not only does the user have to guess if there’s a title text, they also have to wait a second before it possibly shows. Users are usually in a hurry when navigating the web, so most won’t stop and dwell. 6. Screen readers read title texts inconsistently Many users with visual impairments use screen readers to navigate the web. Some screen readers will read title texts. Some will not the read title texts. Some will pause before reading them. Some have a setting that the user can enable to read them, but most will not know of that setting or bother activating it. The point is, title texts are handled differently and you can’t rely on how it’s conveyed to the user. Don’t trust me? David Ball of @silktide wrote this nicely researched piece on the same subject a few years ago: I thought title text improved accessibility. I was wrong. He asked html-expert Jeffrey Zeldman on his thoughts on title-texts. @silktide No! Do not use. — zeldman (@zeldman) December 12, 2012 Web accessibility guru Bruce Lawson isn’t a fan of the title-text either: @silktide kill it with fire. Or, as Bim, a blind screenreader user with RNIB would say: http://t.co/y6tN6UZU — Bruce Lawson (@brucel) December 12, 2012 Also, here’s another nice article on title texts: Don’t rely on the title attribute for accessibility. What should I use instead of title texts? Well, just make sure your link and button names clearly describe where they take your user and you’ll be fine. Also, write text labels for your icons, then you’ll not need to worry about title texts. Don’t confuse title texts with alt-texts. Alt-texts are very important and don’t suck at all: Alt-texts: the Ultimate Guide What about iframes? Some accessibility experts say there’s one exception where they recommend using the title text: iframes. First off: don’t use iframes unless you really have to. They can really confuse screen reader users. But if you use them anyway, just add an aria-label that describes the iframe’s content instead of the title attribute and this conundrum is solved. Other things that suck This was our third article on the topic of things that suck. You should check out our other two master pieces: Disabled Buttons Suck Captchas Suck Hope you enjoyed! Paying Employees to Work on Open Source Projects Hampus Sethfors — Thu, 18 Jan 2018 09:41:11 +0000 Open source is awesome and even though we’re a startup we’ve found a way to pay our employees to contribute to the community. Here’s how and why we do it. Photo: Samedaypapers We, like most other companies that build software, base a lot of what we do on components and frameworks that were built in open source projects. Even though we are a small (but growing) startup – five employees at the moment – we wanted to find a way to actively contribute to the open source community. We were inspired by how Futurice sponsors free time open source activities, and set up our own version of it. The deal As an employee at Axess Lab, you get paid 15 € an hour for up to 10 hours a month for open source work if: It’s done outside of working hours The project or task is related to accessibility, inclusive design or something similar The employees have a time code in our time reporting system where they report the open source work and add a copy to a relevant pull request or commit. That’s it. We don’t make it more complicated than that. What’s in it for us? Why would a startup like us do this. Well, we see many benefits: It makes our employees even more skilled at accessibility. It’s a good way to give something back to the open source community It increases our chances of recruiting great people to our company It aligns with our company’s vision of creating a more inclusive digital world It makes our employees happy Want to know more? Hopefully this will inspire some other companies to set up something similar. If you want to know more, get in touch with us by mailing [email protected] or tweeting @axesslab. You’re extra welcome to message us if you live in Sweden and are interested in working with us to make the digital world more accessible! Our Top Articles 2017 Hampus Sethfors — Fri, 29 Dec 2017 12:01:13 +0000 It’s been a great 2017 at Axess Lab! We celebrate by listing our most popular articles all year. The podium Here are the top three. Congratulations! Accessibility According to Actual People with Disabilities 43 000 page views “If you have a disability, what’s the hardest thing about browsing the web?” We sum up the answers to a viral Twitter thread. How Icons are Ruining Interfaces 18 300 pageviews More and more designers are using icons in the wrong way. And it’s hurting both the usability and accessibility of interfaces. Alt-texts: The Ultimate Guide 15 200 pageviews Practical tips on how to craft the perfect alt-texts. We also go through when to – and not to – use them. Happy losers Here are some articles that fought hard but just missed the podium. Ouch! Disabled Buttons Suck Showing buttons as disabled might seem like a good idea. It is not. Here’s why disabled buttons suck and what to do instead. Fonts Don’t Matter If you’re an art director, you might want to sit down for this. Here’s why fonts are overrated and what actually matters for readability. Top 7 Free Color Contrast Checkers Seven great free tools that help you measure color contrasts and create beautiful, accessible color schemes Practical Examples of Accessibility Improvements Hampus Sethfors — Thu, 28 Dec 2017 16:33:08 +0000 “It would be great to see actual examples of accessibility in action. Like before and after accessibility improvements.” I got this great comment from a woman in the audience at a meetup. So let’s make that idea a reality! Offer alternatives Accessibility is a lot about offering people alternatives. Here’s an example from “real life”. When I was user testing with people with disabilities, this slider proved to be an obstacle for people with motor impairments. It was difficult to set it to the specific value the users wanted to. We solved it by offering an alternative. Users can now either use the slider or input the numbers directly in the input fields. This turned out great for mobile users as well. Their fingers were previously covering the value under the slider as they were adjusting it. Now they could see it above the slider in the input fields as well. A win for everyone. Here are some other examples of offering alternatives to users: Instead of forcing people to call customer service, offer an alternative to write in a chat or email. Instead of forcing people to understand a diagram, offer an alternative to see the data in a table: Instead of forcing people to read an article, offer an alternative to watch a video: Note that it’s the combination of alternatives that’s the key. Not just a video or just text, but the combination of them. Let the user choose! Colors There are two main things to keep in mind when it comes to colors and accessibility: color contrasts and not relying solely on color. Color contrasts Good contrasts between text and background is important to make your content accessible to low vision users, or users who have sunlight reflecting off their screens. Here’s an example of light gray text on Squarespace that doesn’t fulfill the contrast guidelines in the Web Content Accessibility Guidelines (WCAG): A normal contrast failure is for link colors. Mediatemple have links that are far from acceptable: To give you a feel for how little it takes to make your contrast sufficient, here is an example of failing contrasts for both the gray text and blue link, and an example of sufficient contrasts for the gray text and blue link. You wouldn’t believe how hard I sometimes have to fight with art directors to get them to increase the contrasts to an acceptable level. Even though – in my view – everyone benefits and there’s not that big a difference aesthetically. Or is it just me? Anyway, it’s easy to measure contrasts yourself. Here are some free contrast checkers we recommend! Don’t rely solely on color Some people with color vision deficiencies can’t tell different colors apart. Here’s an example that would create problems: Simply labeling your colors is a way to make color pickers accessible: A common fail to this criteria is links that are only blue: Viewing this in grayscale makes it clear why this is important: Some ways to make your links pop out is underlining them, giving them link icons or making them look like buttons: If you want to know more on this subject, check out our article on color blind accessibility. Keyboard accessibility Some users with motor impairments navigate using their keyboard. Many assistive technologies like switches, magnification and screen readers also rely on keyboard accessibility. But what does it mean to make your site or app keyboard accessible? Focus indication Make sure that it’s clear which element has focus when tabbing around in your interface. The default focus indicator varies between browsers, but it’s often not very easy to spot. Some sites, like Only.in, have even removed the default focus indicator. Most likely because someone googled how to remove it because they thought it looked ugly when focus was on their search field. On gov.uk focus is indicated with an orange background that really stands out from the surrounding: So design a clear focus indicator and implement it using the :focus selector in your css. Skip-links Skip-links are a bit magical! They don’t show up for most people, but if you navigate with a keyboard you’ll find them very helpful. They are made visible only when they receive focus and basically provide a shortcut past all the links in the site header and menus, so you quickly can get to the content of the page. Here’s a skip-link in action at www.starbucks.com. Try it out yourself by going to Starbucks and pressing the tab key on your keyboard until you see it (in any other browser than Safari, where keyboard navigation first needs to be activated in settings for some reason). Screen reader accessibility Making your site or app accessible for users with visual impairments who use screen readers is a lot about coding correctly and following the html-standard. For example: instead of building buttons and links out of spans, use the button and link elements. Another thing you need to do is add alt-texts to images, which conveys their meaning to people who can’t see them. Editors need to learn how to do this in their Content Managment System. It takes about 5 seconds for each image. You should check out our Ultimate Guide to Alt-texts! Accessibility is a lot about simplicity and usability. Make your interface intuitive and use a clean layout and you’ll help all users, including screen reader users. Sometimes online shopping is more accessible than health care, simply because e-commerce sites focus so heavily on usability and streamlined design. Wrapping it up There is of course more to accessibility than I’ve listed above. But the point is that it’s not rocket science. Also, making your site or app accessible does not mean you have to make it boring and remove all colors, images and videos. Accessible sites can – and should – be made awesome and beautiful! If you want our help achieving this in your projects, let’s work together! Finally, I’d want to recommend the world’s best tumblr: a11ywins.tumblr.com It’s a collection of accessibility wins – that is, examples of awesome accessibility solutions on sites and apps. Jump over there and read it all! “Our Users Have no Disabilities” Daniel Göransson — Sun, 17 Dec 2017 11:45:08 +0000 There are a lot of unfortunate misconceptions about people with disabilities. Many trickle down into IT-teams who use them as arguments not to care about accessibility. So it’s time to set some things straight! Things we hear all the time When we at Axess Lab are out consulting or speaking about accessibility, time and time again we hear the same types of arguments from people who are not very keen on focusing on accessibility: I work on an intranet. We don’t have disabled employees. Our customers are athletes, not handicapped people. I’m building a site for this upcoming movie. Obviously, blind people are not part of my target audience. The many, many people who think or say these kinds of things probably don’t do it because they are pure evil! Instead, the comments are likely to stem from a lack of knowledge and preconceived ideas about disabilities. So, let’s bust some myths and straighten this thing out once and for all! All disabilities are not visible Most of the time, you can’t tell if a person has a disability just by looking at them. Even though you might not think you have colleagues or users with disabilities, you probably do. Here are some disabilities that usually are hidden: Autism Adhd Hard of hearing Dyslexia Color vision deficiency Chronic pain Mental illness Many more Even some disabilities that you think are visible are not always. I am legally blind. If I don’t chose to tell people, they usually have no idea. Just by looking at me, there’s no way to tell. Here I am, roller skating! So guess what! You’ll probably pass a lot of people today that have disabilities, but you won’t even notice! And me roller skating leads us nicely onto the next topic… People with disabilities have interests too There are a lot of preconceived ideas about what people with disabilities do. We do everything. Or nothing. Or exactly what we want to. And we want different things, just like everyone else. Some of my favorite interests are: Video games – not special games for special people. Right now I’m playing Tekken 7, accessible to me through great sound design and contrasts. Sports – I both like to watch sports and play it myself. I play a type of soccer that involves eye shades and sounds. Here’s a link to the best goals in the 2016 Paralympics. Movies – Contrary to popular belief, many blind people enjoy movies. I use a combination of the little sight I have and audio descriptions that describe what’s happening, like who’s beating up whom in a fight scene. I have friends who are blind. Some hate sports and don’t do video games. Some love them like me. I know people with hearing impairments that love music, theatre and musicals. The point is we are different and have many interests! This means that we buy soccer shoes, book movies tickets and hang out on video game review sites. And skateboards! So let’s agree on that you can’t assume that their target audience has no disabilities. We are everywhere! Young people have disabilities too Many people tend to believe that disabilities is something that only elderly people have. It’s true that many disabilities are more common among the older population. But not all. Think of dyslexia, color vision deficiency, autism and adhd. They are just as common in all age groups. And there are, of course, young people with disabilities like vision and hearing impairments, even if they are more common among elderly. We would also like to congratulate you, our dear reader. You’ve just set a personal record! You’ve never been older than you are right now! And you’re getting older every day. Design for your future self! Employed people have disabilities too One of the most common situations where we hear excuses for not caring about accessibility is when it comes to intranets, administrative systems or any other system that is used by professionals. There is a widespread misconception that people with disabilities don’t work. At least not at your own office. This, of course, is false. People with disabilities can be found at any workplace. Sometimes you don’t know about it, because many disabilities are hidden. But trust me, we’re there! And even if you don’t have a colleague right now who is, say, blind, that doesn’t mean you can assume you never will. Let’s say a highly qualified individual is applying for a job. She’s better than all the competition and would be perfect for the position. However, she happens to use an assistive technology. And your intranet and administrative systems are not accessible at all. Because of that, she can’t do her job and you hire someone else. In that scenario, apart from the terrible discrimination, you also lose a great recruitment. So don’t just make your external website accessible. The inside counts as well! You can’t know your user’s environment Impairments can be situational. A user without a disability could be stressed, tired, drunk (maybe not for intranets..) or using their device in sunlight. Anyone could be riding the subway on a poor internet connection. All users have disabilities sometime in their day-to-day life. In web analytics, there is no good way of examining if the visitor has a disability or is using an assistive technology. So you can’t know if a user is using a screen reader or an eye tracker to navigate. So even if you know that over 90% of your users are using a large screen, you can’t assume that everyone is using a mouse. Which in turn means you can’t rely on hover to navigate. Tech enables Digital services like apps and web are often more important to people with disabilities than the so called average Joe out there. Let’s look at an example. Stephen Murray crashed on his BMX-bike and was paralyzed from the neck down. He now uses an eye tracker to control his technology. He runs his own company, pays his bills and communicates with friends and family, all by only using his eyes. Tech has enabled him to do all this, and to be independent again. But Stephen Murray is also very reliant on the accessibility of the services that he uses. More so than most other people. Say you want to book a meeting room. If the booking system is a piece of paper by the meeting room, most people could use it, even if it would be a bit annoying not to be able to do it from the computer. Stephen wouldn’t be able to book it at all independently. The same goes for other people with disabilities, like someone in a wheelchair who might not reach the paper, someone with a hand tremor who can’t write with a pencil or someone with a vision impairment. An accessible digital booking solution is crucial fort these users, but benefits everyone. One last tip Now you’re hopefully equipped with enough arguments to convince your colleagues and bosses to prioritize accessibility. People with disabilities are everywhere and inclusive design is important for everyone. No matter what prject you’re in Here comes our last tip! The best way to get empathy and understanding from someone is to let them experience accessibility issues themselves. One way is to get Funkify – the disability simulator, a free Chrome extension that we’ve been a part of building! Another way is to let us meet your team. We’ll let you use your site or apps with screen readers, magnification, eye control and a lot more. An empathy lab that will convince even your most stubborn colleague! Thanks for reading and keep on spreading accessibility awareness! 5 Ways to Make Your App More Accessible Guest — Tue, 21 Nov 2017 08:10:44 +0000 Users spend a large portion of their days in apps. However, there is not yet as much focus on app accessibility as web accessibility. It’s time to change that! This is a guest post by Bryn Gelbart from Fueled, who builds apps with accessibility in mind. Why care about app accessibility? One billion people, or about 15% of the world’s population, live with some form of disability. Combine that with the fact that smartphone and app usage is booming in all parts of the world, across all ages and abilities. This means that in order to truly maximize the impact, reach and profit of your mobile app you need to make sure it is easy to use for people of all ability sets. It must be accessible. An app can do this by addressing the core accessibility checklist that the Web Accessibility Initiative puts forward. But if you don’t have time to read through the long checklist, here are five practical ways to improve your app’s accessibility. 1. Design for colorblindness Approximately 8% of men and 0.5% of women are color blind according to visiontechnology.co. This comes close to 300 million people worldwide, a majority of those being caucasian men. That can be a bigger issue than you think considering the demographics of the tech industry. A core accessibility principle is to not rely solely on color to convey meaning. Don’t just make error messages red. Also add an error icon to make it clear to everyone. It is imperative to use easily distinguishable colors. Avoid mixing green and red, as that is the color combination that most people with color blindness can’t tell apart. You must make your backgrounds pop from your foregrounds, so no crucial information is lost on the color blind user. For example measure contrasts and make sure they comply with the color contrast threshold in WCAG (Web Content Accessibility Guidelines). Also, don’t have too similar hues of the same color, as this is likely to be seen as the same by many colorblind users. The screenshot from Candy Crush Saga below uses distinct shapes and varied shades to cater to colorblind users: 2. Provide captions and alternative text Captions for video are essential for users with hearing impairments. Providing this alternative also benefits all users, as closed captioning can be useful in many situations, including commutes and while using your device in loud environments. Additionally, people who rely on text-to-speech voice technology are a demographic to consider when talking about accessibility. All photos and icons should have alternative text that can help all users get the full experience. To add this alternative description to images and icons in apps, refer to these guides provided by Google and Apple: Android Accessibility iOS Accessibility In short, for Android use android:contentDescription and for iOS use the label attribute. Another good guideline is to complement icons with text. That way, it’s more clear to everyone what the icon means. In the Remente app, each icon for feeling is complemented with a number from 1 to 5. Also, the thumbs up and thumbs down icons have a label “Negative” and “Positive”. 3. Readable and distinguishable interface Making sure displays on your app are easy to see goes beyond proofing for colorblindness. Giving your text a strong brightness-contrast and using larger font sizes is a good place to start. It is also important to differentiate clickable content. Hyperlinks and buttons that take the user to other screens should be both colored differently and highlighted with non-color characteristics, like a border on the button, a link underline or a link icon. Also, keep formatting consistent. Users with cognitive limitations may become confused if components are formatted differently on different pages. 4. Be aware of seizure inducing elements According to stats from Healthline, about one in every 26 people will experience recurring seizures in their lifetime. The causes range from epilepsy to other less common conditions that can come into effect without prior warning or experience. Avoid putting in features that frequently flashes on the screen or makes use of the camera flash on devices. Alternating colors or patterns are a bad call as well. If these are features that you must include, provide a warning and an option to disable them. 5. Multiple language settings While it does not fall into the same category as these other tips, it is important to recognize when your concept may be applicable to a non-English speaking audience. Translating all text is an easy way to expand your accessibility. On mobile these options will often be automatically changed based on user settings. An additional feature for multilingual users could be a slick drop down menu built into the interface that can give language options from within the app. Thanks Fueled It’s nice to see more and more companies spreading accessibility awareness! Thanks Fueled for writing this post. And no, we didn’t get paid to feature this. We just like working together with people who work with accessibility in mind! iPhone X – Welcome Screen Inaccessible to Blind Users Daniel Göransson — Fri, 17 Nov 2017 13:25:05 +0000 I just got the new iPhone X. To my surprise, the first impression was not good at all for me as a user with a visual impairment. Apple usually don’t let me down, but now they seem to have made blunder. Explain what happened in text, please! Ok, so I use a screen reader that speaks information about the elements on the screen as I hold my finger over them. The first screen was totally blank to me, I got no information on how to proceed. Visually, there is text there, but I can’t see it and it’s not read with the screen reader. So it doesn’t help me. I couldn’t swipe across the screen to find elements to interact with, which I usually can. After struggling a while I found an element at the very bottom of the screen that said: “Home indicator, dimmed. Swipe one finger up from the bottom of the screen to go home”. I tried it even though I don’t want to go to the home screen, but it was the only thing I could do. That led me to the installation process. So I made it, but the experience was far from pleasant. I think many people with visual impairments will get stuck here and have to ask for sighted help, compromising their independence. Apple, hope you’re listening. Fix this please! Captchas Suck Hampus Sethfors — Thu, 02 Nov 2017 16:01:07 +0000 Captchas were invented to protect websites from spam. However, like the well-meaning invention of nuclear fusion, captchas too got some unethical and destructive side effects. Here’s why captchas suck and what to do instead. Introducing the evil Nobody likes captchas. They are at best an irritating, conversion-killing step users need to get past. At worst, they can be a complete roadblock to people. I’ll share my true feelings towards captchas at the end of this article in a poem. Yes – a poem. I’ve heard poems are good for expressing feelings. Anyway, first I’ll be more objective and describe what they are and why they do damage. Captchas are meant to tell humans and computers apart. The whacky name is an acronym for Completely Automated Public Turing test to tell Computers and Humans Apart. They come in some different shapes and forms. Here’s one that everyone would struggle with: Here is a captcha to sign up to a movie website, which – at least – is a bit whimsical! Captchas are seriously inaccessible Imagine that you’ve spent what felt like an eternity filling out a form. Finally you get to the end of it and find this question. Prove you’re not a robot. Click on the animals in the image below. You can’t see any animals, but luckily you find a give-me-a-new-challenge-button. You click it: Prove you’re not a robot. Solve this simple math problem: These may be silly examples, but it’s a pretty accurate experience of how many people with disabilities experience captchas. For users who are blind or have visual impairments, these types of image-captchas are usually impossible to solve: For users with learning impairments, a math problem like 21+42 can feel like a complex integral: For users with dyslexia or other reading impairments, blurry images of squiggly text can be impossible to solve. Users share their feelings Here are some users – with and without disabilities – expressing their not so loving feelings towards captchas on Twitter. https://twitter.com/megsiobhan/status/841296437153525765 https://twitter.com/krrnlyd/status/925985592160133120 @n5up I'm trying to contact you via web for ask a question but I can't 'cause I'm blind and I can't resolve the form CAPTCHA.Please help me — EA3GZA (Miguel) (@ea3gza) August 22, 2017 https://twitter.com/thejoycean/status/822981228408274944 As to what drives her nuts, non-accessible captchas are the top. It can severely limit which services are available to her. — Totally Not a Giant Bug in a Hat (@DannyDoesCode) June 3, 2017 Dear @Audible_com, introducing a CAPTCHA during iOS app login process is completely inaccessible and useless. #a11y — Pratik Patel (@ppatel) March 25, 2015 Stupid captcha is blocking me from completing AWS registration!!! arghhh i hate captchas — José Rodrigues (@jrocharodrigues) October 23, 2017 No, Google’s new ReCAPTCHA is not good enough You might have come across the “I’m not a robot” captcha: It’s not as bad as the standard captchas. But it’s still bad. People with assistive technologies like screen readers often report that they get classified as a bot and need to solve a regular, inaccessible captcha. Here is a video of a screen reader user trying to get past the captcha and failing. Get ready for some quick robotic speech. It can be hard to understand what’s going on if you’re not used to it. Also, here’s a robot beating a captcha No, the audio alternative is not good enough Many captchas offer an audio alternative. Try listening to the next one you come across and you’ll understand why it’s not good enough. It can be really, really hard to hear the message, since it’s got to be distorted enough that computers can’t figure it out. Another problem with the audio captcha is that the icon to switch to the audio captcha is usually really small and difficult to find. Screen reader users also tend to struggle as the audio starts playing before they’ve found the field for inputting the text. Focus should be put on the field automatically, but usually isn’t. A few years back, the White House had a CAPTCHA that prevented blind people to sign a petition for an international treaty that was supposed to help the blind. Here’s what they had to say about the audio captcha: An audio code option — meant to help the blind complete the Captcha — is incomprehensible, according federation spokesman Chris Danielsen. And that same flawed audio code system is in use for people who wish to write the White House an email with any suggestions or complaints regarding the “We The People” site. Captchas hurt conversions So captchas exclude many users with disabilities. This should be the only reason you need to seriously question their existence. But let’s look at another serious problem: it’s a conversion rate killer. Everyone struggle with captchas, not just people with disabilities. Many have conducted A/B tests and shown how they hurt conversion rates. Webnographer conducted an online usability test where only 62 percent of users completed Captcha on their first try. 23 percent gamely struggled through multiple attempts before succeeding, but 15 percent gave up entirely. – Do the new Captchas Affect Conversion Rates (pagewiz.com) They ran the test until 99% confidence level was achieved. The form with a captcha converted at 48% whilst without it converted at 64%. A 33% increase in conversions! – Web form optimization (acquireconvert.com) So – not surprisingly – captchas will lower your conversions. That – to most organisations – means less revenue. Another awesome reason to seriously question captchas. What to do instead Throw it out The first thing you should consider is to just not have a captcha. Sifting through SPAM is irritating and time-consuming, but it’s better to get more SPAM and conversions than not to. – Why Your Captcha is Killing Your Conversions (medium.com) Having an accessible site with high conversion rate might be worth the spam. Also, there’s something iffy and unprofessional about web site owners putting the burden of their spam problems on their users. Solve it “on your side” instead. Don’t make users take responsibility for our problems. – Beyond Captcha (sitepoint.com) Replace the captcha with an accessible alternatives There are ways to verify your users without using a captcha. Here’s one example that allows users to skip the captcha: Check out these articles on Captcha alternatives: 9 Captcha Alternatives That Won’t Wreck Your UX (dtelepathy.com) Not all of the 9 methods are accessible, so focus your attention on number 3 – “Biometric security”, number 4 – “Text message verification” and number 6 – “The honeypot method”. Think Your Site Needs A CAPTCHA? (usertesting.com) Same as with the previous article: not all alternatives they suggest are accessible. Focus your attention on “Honeypots”, “Timestamps” and “Verified sign in”. A final poem to captchas So here’s what I promised at the beginning of the article. Be advised, I haven’t written a poem since I was in the eight grade. But I feel it’s time. I’ve got some strong feelings I need to express. No it doesn’t rhyme. And excuse the harsh language. Anyway, here goes! Dear captcha. They say everyone is good inside. But you are pure evil. The dark side of cyberspace. The Voldemort of the web. So duck you, captcha. Duck your squiggly faded tilted letters. Duck you for making users squint and curse. Duck you for excluding users with disabilities. You inaccessible, abelist piece of sh….shoe. A blocker to people with vision, reading or learning impairments. You are to accessibility what cigarettes are to lungs. You are technological discrimination To be fair, you’ve made one accomplishment. You improve spam robots’ letter recognition. Maybe one day that can be used for something. Other than ducking up people’s life. Developers, web designers, user experience professionals. You’re smart, creative, empathetic people. Google “captcha alternatives”. Start questioning them. You can do better than a captcha. Trends That Exclude Hampus Sethfors — Wed, 18 Oct 2017 12:04:41 +0000 Jumping on a new trend is risky business, both in fashion and web design! Here is why trends often hurt the user experience and exclude users with disabilities. I’ll also go through what you can do to avoid this from happening. Trend #1: Bright and light For a while now, it’s been considered modern to design things that are difficult to see. It’s a strange trend that’s causing problems for all sorts of users. Let me walk you through some troublesome bright and light trends out there. Thin, small, grey font Slim, tiny, grey letters are popping up in interfaces all over the web, forcing users to strain their eyes while reading. Companies like Squarespace are even winning awards for this kind of unsightly design: Running this interface through the disability simulator Funkify, this is what the interface above looks like with blurry vision: Not very pleasant, right? Nobody likes to strain their eyes when reading, but this trend is especially hurtful to some user groups: Users with small devices People who are outside in bright sunlight Elderly users People with low vision When asked what causes accessibility problems on the web (our full article: Accessibility According to Actual Users with Disabilities), quite a few people brought up this topic: Nearly blind in my left eye. Tiny, thin font with low contrast to the background — Andrew So (@AndrewDixonSo) 3 juni 2017 I know what you’re thinking: It’s Apple’s fault! Yes, Apple introduced a thin font in iOS a couple of years back and they used grey text color a lot in their designs. However, they made sure the grey had a sufficient contrast level (how to check color contrasts) and the thin font wasn’t measured in nanometers. The problem was that when other designers jumped on this trend, they made the grey color brighter and the letters thinner. Suddenly the text was only readable by designers with 52 inch retina displays and predator birds. That’s why it’s so nice to hear that Apple is ditching it’s thin, grey fonts. Here’s a comparison between the old and new phone interface: So Apple is moving away from the thin, grey trend. You should too. Bright color schemes Many users with disabilities struggle on the web because of contrast issues in trendy interfaces. Lack of contrast between font color and background color. Photo backgrounds that overpower the text on top of them. — Megan Lynch (@may_gun) 4 juni 2017 One common offender is white text on brightly colored backgrounds: The color contrasts between the text and backgrounds above are terrible and far below the accepted contrast level in the Web Content Accessibility Guidelines (WCAG). Like the tweet above said, another common contrast problem is when text is placed right on top of images, which is trendy now. So start measuring contrasts and make your content easy to read for all your users. Ghost buttons Ghost buttons are transparent, thin buttons that have become popular lately. Like the name suggests, it’s quite a frightening design trend! The background overpowers the important content, making the buttons harder to spot and read: Make buttons stand out. It improves usability, conversions and accessibility. I think it’s time to stop scaring users away with ghost buttons. Trend #2: Motion Motion in interfaces is one of the top things that causes frustration when user testing with people with disabilities. It’s extra irritating for some people with cognitive disabilities, like adhd and autism. ADHD: If there’s a “subtle” animation always running, I cannot focus. Biggest offender: https://t.co/KgfCA4a7lB‘s header gradient — Taylor Hunt (@tigt_) 3 juni 2017 Assuming ADHD counts, it’s hard to locate content on overly busy pages and animations are a nightmare of distraction. #clickthemonkey — mkb (@mojinations) 4 juni 2017 related, I’m also autistic and can get frustrated with, or repelled by, glitzy mouseover effects/animations, sudden autoplay, etc. — back at the holler (@elementnumber46) 3 juni 2017 Let’s look closer at two motion trends that are annoying users: parallax scroll and image carousels. Parallax scroll Parallax scroll is a technique that became popular recently. To highlight how terrible this design trend is, I give it two poop-emojis instead of just one. Don’t you just love coming to a site to realize they’ve hijacked your scroll wheel? So that when you scroll, strange things happen on the site. You’re not alone in thinking that’s frustrating! Here’s an example where animations start cluttering the interface as the user scrolls: https://axesslab.com/wp-content/uploads/2017/10/parallax2.mp4 It might look cool at a glance, but after a few seconds it gets really annoying. Not many users like it and some even get seasick, especially people with balance disorders. Try the madness yourself at parall.ax. Image carousels Image carousels is another motion trend you should avoid, and something that the user experience (UX) community has warned about for years. Sadly, there are still plenty of sites that use them, creating distractions for users who are trying to focus on reading the site’s content. Why are carousels bad? I’ll let my favorite site on the web tell you the answer: shouldiuseacarousel.com. Trend #3: Inaccessible social media posts In feeds all across social media platforms, we’re seeing posts that exclude users with low vision or reading impairments. Let me take two examples. Images of text “Hahaha check out this epic meme:” Hilarious, right? Didn’t think so. The image is a meme that contains text, which will not be read by assistive technologies. So this is the experience many users with disabilities will get. Some social media platforms like Facebook will automatically describe what images might contain (like TV and dog indoors) to users with visual impairments who can’t see the image. But this description will not include the text in the image. So if you post an image of text, you should describe the text in the actual post. Let’s try it again: “Hahaha check out this epic meme! Making my dog watch commercials of the homeless dogs so he knows how good he got it.” Much better right? And more along the lines of the experience a sighted user has: The text description will also help users with reading impairments who use assistive technologies to read text. These assistive technologies will not be able to read image of text, so writing the text in the actual post is very helpful. If you’re interested in learning more about accessible images in social media, check out this article on accessible social media posting. Videos with text only An awesome trend that has started on social media is captioning videos. Facebook autoplays videos in your feed, and 85% watch videos without turning the sound on. So people have started captioning, which is great for everyone but crucial for hard-of-hearing or deaf users. However, lately this nice trend has shifted a bit too far. Now many skip the soundtrack altogether and only write text in videos. Here’s an example, in Swedish but you get the point: https://axesslab.com/wp-content/uploads/2017/10/lxI7vf.mp4 This excludes users who have a severe sight or reading impairment who depend on a voice narrating the video. So don’t just use text on videos. And don’t just use sound. Sound and text in videos are like pancakes and jam – awesome together! Trend #4: Icons only Icons without text labels have blossomed with the rise of smartphones. There is a major shortage of screen space on small devices, so the idea of replacing text with icons is obviously an attractive one. However, icons without text labels require users to do a lot of thinking and it’s causing significant usability problems. I wrote a whole article on that topic: How Icons are Ruining Interfaces. Apart from usability problems, the icons often cause specific problems for assistive technologies. When there is no text label, a screen reader user is dependant on the presence of a description of the icon in the code. This is not difficult to do for a developer, but many, many, many forget it. Then the screen reader will say something along the lines of: “Button 3” instead of “Button Play clip”. A young girl with a vision impairment I interviewed a while back told me about how her favourite app had updated, and suddenly there were no descriptions of any of the buttons. She had to get sighted help and memorise patterns to be able to using it: To start I press button 3, then 7, then 2. I change track on button 11. It’s difficult to find but I’ve gotten quite good at it! – Screen reader user Not a very nice user experience, right? So the icons-without-text-labels-trend is causing problems for all sorts of users. Why, oh why, does this happen? Here’s my theory as to why so many new trends exclude users. Go to Google Images and search for “web designers”. You’ll get a lot of results like this one: Young people sitting in front of giant monitors designing. This is how it looks in many tech offices around the world. Of course these people are not likely to react to problems with color contrasts or thin letters. Almost anything looks good on such an expensive screen! However, the users’ reality is often a lot different. Most designers and their colleagues are also very much more tech-savvy than the average person out there. Designers will often find new tech trends interesting, while most users just want interfaces to look and work like they’re used to. What should we do about it? Glad you asked! Here are my three best tips on reducing the excluding-trends-problem. 1. User test with a wider audience I assume you already user test your interfaces. Otherwise start right away! But either way, make sure you recrute a wide range of users to your tests, for example: Old people People who are not fluent in your language People with disabilities User testing with these user groups is extra important when you’re considering jumping on a new trend, to spot potential accessibility issues. If you make sure your interface works well for these users, you’ll also make it easier to use for everyone. Win-win! 2. Train your team The best way to create inclusive products is to educate yourself and your team on the topic of accessibility. Take a course and learn to see things from new perspectives. Make sure your developers know the techniques for coding accessibility into their interfaces, designers know how to check for contrasts and testers know the basics of using some assistive technologies. Accessibility is not a one man show, it’s a team effort! 3. Test with Funkify We’ve created a free browser plugin, Funkify, that let’s you simulate different disabilities, right on your site. View your site through a blurry filter, try navigating with a trembling mouse pointer and more. It can help you evaluate your interface in your day to day work! Here’s a demo of the plugin in action: https://axesslab.com/wp-content/uploads/2017/10/Använder-Funkify.mp4 That’s all, folks! Let’s work together to embrace inclusive trends that make the digital world a better place for all users! Alt-texts: The Ultimate Guide Daniel Göransson — Sun, 15 Oct 2017 16:44:25 +0000 This post contains everything you need to know about alt-texts! When to use them and how to perfectly craft them. By me, Daniel, a web developer with vision impairment who use a screen reader in my day-to-day life. My experience of images on the web I use a combination of magnification and screen reader when surfing the web. As a rule of thumb, I use magnification on larger screens and a screen reader on smaller devices. I, like everyone else, come across many images when surfing the web. If I’m using a screen reader I depend on getting a description of the image – the alt-text – read to me. Many times the alt-text is not helpful, often even a waste of my time because it doesn’t convey any meaning. Let me illustrate this on The Verge’s startpage. This is what it looks like for sighted people: Below is what I see. I’ve replaced the images with what my screen reader reads: Not very useful, huh? Here are some common alt-text-fails I come across: “cropped_img32_900px.png” or “1521591232.jpg” – the file names, probably because the image has no alt-attribute. “ ” – on every image in the article, probably for improving search ranking (SEO). “Photographer: Emma Lee” – probably because the editor doesn’t know what an alt-text is for. Alt-texts are not always this bad, but there’s usually a lot to improve upon. So whether you are a complete beginner or want to take your “game” to the next level, here’s our ultimate guide to alt-texts! What is an alt-text An alt-text is a description of an image that’s shown to people who for some reason can’t see the image. Among others, alt-texts help: people with little or no vision people who have turned off images to save data search engines The first group – people with little or no vision – is arguably the one that benefits most from alt-texts. They use something called a screen reader to navigate the web. A screen reader transforms visual information to speech or braille. To do this accurately, your website’s images need to have alt-texts. Alt-texts are super important! So important that the Web Content Accessibility Guidelines (WCAG) have alt-texts as their very first guideline: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose. – WCAG guideline 1.1.1 If you want a second pair of eyes, our WCAG accessibility review covers image alt-text quality and coverage. Or, if you prefer hands-on help while you ship, embed an accessibility consultant from our team to review alt-text patterns as you design. How do I add an alt-text? In html, an alt-text is an attribute in an image element: Most content management systems (CMS), like WordPress, let you create the alt-text when you upload an image: The field is usually named “Alt-text”, “Alternative text” or “Alt”, but in some interfaces it’s called “Image description” or something similar. Let’s create the perfect alt-text! Here are the steps to crafting fabulous alt-texts! Describe the image It might sound obvious, but an alt-text should describe the image. For example: “Group of people on a train station.” “Happy baby playing in a sand box.” “Five people in line at a supermarket.” Things that do not belong in an alt-text are: The name of the photographer. This is very common, but makes absolutely no sense. Keywords for search engine optimization. Don’t cram alt-text with irrelevant words you’re hoping to rank high on Google with. That’s not what alt-texts are for and it will confuse your users. Content of the alt-text depends on context How you describe the image depends on its context. Let me give you an example: If this image was featured in an article about photography, the alt-text could be something along the lines of: “Close up, greyscale photograph of man outside, face in focus, unfocused background.” If the image is on a website about a TV-series, an appropriate alt-text could be completely different: “Star of the show, Adam Lee, looking strained outside in the rain.” So write an alt-text that is as meaningful as possible for the user in the context they’re in. Keep it concise Reading the previous section, you might be thinking to yourself: “I, as a sighted user, can see many details in the image, like who it is, how it’s photographed, type of jacket, approximate age of the guy and more. Why not write a detailed, long alt-text so a user with visual impairment gets as much information as I do?” Glad you asked! Well frankly, you can also get the necessary information from the image at a glance, and that’s what we’re trying to achieve for users with screen readers as well. Give the necessary information in the alt-text, but make it as short and concise as possible. One of the few times you should write long alt-texts is when you’re describing an image containing important text. Ideally, you should not have images of text, but sometimes you need to. Like on some screenshots or photos of signs. But the general rule of thumb is to keep it concise and avoid a verbose experience. Don’t say it’s an image Don’t start alt-texts with “Image of”, “Photo of” or similar. The screen reader will add that by default. So if you write “Image of” in an alt-text, a screen reader will say “Image Image of…” when the user focuses on the image. Not very pleasant. One thing you can do is end the alt-text by stating if it’s a special type of image, like an illustration. “Dog jumping through a hoop. Illustration.” End with a period. End the alt-text with a period. This will make screen readers pause a bit after the last word in the alt-text, which creates a more pleasant reading experience for the user. Don’t use the title-attribute Many interfaces have a field for adding title-texts to images close to where you can add an alt-text. Skip the title text! Nobody uses them – they don’t work on touch screens and on desktop they require that the user hovers for a while over an image, which nobody does. Also, adding a title-text makes some screen readers both read the title-text and the alt-text, which becomes redundant. So just don’t add a title-text. When not to use an alt-text In most cases you should use an alt-text for images, but there are some exceptions where you should leave the alt-text blank. Important note: never remove the alt-attribute, that would mean breaking the html-standard. But you are allowed to set it to an empty string, that is: alt=””. Do that in the following cases. Repeated images in feeds Pretend you’re scrolling through your Twitter feed. Everytime you want to read a new tweet, you first have to listen to “Profile picture of user ”. In my opinion, that would be super annoying! Other examples of feeds are: A list of links to articles. Like the one on our page Articles. Chat or messaging feeds Feeds of comments So for an ideal user experience, leave the alt-text blank for images that are used repeatedly in feeds. Icons with text labels You should always have text labels next to icons. Assuming you do, the icon should not have an alt-text. Let me explain why! Let’s take a social media button as an example: If you would write an alt text to the Facebook icon, a screen reader would say something along the line: “Facebook Facebook.” Very redundant! OK, this is technically not about alt-texts but still important: make sure both the icon and the link text are in the same link-attribute, to get a smooth experience. Like this: `Facebook` Another common mistake with icons is on menu buttons: If the menu button has no visual text label – which, by the way, is really bad for the user experience – then it needs an alt-text (or another way of describing its function in code, like aria-label). Explain the icon’s function, like “Menu”. Don’t write “Three horizontal lines” or “Main hamburger”, which sadly are real examples I’ve stumbled on. If the menu icon has a label, you should leave the alt-text blank. I often find menu buttons which are read as “Menu menu”. Once I even came across “Hamburger menu menu”. Somewhat confusing wouldn’t you say? Images in links Usually an image within a link is accompanied by a link text. Like in the example below: In this case, the image and the link should be in the same link-tag in the html. In this case, you can just leave the alt-text blank. The important thing for the user is to hear the link text. An alt-text of the image would only distract by adding information that the user will not find necessary. The image is probably found on the page that is linked, and then you can give a good explanation of it in the alt-text. If you really, really have to have an image in a link without an accompanying text, then the alt-text should describe the link destination, not the image. Decorative images Preferably, decorative images that do not convey any meaning to the user should be placed as background images in css. It probably goes without saying, but this means you don’t need alt-texts on them at all. I’d classify most images that you place text on as decorative. You don’t need an alt-text on them. One example is the background image on Netflix’s startpage: Some images intend to give users a certain feeling, like an artsy photo of a sunny beach next to a section about “Vacations”. Do not make the mistake of classifying such images as decorative just because they are pretty! If an image enforces a feeling, then a description of the image should be set to allow screen reader users that same feeling. If an image is used to clarify a heading or label, like an image of a wooden table next to a heading called “tables”, it is not decorative and it should have an alt-text. It clarifies to users that we do not mean “tables of content” or any other kind of tables, but the ones you use to dine on. Such clarification should be given to all users. A good rule of thumb when it comes to decorative images is that it is better to have one alt-text too many than one to few. And if you have to analyze the content of a photo to determine if it is decorative – then it probably isn’t! (We don’t need to know what is in the netflix background image above to know that it’s decorative). Special cases Logos in the banner Logos in the banner almost always link to the websites start page. The opinions vary a bit on the topic of alt-texts for logos. Some say it should include the company name, the fact that it is a logo and the destination of the link. Like such: “Axess Lab, logotype, go to start page.” In my opinion, this is a bit verbose. Too much noise! Since my screen reader already tells me it’s an image and a link, I only feel I need to hear the company name. From the fact it’s an image I assume it’s a logo and from the fact it’s a link I assume it follow conventions and links to the start page. Svg Scalable vector graphics (svg) is an image format that’s becoming more and more popular on the web. And I love them! They keep their sharpness while zooming and take up less space so websites load faster. There are a two main ways of adding an svg to an html-page. Inside an img-element. In that case, just add an alt-text as usual: Using an svg-tag. If you use this method, you can’t add an alt-attribute because there’s no support for that. However you can get around this by adding two wai-aria attributes: role=”img” and aria-label=”. Actually, for the second case, you’re supposed to be able to add your alt-text as a title-element in the svg, but there is not enough support for that from browsers and assistive technologies at the moment. Can’t a machine do this for me? Although machine learning and artificial intelligence is improving quickly and can describe some images quite accurately, they are not good enough at understanding the relevant context at the moment. On top of that, machines are not good enough at deciding what is “concise”, and will often describe too much or too little of the image. Facebook has actually built in a feature that describes images automatically. But I feel like the descriptions are usually too general. One image in my feed right now is described as: “Cat indoors”. The actual photo shows a cat hunting a toy mouse. So I’m sorry, you still have to write alt-texts yourself! Thanks for making the web better! I’m happy you read this far! It means you care about making the web a better place for all users. Spread the knowledge and keep being awesome! Charming interfaces – make your users smile Hampus Sethfors — Sat, 30 Sep 2017 14:26:31 +0000 Using charm and humor in interfaces is a hugely underestimated technique that can make the user experience delightful, memorable and sharable. Here’s how to design, write and illustrate your way to smiling users! Hey…aren’t you accessibility experts? Yes, at Axess Lab we specialize in accessibility. But what does this post have to do with accessibility? Are you really allowed to use humor around people with disabilities? Well, I’ve carried out some rigorous research and it turns out people with disabilities actually enjoy having fun! Also, since technology is usually full of frustrating accessibility issues, I’d argue that people with disabilities benefit more from charismatic interfaces than most users. The polite registration form In this article I’ll give you a bunch of examples of charming interfaces, talk about the benefits of using humor and give tips on how you can succeed. But first, a short anecdote on how I stumbled on this topic. A few years ago, I was stuck at a login screen, trying a gazillion different email-password-combinations. My frustration grew for every incorrect-email-or-password-message I got thrown at me. You probably know the feeling. I finally gave up, cursed and went to their registration screen to set up a new account. I was in a terrible mood. I typed my first name in the registration form. A message popped up to the right of the field: “Nice to meet you!” It caught me off guard, got me smirking and made me curious. I quickly moved to the field for last name. Another reply from the form: “Great name!” Probably the first complement I had got all week! It. Felt. Great! I was probably humming Lego The Movie’s themesong “Everything is awesome” as I finished the last two fields. New delightful messages at each field. In less than a minute a form had turned my mood from “please kill me” to “I’m the king of the world!” For the first time ever I felt sad that I was done with an online form! How to use humor in interfaces This experience got me thinking about how we can use charm and humor to enhance the user experience. I started collecting examples of interfaces that do it well. It’s an underused technique, so it’s quite hard to find good examples, but I’ve been searching for a long time! So now I’d like to share what I’ve found and hopefully inspire some of you to work on making your users smile. I’ll give examples on three ways to use humor in interfaces: Make errors less frustrating Make users smile at details Convince users to do something they don’t really want to Let’s dive in! Make errors less frustrating One great place to start experimenting with charm is in error messages. Try to make your users smile with an illustration or unexpected wording. If you succeed, it will make your users more forgiving and they’ll hopefully find the energy to get around the error. Twitter shows an adorable illustration when it’s down due to overload: Google also uses funny illustrations if there are no results when searching for flights: Spotify cleverly complements the user instead of just saying “There are no lyrics available for that song”: Mailchimp hints of an evil twin if the username you want is taken: Basecamp has an illustrated boy pointing to each form field as you fill them in. He turns surprised when you make a mistake: A 404-page is an awesome place to add some humor. Olivia Ricci exploits every user’s strong feelings for cute kittens. Aww! Why do charming error messages works wonders? Well, users will likely be irritated when they see the error. Luckily, it’s close to impossible to stay angry when you’re looking at a cute kitten. If you’re interested in the science behind it: smiling and laughing releases dopamine, endorphins and serotonin which acts as mood-lifter and makes you relaxed and feel less pain. You’re basically drugging your users when they need it the most! Make users smile at details Another great place to use humor is in the details. Leave small treats for your users! There is a great site dedicated to this: Little Big Details. If you find this article interesting, you should definitely check it out. I got quite a few of my examples from it. In Spotify the time bar turns into a light saber in the Darth Vader playlist: Google Hangouts show charming animations when you type certain words, like “Happy new year”: Tumblr changes their wording depending on the age of the user: A Lego figure covers his eyes when you type your password on Lego Universe: Siri answers some philosophical questions in clever ways: Generally, you should not ask users for their gender if you really don’t need that information. But assuming you do, you can add some humor: Mailchimp shows a high-fiving chimp hand when you’ve shipped an email campaign. Clicking it – or high-fiving it back – makes the hand gradually more red. If you continue to click the hand, a high-five game starts in your browser. It made me wonder if Mailchimp’s developers have a bit too much time to spare…Or hey! Maybe they prioritize this type of content because they know it works! Here are some advantages of using humor in the details: It makes the interface sharable. The first thing I did when I saw the Mailchimp high five feature was to take a bunch of screenshots and share them with my colleagues on Slack. You’ll get your users to market your product for you. Genious! It makes the user feel special. It’s kind of like finding a hidden treasure! It builds a connection between the user and your brand. It makes users search for more special details in your interface. A quick search on Google and you’ll find tons of funny things to ask Siri. This can help build loyal users who share their findings. Convince users to do something they don’t really want to Increase conversion rates by manipulating with charm! It might sound a bit odd, but you can use humor as an energy-boost for carrying out tasks that users might not feel like doing. Songkick charms their users by offering something silly if they track 20 artists. Who wouldn’t put down the effort just to see the drawn picture they offer?! Nobody likes to wait, but as the old saying goes: “Time flies when you’re having fun”. There are some charming progress bars and loading spinners out there. Here’s a nice one by Dennis Perepelenko: OkCupid shows this epic banner to people who use ad-blockers to get them to donate. You will be much more inclined to do something if you’re in a good mood! That’s the simple brilliance behind this technique! Still skeptical? “I see your point, but I can’t design whimsical interfaces because I run a professional/business-to-business/multi-million-dollar/fortune 500/ company.” I understand your concern, but – at the risk of sounding like a polite Englishman – I beg to differ. People don’t stop liking humor just because they go to work or become rich CEO’s. It’s human nature to enjoy smiling. And to appreciate the person (or interface) that made you smile. As you’ve seen in the examples in this post, there are many ways to be charming. Everything will not work in every interface, but you should always be able to find a style that fits your brand. Everyone benefits from happy users! Create memorable experiences Lastly, I’d like to draw a parallel to one of the best articles on user experience I’ve read: User Memory Design: How To Design For Experiences That Last. In short, the article is based on research done by Nobel Prize-winning psychologist Daniel Kahneman and talks about something called the “peak-end rule”. The gist of the rule is: People’s memories of an experience are based on a rough average of the most intense moment (the peak) and the final moment (the end). So when people evaluate your interface, their feelings about it will be based mainly on what they felt at the end and what they felt at the most intense moment. So when designing interfaces you should focus on creating one powerful peak moment and a great last impression. You probably see where I’m going with this! Happy is a powerful feeling. You can use charm and humor to achieve that! It’ll be extra effective if you inject humor when the user is done with a task, like the Mailchimp high-five example from earlier in this article. Spotify cleverly uses humor in their offboarding by offering the user a “Farewell playlist” when they cancel their subscription: Maybe they won’t make a whole lot of users change their mind, but at least the user is more likely to leave with a smile on their face and have a slightly better memory of Spotify, which probably increases the chance they’ll come back some day. A final joke I want to live like I learn! Since the article is just about over, here’s a joke: How many graphic designers does it take to change a light bulb? Four. One to change the bulb and three to argue about whether they should have used serifed or sans serifed fonts on the packaging. Ahh, priceless! If I listen closely, I can just about hear the endorphins flowing through your body helping you remember this article! Hope you enjoyed! Web Accessibility Directive – What it is and how to comply Hampus Sethfors — Wed, 27 Sep 2017 18:27:22 +0000 Worried about the new directive on accessibility that you need to follow? Great, you’re in the right place! Here’s everything you need to know about the directive and a seven step guide on how to comply. About the accessibility directive In October 2016 the EU parliament approved a directive on digital accessibility that had been worked on since 2012. The directive will become law in all EU-countries. In this section, we’ll give an overview of the directive. In the next section, we will talk about what steps you need to take to comply. The directive in a nutshell If you work with web or apps in the public sector, the directive states that you must: Make sure your website, intranets and apps comply with accessibility standards (more on that later in “What are the actual rules”). Provide a feedback mechanism where anyone can notify you of failures to comply with the accessibility standards. Regularly provide a detailed accessibility statement on your compliance, using a template from the EU Commission. Who is affected The directive affects EU-countries, and its full name gives a good hint of what is covered: “Directive on the accessibility of the websites and mobile applications of public sector bodies”. So you’re definitely affected if you – or your clients – fulfill the following criteria: Work with web, intranets or apps Work in a public sector body Work in an EU-country Even if you’re not a government organization, you’re still affected by the directive if you: Provide services that are essential to the public, or services that specifically address the needs of, or are meant for, persons with disabilities. Exactly what’s considered essential to the public is not clear, but it will likely include companies in the transportation, food and finance industries, among others. The directive lists some exceptions. The most prominent are: Broadcasters (TV, radio etc) Online maps Live video or audio content There are a few other exceptions that you can read about in Article 1 Section 4 of the directive if you’re interested. Will they audit me? Yes. Here are some quotes from the directive: Member States shall ensure the availability of an adequate and effective enforcement procedure to guarantee compliance with this Directive Member States shall periodically monitor the compliance of websites and mobile applications of public sector bodies with the accessibility requirements Member States shall ensure that public sector bodies provide and regularly update a detailed, comprehensive and clear accessibility statement on the compliance of their websites and mobile applications So to cite George Orwell: “Big brother is watching you!” What happens if I don’t comply The most important problem if you don’t comply is that you’re making it difficult for your users to access your services, especially users with disabilities. But also, since the directive will be made into a law in each EU country, not conforming to it will literally mean you’re breaking the law. Details about the actual consequences are decided by each country’s authorities and may differ between countries. Deadlines – How long do I have to comply? 23 September 2018 – deadline for countries to have put laws and regulations in place to comply with the directive. 23 September 2019 – all new websites (created after 23 September 2018) need to be accessible 23 September 2020 – all websites (not just new ones) need to be accessible 23 June 2021 – all mobile apps need to be accessible This does not mean you can wait until 2019 to address this. Accessibility is a team effort that involves developers, designers, publishers, executives…well basically everyone. If you’re not working actively with accessibility now, it will take time and energy to make accessibility part of your processes and increase the knowledge of your organization. For most public sector bodies we’ve worked with, it takes about a year of calendar time to put the right strategies in place to become successful with accessibility. So get started in time! What are the actual rules? If you want to dive into the actual standard, you should! But be prepared to do some serious reading. The directive is only 15 pages. But it doesn’t include the actual requirements for complying. Instead it references the EU standard for accessible public procurement which is 134 pages long. In turn, that standard points to WCAG 2.0, which is about 1 000 pages if you include techniques of how to comply with it. If you are like most people, you don’t have nearly enough time to go through all that. So below we’ve put together a guide to what you need to do to comply with the directive. Practical seven step guide to compliance “Only seven steps!?” you might be thinking, but it gets even better: Apart from making your site or app accessible to people with disabilities, we guarantee it will become more usable for all your users. Win-win! You might be able to skip some steps, depending on what type of organization you are. If you’re only going to procure apps or websites, you should focus on step 1, 3, 4 and 7. If you’re only building the apps or websites, focus on step 1, 2, 5 and 6. So here we go! Our guide for building accessible products that comply with the accessibility directive: 1. Educate yourself and colleagues To succeed with accessibility, different roles need to have the right know-how. Like we said before, accessibility is not a one-man-show, it’s a team effort. Here are some key roles and the competences they’ll need: Developers need to learn how to use techniques like WAI-ARIA to make their code accessible to assistive technologies. Testers and developers need to learn the basics of assistive technologies like screen readers, so they can validate the user experience of their interfaces. Designers need to learn how to create accessible user experience and design, like how to check the contrasts of their color schemes etc. Editors need to learn how to produce accessible content, like how to write alternative texts for images and create captions for videos. Managers need to know how to plan for accessibility and incorporate it into their requirements and agile processes. Luckily, it doesn’t require weeks of education to get your team on track with accessibility. Most courses offered on accessibility are done in a day or two. If you don’t have an accessibility professional to teach your team, here are some companies that offer accessibility training: Axess Lab (yes we shamelessly promote ourselves because we’re really good at this!) Paciello Group Simply Accessible Funka A set up that we like to use is half a day of general training where people get to try out different assistive technologies, understand the users and learn the fundamentals of accessibility. Then we follow that up with half a day of specific accessibility training for different team roles. “Technical accessibility” for developers, “Accessible design” for the User Experience team etc. 2. User test User testing is an absolute key task to succeeding with accessibility. If you’re not user testing on a regular basis right now, you should definitely start! Trust us, we’ve worked with loads of clients who tried to make accessible products just by following different checklists. You will not succeed in building an accessible product unless you let actual users test it. Accessibility and usability are closely related. You can’t have one without the other. If you’re user testing right now, great! Then all you need to do is start recruiting users with disabilities as test subjects as well. Check out our article on seven tips for user testing with people with disabilities. 3. Rework your style guide I can’t even count the number of times an inaccessible style guide has caused problems in web projects. Since the style guide is the foundation that you build all your digital products from, an inaccessible style guide results in problems all across your interfaces. Usually it’s because it specifies color combinations that have insufficient contrasts. A good tip is to have an accessibility expert work together with your designers to make sure your style guide complies to the accessibility standards. Put in the effort to rework the style guide once and you’ll see so much fall into place automatically. 4. Feedback mechanism The directive requires you to have a feedback mechanism that encourages users to comment on accessibility issues. You’ll also need to set up a strategy of how you handle issues that come in through the feedback mechanism. For example, this can be a special email, like [email protected] that you add to your contact or support pages of your sites and apps. Many larger companies also have special social media accounts for accessibility, where they promote work they do on accessibility and encourage feedback and discussions. Get inspired by the following examples on Twitter: @fbaccess, @MSFTEnable and @BarcalaysAccess. 5. Automatic testing There are plenty of tools out there that help you catch some accessibility issues automatically. However, I need to be really clear on this: automatic tools will not find the majority of accessibility issues in your interface. Accessibility guru Steve Faulkner put it clearly in this tweet: Automated accessibility checking is great, but it needs to be clearly understood that you can only auto-check about 30% of #a11y issues pic.twitter.com/kAXYGqpiOg — Steve Faulkner (@stevefaulkner) May 12, 2017 Here’s a great article from Gov.uk on automatic testing tools: What we found when we tested tools on the world’s least-accessible webpage. The overall gist of the article is: It’s important that teams don’t rely on them too heavily. Automatic testing tools are a good resource if used together with manual reviews and by a team with accessibility knowledge. But don’t count on them to fix all your problems. Here are some automatic testing tools that you can compare: aXe Tenon SiteImprove pa11y (free) WAVE (free) 6. Manual testing You should complement your automatic testing with manual accessibility testing. In other words: let someone who knows about accessibility test your site or app. Here, you can either work together with accessibility specialists or educate people in your testing or development teams to do the accessibility testing. You will be required to do manual accessibility testing when you update the accessibility statement required by the directive. How often this needs to be done is not specified in the directive. It just says “regularly update a detailed, comprehensive and clear accessibility statement on the compliance of their websites and mobile applications”. A good guess is that it will be at least once a year. A good way to succeed with this is to make accessibility testing part of your agile process. A lot of teams have a “definition-of-done” that specifies the criteria that need to be checked off before they release a new feature. Make both a manual and automatic accessibility test part of the definition-of-done. 7. Procurement and requirements If you’re not developing your own sites or apps it will be crucial that you have clear accessibility requirements and that you follow up on those requirements. Just pointing to a standard like WCAG and relying on your client to ship an accessible product is not a good way forward. WCAG is long, abstract and difficult to understand and it’s very likely your contractor didn’t even read it, knowing you probably wouldn’t either. But you are the one getting in trouble if the result is not accessible! You need to make the requirements concrete and easy to understand. You need to decide how you will test the delivery and state what will happen if the requirements are not fulfilled. You wouldn’t imagine how often organizations fail with this. It’s not rocket science, but you need to be thorough and not take the easy road. High five! By following the web directive and creating accessible websites and apps you’re doing a great thing for democracy and people’s independence. When focusing on the needs of users with disabilities you’ll make your products better for everyone. That’s called design for all and is what accessibility is really about. On behalf of all users, we thank you for your commitment and wish you the best of luck with your accessibility journey. If you have any questions don’t hesitate to get in touch at [email protected]. Statistics on disabilities – the one stat you need to know Hampus Sethfors — Tue, 19 Sep 2017 06:42:05 +0000 We often get asked how many people have a disability. So here is everything we think you need to know about the statistics. Yea, that’s it! You really don’t need to go dig into more details than that. Accessibility affects everyone in a positive way. And the older you get, the more you’ll depend on accessibility. So start building accessible products right away – and let us help you if you need a hand! But if you really, really want to know how many people live permanently with a disability, it’s around 15 % of the world population (who.int). Text transcript of the infographic 100 % of the world population spend part of their life with a disability. Here are some examples of why: Bright sunlight on your phone screen leads to vision impairment. Big thumb on small mobile device on shaking train leads to motor impairments. Loud environment leads to impaired hearing. Alcohol leads to lowered cognitive abilities. Tired or stressed results in lack of focus. Ageing leads to all of the above. Accessibility matters to everyone. Design for all. Always. Skip the WCAG! User test with people with disabilities instead Hampus Sethfors — Thu, 14 Sep 2017 10:24:05 +0000 If you’re trying to make your website or app accessible, you’ve probably stumbled over the Web Content Accessibility Guidelines (WCAG). But don’t waste your energy trying to understand them. Just don’t. Get out and test with actual people I know it’s a bold statement. But the WCAG will confuse you. And probably scare you away. It’s really, really, really long and difficult to wrap your head around. How long? Well, I took the WCAG, pasted it into Microsoft Word and zoomed all the way out. Voilà, here are the 98 pages: On top of that, there are the actual techniques for succeeding – the blue links on the latter half of the pages above lead to those techniques. Probably another 1 000 pages or so. So instead of diving into WCAG, if there’s one thing you should do to improve the accessibility of your website or app it’s to let people with disabilities test it. I’ve done this a lot in my role as an interaction designer at accessibility focused companies. And there is no doubt in my mind: testing with users with disabilities will help you improve accessibility far more than reading any checklist or standard ever could. Period. “Normal” users are not good enough Testing with users with disabilities will also help you improve your usability far better than testing with your “regular” test subjects. Why? Well, for instance, a person with cognitive impairment like autism will react to the same things that another user will. But they go further. They are much better at spotting inconsistencies in design, problems with navigation and unnecessarily difficult content. Things that other users will find annoying but work their way around without mentioning. In a similar way, a person with low vision will react to small text or low contrast, which will make reading difficult for anyone out in the sun with a smartphone. If you want to test with people with disabilities, I’ve put together a list of tips to get you going in another article: Seven tips for user testing with people with disabilities And if you feel it sounds a bit scary, we can hold your hand and help you with recruiting users and carrying out the tests. Don’t hang me… And finally, I turn to the awesome people of the accessibility community: Please don’t hang me for suggesting people to skip the WCAG. The fact is, I love the WCAG! It’s probably one of the most important documents around, all categories. But it should be used by people who’ve matured further in their accessibility career or mindset. First, you have to witness people in action, otherwise you’ll not understand how to use the WCAG, why it’s around and it’s strengths and limitations. Hope you get what I mean! Accessible datepickers Hampus Sethfors — Wed, 06 Sep 2017 12:26:29 +0000 Datepickers often cause problems to assistive technology users and fail several basic criteria in the Web Content Accessibility Guidelines (WCAG). But datepickers can – and should – be made accessible. Here is how to do it and a few examples you can steal or get inspired by! Criteria for accessible datepickers Don’t force people to use the datepicker. Make it possible to write directly in the input field as well. And make sure the required format is specified in the label. Make it possible to navigate with a keyboard (here is where most fail). For example by tabbing to the calendar and using arrow keys to pick the right date. Don’t hide the calendar button from screen readers. We’ve met a few clients who considered setting aria-hidden=”true”, forcing screen reader users to input directly in the text field. But that’s not a great idea. Some screen reader users use a combination of sight and screen reader, so hiding the calendar button and calendar view for screen readers will harm their user experience. Make the actual datepicker accessible instead. Make sure that the buttons and icons in the calendar view have proper labels so that they get correctly read by screen readers. For example, the dates of the month should not just be “1”, “2″ etc. They should be read “1 January, Thursday” or something similar. You can use aria-label for this. Examples of accessible datepickers Here are a few accessible datepickers that fullfil the criteria above that you can get inspired by: Accessible Bootstrap Datepicker Aria Datepicker Deque Datepicker WebAxe have some more examples in their article Accessible Date Pickers (webaxe.org). Colorblind Accessibility on the Web – Fail and Success Cases Hampus Sethfors — Wed, 06 Sep 2017 05:43:00 +0000 It’s Colorblind Awareness Day today! To celebrate, we raise awareness by giving you some practical examples of how design can hurt or help users with color vision deficiencies. Diagrams and infographics Diagrams and infographics are common offenders when it comes to creating accessibility barriers for people who can’t tell certain colors apart. Green and red are the most common colors that are difficult for people to tell apart, which makes the diagram below extra problematic. This is what it would look like with deuteranopia, a color defiency that about 6% of the male population has. Pie charts are usually really inaccessible. Reasons why I hate pie charts pic.twitter.com/e1ooavL7Zd — Color Blind Probs (@WeTheColorBlind) January 28, 2014 If you really want to use a pie chart, put your labels in the chart. Or just use a bar chart instead because piecharts kind of suck. Here’s a great article on how to make your charts more accessible with color blind friendly palettes. Color pickers Color pickers without labels will create a barrier for people with color blindness. Instead, label the colors. This will help all users, since it can be hard to see the difference between certain colors like black, tortoise and brown. The great example below is from warbyparker.com. Apple also does a good job with this. Instead of showing a color palette they show the actual product in the different colors, with a label below. Toggles Here is what one person on Twitter answered when asked what causes accessibility problems for people with disabilities: Colourblind. Text on background is usually fine, but things like colour-coded toggles, heatmaps, etc can be hard. — Dan (@phrawzty) June 4, 2017 This is what iPhone’s toggles look like if you remove colors. Which one is on and which one is off? A simple solution is to just use check boxes instead: Error messages A red frame around error messages is not good enough, like illustrated by this image from the great article Designing eCommerce for colourblind users (uxplanet.org): You need to make the error stand out more clearly by adding an error message: Links Don’t just use color to differentiate links from other text. If you remove the color it’s really difficult to understand that the heading “Modules” is clickable in the example below. You can use color, but in combination with something structural, like an underline, a link icon or a button design. Here are a few examples of links that work well even if you have a color vision deficiency. Contrasts Make sure that you have sufficient contrasts between your colors. Avoid writing text on top of images, like in the example below from the article Improving The Color Accessibility For Color-Blind Users (smashingmagazine.com): Make the background darker to improve the contrasts: Measure your contrasts and make sure they are at least 4.5:1. Here’s a list of our favorite free color contrast checkers. Below is an image of a big contrast fail in real life: The overall accessibility guideline The guideline for creating accessible content for people with color vision deficiencies is pretty straight forward: Color is not used as the only visual means of conveying information (Level A) – Web Content Accessibility Guidelines 2.0 So it’s fine to use colors to convey information, as long as it’s also conveyed in some other way. A great way to check it is by viewing your design in greyscale before each release. You can use the free tool Funkify to do it right in your browser. If you’d like to go deeper, you can join a practical workshop with our team, or even prepare for WAS certification to strengthen your skills in accessibility. Keep updated on color blindness Here are tips of two awesome Twitter accounts to follow that raise awareness on color blindness: @colourblindorg @WeTheColorBlind And while you’re following great accounts on Twitter, follow me as well: @hampelusken! Let’s end with this Tweet from @colourblindorg showing that color problems limit people outside of the web as well. 1/2 Why no section for ppl unable to watch matches due to ‘colour blind’ kit clashes #1in12men #1in200women @EHCR?https://t.co/bHnx8cqj1K pic.twitter.com/2jssIGPicA — ColourBlindAwareness (@colourblindorg) August 11, 2017 Fonts don’t matter Hampus Sethfors — Fri, 01 Sep 2017 13:45:27 +0000 If you’re an art director or font fanatic, you might want to sit down for this. Take a few deep breaths. Go to your happy place. Because I’m going to explain why fonts are overrated and what actually matters for readability. The hard truth What’s important when picking out a font? It’s one of the most common questions I get when I consult in accessibility. People expect me to start lecturing on the importance of fonts for people with dyslexia or other reading impairments. How different typefaces and kerning really can make a difference for the readers. How the choice of serifs or sans serifs in headings is as close to a life-or-death changing decision a web designer can get. So I always get perplexed reactions when I reply: Actually, font’s do not matter very much… I know it’s a really bold thing to say. Telling web designers that fonts don’t matter is like stealing a kid’s favorite toy. But before you compose an angry tweet about it or respond with a “Fonts matter a lot” article on Medium, please hear me out. Fonts are overrated I’m asked to talk about fonts so often that I consulted members of the Dyslexia Association here in Sweden. They are experts on readability and get font questions so often that they even had a prepackaged answer referencing different studies made on the subject. Here’s the gist of what they had to say: The energy put on fonts is hugely overrated. There are other things that are of much greater importance for our members. – Representative from the Swedish Dyslexic Association The folks at Dyslexia Action agree with this: Research shows that fonts matter relatively little. – dyslexiaaction.org What really matters for readability So first I want to go through what really matters to people with reading impairments. At the end of the article you’ll find some pointers on fonts as well. You’re only allowed to read that once you’ve understood the other things that matter more. So promise me you won’t skip to that right away. Structure the text – headings, sub headings and paragraphs Here are two of the answers from our article Accessibility According to Actual People with Disabilities: Dyslexic – not really seen as a disability, but large walls of text is painful. Also never ending sentences and over complicated language. — Mustafa Kurtuldu (@Mustafa_x) June 3, 2017 When ppl type large blocks of text w/ no spaces added — Dead Ass (@MeBeShe4815) June 3, 2017 So giving your text a reader friendly structure is important. Here are a few things you can do to structure the text in a nice way: Include plenty of headings and sub headings Use bullet lists a lot (like I’m doing now) Keep paragraphs short Complement text Letting users choose how to obtain the content is a key to accessibility. Work on complementing text content with: Infographics Videos Illustrations Images Audio I tie a tie about once every five years. I’m happy for the combination of video, text and illustrations on tie-a-tie.net (see example below). Usually I look at the illustrations, but if I can’t figure them out I switch to the video. I have a friend who is completely blind. He prefers the text version. The point is that we can choose, and that’s awesome! Don’t use italics I could cite a few studies done on the readability of italics, but instead I’ll just write this in italics to prove my point. It takes more effort to read for everyone. Especially words you don’t come across very often, like absquatulate. On top of that, imagine that you have a reading impairment where letters tend to blend together. Then italics will make things so much worse. So just don’t use italics. Keep it clean Let the user focus on the content without distractions. Avoid: Movement, animations and other “concentration thieves”. Common offenders are advertisement banners, image carousels, popups and fly-ins. Too much clutter around the content, like multiple columns with related articles. “Sticky” objects that follow along when you scroll, especially ones that cover part of the content. Ladies, gentlemen and everyone in between, I present to you the pride of my home country Sweden, the world’s most cluttered site: Arngren.net. Gaah! Do not follow their example. Line length – keep them short! A common problem for people with reading difficulty is that they jump to the wrong line of text at line breaks if the lines are too long. In other words, when you can’t find the way from the end of one line to the beginning of the next line. One way to reduce this problem is by keeping paragraphs short. Another important guideline is to keep line length short. 50–75 characters – including spacing – per line is a good line length guideline for big screens. Shorter of course on mobile screens. Line height – make it large enough Usually the problem with line height on websites is that it’s too tight. This contributes to the problem for the user finding the next line from the previous one. It can also make the page feel like a “wall of text”, a common comment when user testing with people with dyslexia. A good guideline is to use a line height that’s 150 % of the font size (Smashing magazine). It’s what we use on this site. Font size – make it large enough Anyone who has used their phone to surf to a site that is not adapted to small screens knows that font size matters for readability. As with line height, the problem is usually that it’s too small. It probably has to do with the fact that most people who design websites are young and have a better than average vision. Show your interface to someone who is over 65 years old and see if they pinch or hold the device really close to their eyes when reading. Usually we see font sizes between 15–18 pixels on the web. Here is one good reason to crank that up a few pixels: A larger typeface has been proven to enhance readability for all types of users, regardless of one’s age or quality of eyesight. – Your body text is too small (marvelapp.com) Here’s a rule of thumb I made up that should work for most designers: Pick a font size that you think is nice. Then make it at least 2 pixels bigger. What matters with fonts and accessibility Yes, I lied in the title of the article. A little bit. Because even though fonts are overrated and get far too much energy and attention in projects, I’m not arguing that they don’t matter at all. Just that other things matter far more. For example, if you’d use Comic Sans on your site many readers would probably react. If you’ve done your best with all the other factors that I’ve mentioned above, then it’s time to think about the font. So here are some pointers when choosing a font for good readability. Pick a common font When studies compare reading speed and user preference of different fonts, common fonts usually win. People tend to prefer reading letters they’re used to reading. – Representative from the Swedish Dyslexic Association …duh! Quite obvious when it’s put in that way, right? When a font looks odd, it’s hard to focus on the actual content. The best font choices are ones where the reader does not notice the font, but the message – WebdesignerDepot.com Which font are common on the web? Here’s a great article on the most popular fonts on the web (theultralinx.com). A note on “dyslexia friendly” fonts There are a few fonts out there that market themselves as “dyslexia friendly” and they’ve gotten a lot of spread lately. Below is Open Dyslectic, probably the most well known font designed for readers with dyslexia. As you can see, the foot of each letter is bold, which is meant to reduce risk of flipping the letters around when reading. However, people with dyslexia tend to prefer common fonts to dyslexia-friendly fonts when comparing them. Special fonts often result in the reader mentally thinking about the font, when reading actually is about getting beyond the font and reading the content. – Representative from the Swedish Dyslexic Association There is no evidence that dyslexia fonts help people with dyslexia to read faster and more accurately. – Understood.org So don’t overestimate their dyslexia friendliness. Use common fonts instead. Let people choose Depending on what type of interface you’re building, it might be a good idea to make it possible for your users to switch to a font they prefer. Most e-book readers – like Amazon Kindle below – have a feature to pick font, line spacing, margins and more. Web browsers also let users set global font and color schemes. Try it out in the settings of your browser and make sure it works on your site. Safari’s Reader Mode also let’s the user pick fonts, colors and sizes that they prefer: Far from everyone who need the font styling features will find them, so you still need to format the default text in a way that works well for readers. Even though it can be good to let users pick their fonts in some interfaces, it’s doesn’t work for all of them. For example, if you place a font changing feature in the header of a website, it’s usually not something that users will find or bother to use. They want to set it globally so it affects everything they read – like in the Reader Mode on Safari – not have to do it separately on each individual site. Serif or sans-serif The question of serif – squiggly decorative ends of strokes on letters – or sans-serif font is always a well debated issue. Some readers think it helps the flow of the text, others will say it causes letters to blend into each other. So I will recommend you to fall back to the previous guidelines: Use common fonts. On the web, most use sans-serif fonts so that’s what we recommend for body text. Let the user choose. Make sure that changing the font in the browser settings works on your site. Final words I’ve sat countless of hours in web design meetings where fonts choice was debated back and forth. I just want to cry out “Please put this energy on making great content, user testing, information architecture or something else that matters more!” Sadly, I’m way too polite to say that out loud. Instead I hide behind my keyboard and write this article about it. So please help me out. Do talk about fonts in your projects. But keep it to a reasonable amount. Pick one, then move on to something more important. How icons are ruining interfaces Hampus Sethfors — Mon, 21 Aug 2017 15:02:07 +0000 Icons used correctly can enhance both the user experience and look of your interface. Sadly, more and more designers are using them in the wrong way. And it’s hurting both the usability and accessibility of the interface. My dad and his TED app I love to watch my dad use technology. It’s such a great learning experience for me as an interaction designer. He is 57, wears glasses when reading and always delays getting a new phone until his old one completely stops working. You see, he does not like to learn new technology. He just wants his stuff to do what he needs it to do without having to think. My dad does a lot of long distance flying. So recently, he asked me: Can I download TED-talks to watch on flights? I answered as I always do to that type of question: I don’t know. Try! Then I stood behind his shoulder looking at how he tried to solve it. Not helping, just looking. I love it! The only thing missing was a bowl of popcorn. He quite quickly found a video. He looked at his options. Four icons. He hesitated a bit, looking through them. It could be the heart or the list icon with a plus sign. But he decided to go for the down arrow. It looked the most correct. Which it was. But he clearly felt a bit unsure. He got some sort of notification that a file was downloading by the Android operating system. But then he immediately started looking for the downloaded clip in the app. Did it work? Where was it now? The main menu of TED is a collection of five icons: My dad started clicking the icons one by one, clearly not understanding what any of them meant. He could not rule out a single icon. Since he felt unsure of them all, he gave each page a very limited amount of scanning. When he couldn’t find the downloaded clip in the app he went out of the app and looked for some kind of folder where the video could have ended up. “Maybe it’s in a Downloaded folder” he mumbled. Clearly hoping his Android had a file system like his computer. Which it does, but not as visible as on desktop computers so he couldn’t find it. Then he gave up. It’s not worth it. So I had to step in and help, and I found the downloaded clip under the last icon, the one that looks like a user profile. He had clicked that but not had the energy to look closely enough. Too tired from checking every other place that he thought could be correct. So this story illustrates one key problem with how many interfaces use icons… Icons could mean a lot of things The icons are given meaning by the user, in regard to the task they’re carrying out at the moment. Icons are like abstract paintings. They get different meanings for different people. It’s all through the eyes of an observer. And that ambiguity is really exciting with art. But not so much in user interfaces. What’s the icon for offline downloads? It could be a folder, star, heart, down arrow. Or even a profile icon, like in the TED app. It’s very hard to rule out any one icon. So what I’m trying to say is that icons don’t work alone. Icons should have labels When icons are used to save space, things go wrong. Icons should not be used in that way. To a designer of tight mobile interfaces, using an icon to save space is really compelling. At first glance, the interface looks so clean and tidy! However, for the user it’s usually the second glance that counts. The one where they look at the icon when they are carrying out a task. My dad doesn’t give a poop that the interface has a clean first impression if it confuses him when he’s trying to get something done. And your other users probably work in the same way. You recognize an icon used to save space by a lack of a text label. Icons without labels suck Here are some examples of interfaces with labels without icons. The Gmail app. It took me – an interaction designer – an eternity to find the “Mark as unread” feature which I want to use all the time. It’s the mail icon. And the box with the down arrow means “archive”, not “download”. I recall at least three different people I’ve had to help download an app from the App Store after they exclaimed “where the hell is the download button?”. Yes, my dad is one of them. A cloud with a down arrow? Apple, you can do better than that. Instagram is packed with icons without labels. You can probably guess what they do, but you probably have to do a fair bit of thinking and you’ll not feel totally confident. You should aim to make your users feel confident. Icons without labels are not only a problem in digital interfaces. Ever wondered why you always use the same setting on your oven, dishwasher or washing machine? Probably because you have no idea what the other features mean. Here’s a washing machine I came across in France that made me go “Merde sacré bleu”! Icons + labels = true love If you label icons, they suddenly become awesome, accessible and understandable. An icon with a label: makes it easier for the user to find the most important features – the ones with icons. makes it easier to remember where you clicked the next time you come back. makes the interface more aesthetically pleasing than if there were just text buttons. A text and icon combination also improves the experience for people who have a hard time reading, like many users with dyslexia, autism, aphasia or other reading impairments. Icons with labels are awesome Below are some examples of interfaces that label icons. The Tripadvisor app uses icons with text labels on their startpage and on their tab navigation menu. Just for comparison, here’s what it would look like without the text labels. Not as clear without the labels, huh? Headspace uses text or icons with text labels. Never icons by themselves. Slack uses icons with labels in their menu. They also use colors to highlight some of them. Together this assists their users’ memory and lightens up the look and feel. Quora uses icons with text labels both in the header and footer of their app. But hey, I’ll just show a tooltip! Are you considering solving the “my-stupid-users-don’t-understand-the-icons” problem by showing tooltips when the user hovers over icons? An understandable – yet not excusable – mistake. Why is this not a good solution? Well, two main reasons: You can’t hover on touchscreens. Not all users use a mouse, for example a lot of people with motor impairments. Lesson one in accessibility is to make it possible to navigate your interface using a keyboard only. Yes, there are exceptions There are some icons you can use without a label. Like a trash can for delete: Or the magnifying glass for search. But even that icon’s functionality can differ. Sometimes it means zoom or preview: The main thing to know is that the number of universally understood icons are far fewer than you think. If you’re reading this post, you probably live in a bubble where your the people you hang with are far more tech savvy than most people out there. So just because you and your friends and colleagues know what the icon means, doesn’t mean everyone does. Kids now days don’t even recognize the floppy disk as a save icon. Oh my! Where’s this world heading? Another good example is the hamburger menu icon. You probably know what it’s for. And it’s in interfaces everywhere! But A/B tests have shown many people don’t use the hamburger menu icon if it’s missing a label. Icon guideline So lets boil down this post into a simple icon guideline: Awesome: Icon with text label Totally fine: Text with no icon Almost never cool: Icon without text label Or to make it even shorter: Stop using icons to save space. Want to learn more about accessibility? In our accessible design workshop we teach practical patterns for icon+text labeling that test well with low-vision and cognitive-load scenarios. Interested in deepening your skills? Our WAS training course helps you prepare for the international WAS certification, with hands-on practice and guidance to master accessibility in real projects. Why online shopping is more accessible than health care Hampus Sethfors — Mon, 14 Aug 2017 13:24:17 +0000 I recently met people with motor impairments to do user research. To my surprise, they turned out to prefer online shopping sites to public health care sites. This in Sweden, a country at the forefront of technology and with supposedly the best health care in the world. Is this really possible? Who are these people? I was doing user research on motor impairments in order to create a realistic motor impairment simulator. I’m in a super exciting project where we’re creating a browser plugin that simulates different impairments, like motor, vision, reading and cognition. I’ve added a link at the end of this article if you want to check out the plugin. Anyway, the people I met had Reumatism, Parkinson’s, Arthritis or some combination of the above. Most, but not all, were senior citizens. Online shopping versus health care sites I asked them to give some examples of sites they liked and disliked, and then explain what it was about the sites that made them pleasant or difficult. To my surprise, most people said they liked different e-commerce sites where you can buy clothes, tickets, books and similar items. When asked to give examples of sites that they didn’t like, the same site kept popping up: Sweden’s hub for health care 1177.se. This blew my mind a bit. Is it really possible that online shopping is more accessible than health care sites? What shopping sites do well I love filling out forms – No one ever Forms suck. The longer the form, the greater the risk of making a mistake. And for many people with disabilities, inputting data takes longer and more mistakes are made. Stephen Hawking for example, types around two words per minute using his assistive technology. So it’ll take him, and many other assistive technology users, at least ten times as long to fill in a form than for most people. E-commerce sites tend to put a lot of energy on making their forms easy to use. Health care? Not so much. When buying books online, I simply enter my social security number in the checkout and all other form fields get prefilled. It’s super easy! When booking health care, it’s a complete mess. – Woman with Rheumatism She went on to explain different rules concerning which clinic she is allowed to pick, how most clinics have different routines for bookings, how she has to fill out information about her condition from scratch at each place she goes. The list went on. And on. And on. Most users really dislike forms. Most users with disabilities really hate them. So to make your site accessible to people with disabilities you should focus on simplifying your forms. Amazon has taken form-simplification to the extremes with their “buy-with-one-click” checkout process (maybe they’ve even taken it too far). Compare that to the form for booking a time with the health care system below. Lots of fields in a cluttered layout. I know it’s in Swedish, but you get the point (sidenote: it doesn’t seem to be possible to get it in English, another big accessibility problem). Just the fact that you’re supposed to pick the times you can’t go to the clinic…wow. Imagine the number of mistakes made there. I just want to talk to someone Another person complained about how the health care system these days want everything to be done online and what a big a pain it is to get to talk to someone. If you don’t call right when they open the phone lines in the morning, you can spend the whole day in a queue, and sometimes not get through before they close. – Woman with Arthritis The last couple of years more and more effort has been put into forcing users to the web interface. Giving people the opportunity to make a phone call is a service that costs too much, so the health care system is making it a hustle in hopes that people will do everything online instead. This is not appreciated by many people, especially by some elderly who are not comfortable with new technologies. Choice is a key to accessibility. Give people the choice of which channel suits them best. Phone or web. That’s user centered design and client focused health care in practice. So to summarize this section: contacting health care seems to be difficult, time consuming and a form fiesta. Disabilities amplify usability issues I’m pretty sure that if we’d check the accessibility standards conformance of all e-commerce and all health care sites, health care would win big time. But accessibility is so much more than conforming to accessibility standards. Accessibility is mostly about issues that are not black or white. Accessibility is mostly about “softer” things that are hard to put in a checklist or standard. Accessibility is mostly about usability. When most people in the IT sector think about accessibility, they think about coding and other techy things. I’ve done hundreds of user tests with people with disabilities, and a majority of the problems that affect these users are not tech issues. Of course, making your site accessible for assistive technologies like screen readers is important. But most accessibility problems are usability related and affect all users. But, one thing is really important to understand: usability problems are usually amplified by a disability. For example, finding the right country in a dropdown with 200 countries is irritating for everyone. But imagine your hand shakes constantly, your vision is blurry or you have dyslexia. The irritation is amplified. So improving the usability of your interface is important for everyone. But it is crucial for users with disabilities. It’s all ’bout the money I believe that the main reason e-commerce sites often are better at usability – and thereby accessibility – is that they have a greater incentive to convert the users on their site into paying customers. They measure conversion rates and know the effect that simplifying form fields in the checkout has on conversion. Health care obviously also care about money. But for them, it’s often measured in time spent by the health care employees. Phone calls take a lot of time, which costs money. So they have an incentive to reduce that time. They end up hiding their contact info like a squirrel hides an acorn. And patients generally don’t have much choice. It’s not like if the site is a pain to use they’ll skip getting treated. And there is often no where else to go. It’s not like shopping, where you just can head over to a different store. So users use the site even though it’s frustrating. Or sit for hours waiting to talk to someone who can help them. Health care – time to shape up Don’t get me wrong. Online shopping sites – like basically all sites out there – have their fair share of accessibility issues as well. But they prioritize user experience, and that pays off. The health care sector, and the public sector in general, need to get better at user experience and put less of a burden on their users. User experience and user testing should be prioritized higher. Because getting good health care should be just as easy as shopping online. Anything short of that is an embarrassment for a democratic society. Check out the simulator plugin Like I promised at the start of this post, here’s the link to the plugin that simulates different disabilities, if you’d like to check it out: www.funkify.org. It’s in Beta right now but will be released sometime in the fall of 2017. How to make your site accessible for screen magnifiers Daniel Göransson — Sun, 16 Jul 2017 17:21:43 +0000 There are around ten times as many people who use screen magnifiers than screen readers. However, focus always seems to fall on screen readers in accessibility discussions and guidelines. Let’s change that! Here are a few tips on how to make your interface accessible to screen magnifiers. This article is inspired by and based on this original blog post: How to Make Your Website Accessible to People Who Use a Screen Magnifier (dev.to). I also use a screen magnification daily, and experience many of the same pain points as discussed in the blog post. Here is a summary and a few thoughts of my own on this issue. What’s a screen magnifier? A screen magnifier is a software that magnifies the screen and displays a portion of it enlarged. Below is an example of how it can look. Screen magnification is different to browser zoom (that you do with ctrl +) in that it doesn’t cause responsive layout to kick in. Using browser zoom, the layout is usually changed to match the width of the screen, so the user doesn’t have to scroll sideways. With screen magnification you’ll always need to scroll sideways to see all content. Making your interface screen magnifier friendly 1. Complement hover with click The screenshot below shows how only part of a popup is visible when the user hovers over an info icon with a screen magnifier. However, when the mouse pointer is moved over to the popup it closes. So there is no way for the user to read it. Instead, make the icon clickable so the user can decide to show the popup. This is also necessary for touch screens where there is no way to hover because of the lack of a mouse pointer. 2. Check your hover contrasts Color contrasts need to be good for people with low vision, and many design teams know how to check contrasts. However, most forget to check their contrasts on hover. This can create a big problem for users with screen magnification, who may have no choice but to hover over what they want to read. Below is an example from Kickstarter where content becomes almost completely unreadable when hovering. Most people could just move the mouse pointer to another place and read the text. But a person using screen magnification will probably have no choice but to hover over the area to read it, since they need the text to cover all the screen for it to be readable. In the example below from MediaTemple, the links change to a really light blue color with insufficient contrast on hover. So hey! I’ve got an idea. Instead of lowering the contrasts on hover, increase them! Show results close to where it was triggered When a user interacts with something they will often be shown feedback on what has happened. This feedback should be presented close to where the action was triggered. A common place where this fails is in error messages. The user presses a submit button and the error message shows up at the top of the form, or as a “toast message” (that also might disappear after a few seconds which is another problem). Here is an error message that is displayed at the top of the screen that can be hard to find for screen magnification users. Instead, show the messages close to where the user is when it’s triggered. The example below is better – but not perfect as many users zooming will not see things that far to the right of the field. The best design pattern is to show the message just below the field that the user is at. Then they will not miss it. Keep as much as possible to one column Users with screen magnifiers don’t get as good an overview as other users. Because of that, they are more likely to miss the second column in forms and articles. In the form below, users with screen magnifiers will probably miss the required field “Message” since it’s in a separate column. You can put navigation in a separate column because it’s a common design pattern on the web. But other than that, keep it simple and have only one column for your information. If you have “related links”, put them in the content where they are relevant or below the article. Not in their own column. Want to learn more? In our Interactive accessibility lab, your team gets hands-on with tools like screen magnifiers and works through real bugs together. Disabled buttons suck Hampus Sethfors — Fri, 07 Jul 2017 16:56:58 +0000 Showing buttons as disabled until a form is complete might seem like a good idea. It is not. They usually create a lousy user experience and exclude many people with disabilities. Here’s why disabled buttons suck and what to do instead. Why I got pissed and decided to write this A couple of weeks ago I got this comment at an event: I really have to go now, but add me on Facebook and we can continue talking. And I was thrilled! You see, I usually don’t thrive in social situations. Networking has never been my cup of tea. But there I was. At a meetup. Talking to an interesting person who asked me to be their online friend. Oh the joy! So I threw myself on my phone, opened the Facebook app and found her. I got to the screen below, and that’s when everything almost went down the drain: At first I didn’t see it at all. But luckily, I’ve got the eye sight of an eagle! I was just able to read the light grey text. “Add friend”. Seeing as the text and the icon matched my goal perfectly, I pressed it! Nothing happened. Maybe I missed the touch target? So I pressed it again. Same result. Started tapping it like it was the browser refresh button and Justin Bieber’s concert tickets were just about to go on sale. Didn’t work either. And I felt stupid for thinking it might. Had the wifi crashed? Were we already friends? Had I reached the limit of the number of friends I’m allowed to have on Facebook? My brain was working on full speed. Let’s pause the story a while. Sorry! I realize that you must be on the edge on your seat. What happened next? Why was the button not clickable? And would a disabled button spoil yet another friendship? However, like all great entertainers, I’ll reveal the unfolding of this thriller at the end of this article. #cliffhanger But first… Why disabled buttons suck Here are a few reasons why disabled buttons are gruesome things that will ruin your users’ day. They fool users into clicking Disabled buttons usually have call to action words on them, like “Send”, “Order” or “Add friend”. Because of that, they often match what users want to do. So people will try to click them. When nothing happens users can feel irritated, confused, disappointed, nauseated, let down, angry or stupid. Terrible design patterns make users feel terrible. They are hard to see Most disabled buttons are really hard to notice and read. They make the users squint and feel at least 30 years older. Even though the button is disabled, the text can be crucial for understanding the context. White text on light grey background, come on! These insane contrasts, of course, create even bigger problems for users with low vision. For some unthinkable reason, the Web Content Accessibility Guidelines (WCAG) do not require sufficient contrast ratios for disabled buttons: The visual presentation of text has a contrast ratio of at least 4.5:1, except for the following: Text or images of text that are part of an inactive user interface component. It’s simply impossible to understand why this exception is in the guidelines. Just another reason why you can’t follow them blindly (pun intended). But more on accessibility later. They don’t give any feedback 99% of the disabled buttons out there give no feedback as to why they are disabled when you click them (source: gut feeling. No one studies disabled buttons. Probably because they suck). Below are three disabled form elements in Google Analytics. Nothing happens when you try to interact with them. The reason they’re disabled is actually that the user doesn’t have the necessary permissions to control them. Why, oh why, is there no message to help them realize that? They give design teams a reason to rush through error handling If you’re working with IT, you probably hate error handling. “Hey! My users won’t make any errors in my perfect interface.” You might think error handling is taken care of with live error messages that show up when the user makes a mistake. Sadly, the users are often busy thinking hard about the answer to your next form field or looking down at the keyboard while typing, so they often don’t see your error message. “Stupid User ©, just look at my beautiful error message” you might think to yourself. But you have a plan B! You reckon that the user will see the disabled submit button and realize what’s wrong. Sadly many users don’t get why the button is disabled. And most who do first get pissed off pressing the disabled button a million times before realizing what’s wrong. You’ll need to put in some more effort to take care of the users who click the button. More on how later. They make users think Why does this button look so strange? What does it say? Why can’t I click it? What should I do now? Few form fields can make a user think as much as a disabled button. But is that really so bad? Yes. There’s a whole – epic – user experience book written about it: Don’t make me think. Users don’t want to think about your interface, they want to complete tasks with as little effort as possible. Disabled buttons disable disabled users Now that’s a tongue twister! But it’s true. Disabled buttons often create a big barrier for people with disabilities. Why? Well, let’s pretend that you have low vision and you’re filling in the register form on eBay: If you’re zooming the interface because of your low vision, you’ll most likely not see the second column: Maybe you’ll think they only need the first name. Or you might simply fill in both your first and last name in the field for “First name”. I’ve seen that done so many times in user tests, both by users with and without disabilities. You’re so used to writing your last name after you write your first that you do it by default. So this is what you’ll end up with: You’ll find yourself clicking the register button and getting no feedback. By the time you’ve realized there’s a second column in the form, eBay will have gone bankrupt for losing so many customers. Aside from that, assistive technologies like screen readers and switches are usually not even able to navigate to disabled buttons. Try using the tab key on your keyboard to get to one in the eBay form. You’ll see it skips right over it. Frustrating, right? Many assistive technologies simulate keyboard navigation, so that’s the experience many assistive technology users will have. Disabled buttons also tend to cause greater problems to people who make more mistakes when filling out forms. And this means many users with cognitive or learning impairments. Or people with dyslexia. Or problems with their motor skills. Or less tech savvy users. The list goes on. So disabled buttons exclude users with disabilities. It’s one of the best reasons to stop using them. What to do instead Just don’t disable buttons! Have them enabled and then show an error message when the user clicks them. Don’t trust me? Well, take it from A Definite Guide to Sensible Form Validations instead: It is a bad practice to disable buttons. Disabling the button prevents our chance to tell the user what is wrong. The user keeps clicking the button and is totally in the dark why nothing happens. Keep the button enabled. Let the user click the button. Then show the message why it can’t proceed. If you really, really want to indicate that a button is disabled, do some css magic and make it look a bit grey (but with sufficient contrasts). And then turn it green or blue when everything is filled in correctly. But keep the button enabled in the code at all times and put focus on an error message if it’s clicked and there’s something wrong. Do you need help with this on your project? Our accessibility review service covers toggles, states, and interaction patterns across platforms. The end of the thriller The suspense is probably killing you..! Why was the “Add friend” button disabled on the Facebook profile? The answer is – surprisingly – patriarchy! Ah, yet again, poor respect of women pops up as the cause of a problem in society. She had activated a setting on Facebook that blocks friend requests from people that don’t share a mutual friend with her. It turns out that many women get spammed with friend requests from strange, creepy men. It makes me happy I’m not a woman, but at the same time embarrassed of my gender. Luckily she was still around and could figure out why the button was disabled. We solved it by having her friend request me instead. But come to think of it, the disabled button almost cost me both a friendship and an important new insight! #feminism So yeah…disabled buttons suck! Accessible tech example: Queue management system Hampus Sethfors — Tue, 20 Jun 2017 14:10:22 +0000 Standing in line isn’t fun for anyone, but it’s often extra annoying for people with low vision due to inaccessible technology. In a pharmacy in Stockholm we found an awesome, simple solution by Qmatic. Check out this 13 seconds video (captioned) to see it in action! What’s usually the problem? Below are some tasks that can be tricky for people with low vision when it comes to queue management systems: Where do I press? Physical buttons are easy to find, but today many have moved over to touch screens. What number is on my note? Usually the font is pretty big, but for people who are blind or have limited vision it can be impossible to read. What number is now being served? Often there is just a sound notifying that a new number is being served, but requires good vision to see the actual number. How they solved it Qmatic solved this with a few simple features: A tactile overlay on the touch screen, with braille writing for “low vision”. Even though most people with low vision can’t read braille, they’ll notice that it’s there and understand it’s for them. A machine voice speaks the number on the note when it’s printed. A machine voice speaks the number that is now being served. A great feature for anyone who doesn’t want to take their eyes of their phone! Placed at a “wheelchair-friendly” height, with a tilt so that tall, standing people also can access it. Great job Qmatic. This is a textbook example of how a few simple features can create an inclusive product and improve the user experience for everyone! Need help with making your tech accessible? Just contact us at [email protected] or say hi to us on Twitter @axesslab. Accessibility according to actual people with disabilities Hampus Sethfors — Sun, 04 Jun 2017 10:30:46 +0000 “If you have a disability, what’s the hardest thing about browsing the web?” The answers to Safia Abdalla’s tweet are truly eye-opening and shows us what web accessibility should really be about. Photo: Francis Clarke for Wikimedia The tweet that started it all i'm curious to know: if you have a disability, what's the hardest thing about browsing the web? rt for visibility, please and thanks! — Safia Abdalla (@captainsafia) June 3, 2017 In this article I’ll summarize and group the main topics that people bring up in the thread. But do click on the tweet and read through all the answers. It’s an awesome read for anyone interested in making the web a better place for all. And, in my opinion, a far better place to learn about accessibility than reading any checklist or standard. Lack of captions Videos without captions (subtitles) was by far the obstacle that most people commented on. Here is what a few had to say: Being deaf, got to say captioning videos is number one issue for me — Jay Jackson (@jjackson) 4 juni 2017 Video/audio with no captioning or transcript. — Katelyn Reilly (@k_hack) 4 juni 2017 I’m hard of hearing so big pain for me is video with no captions. tweet or article just says “can u believe he said this?” & no summary — Carol Carpenter (@carolmcarpenter) 3 juni 2017 Also, my sister says that she hates it when she comes across videos that are not closed captioned. She’s Deaf. — Erica Boleyn (@radcrochetqueer) 3 juni 2017 Non-existing captions is something that can completely exclude users who are deaf or hard of hearing. But it affects many others as well. Anyone on the bus who forgot their headphones. Or some autistic users: I’m Autistic and when I get overloaded, it’s harder to process auditory input. Especially if the person talking is offscreen or something — act up, fight back (@UntoNuggan) 3 juni 2017 Many are hoping that automatic captioning solves this problem. But alas, not yet! Not really YouTube’s auto subtitling is not accurate enough. — Robin (@tohereknowswhe) 3 juni 2017 And the auto-captioning feature sadly isn’t available for most languages. So it’s still up to the video creators to caption. Motion, animations and cluttered pages Motion and animation can be annoying to anyone, but is extra frustrating to many users with cognitive impairments: ADHD: If there’s a “subtle” animation always running, I cannot focus. Biggest offender: https://t.co/KgfCA4a7lB‘s header gradient — Taylor Hunt (@tigt_) 3 juni 2017 Assuming ADHD counts, it’s hard to locate content on overly busy pages and animations are a nightmare of distraction. #clickthemonkey — mkb (@mojinations) 4 juni 2017 related, I’m also autistic and can get frustrated with, or repelled by, glitzy mouseover effects/animations, sudden autoplay, etc. — back at the holler (@elementnumber46) 3 juni 2017 Do your users a favor by not distracting them with autoplaying videos, advertisements or image carousels. Wall of text Many replies, especially from people with dyslexia or cognitive impairments, were about large chunks of text. Dyslexic – not really seen as a disability, but large walls of text is painful. Also never ending sentences and over complicated language. — Mustafa Kurtuldu (@Mustafa_x) 3 juni 2017 When ppl type large blocks of text w/ no spaces added — Dead Ass (@MeBeShe4815) 3 juni 2017 Huge paragraphs. A page on Wikipedia often consists of many long paragraphs with long sentences. I lose my place within seconds. — Ava Jarvis Art (@AvaJarvisArt) 3 juni 2017 ADHD + large, uninterrupted blocks of text or small bits of animation not part of the main content of a page — back at the holler (@elementnumber46) 3 juni 2017 Large paragraphs, too many moving images, too much content as videos (especially help files), no subtitles, pages with too much going on. — Polenth Blake (@Polenth) 3 juni 2017 The solution is so simple. Just create more paragraphs and sub-headings! And throw in more bullet-lists. Voilà! Small font size Amazingly there’s no minimum font size requirement in the Web Content Accessibility Guidelines. Even though it affects so many low-vision users. Nearly blind in my left eye. Tiny, thin font with low contrast to the background — Andrew So (@AndrewDixonSo) 3 juni 2017 Fonts are often too small and sites break when I increase font sizes. — Brandon Savage (@brandonsavage) 3 juni 2017 Tiny font size and certain animations. — Morgan Estes (@morganestes) 3 juni 2017 Zooming problems Some users with low vision point to layout and navigation problems when zooming or increasing font-size. My daughter has low vision and has to use 300-500% magnification. Many web sites are hard to navigate at this level — Kir Kolyshkin (@kolyshkin) 3 juni 2017 Neurological vision problems due to CFS/ME. Small fonts, I browse everything with fonts enlarged, but sometimes it screws up the layout. — Maija Haavisto (@DiamonDie) 3 juni 2017 for visually challenged, it is understanding the layout — VAMSI KRISHNA (@VamsiJKrishna) 3 juni 2017 Low contrasts and image of text One of the cornerstones of accessibility, color contrast, is still a major problem in a lot of interfaces. Lack of contrast between font color and background color. Photo backgrounds that overpower the text on top of them. — Megan Lynch (@may_gun) 4 juni 2017 Text rendered as graphics instead of text with no alt tags, no image description. From websites to memes. — Megan Lynch (@may_gun) 4 juni 2017 That’s definitely lack of contrasts in colors — charles dominic (@gamescharlie79) 3 juni 2017 So it is vital for web designers and art directors to understand how to measure and create accessible color schemes. Check out our list of seven great, free color contrasts tools. Bright color schemes Bright color schemes can be a big problem for users with low vision and is something that gets too little focus in accessibility discussions. It was interesting how many commented on it in the thread, and the different strategies they had to get around the problem: (cont) so this is fairly simple but I really appreciate the “night” modes that some things have. Less eye strain that way. — Callie (@cxllielayne) 4 juni 2017 re: frequent & debilitating migraines, so many sites are coded with light color scheme&I can’t use them even w/ sunglasses on & monitors dim — Pyrrh-T900XV1 (@xpyrrh) 3 juni 2017 I need to be able to get the article onto my Kindle Oasis to avoid backlight. I’ve also found the reader feature to be hit-and-miss. — Kal Cobalt (@kalcobalt) 4 juni 2017 Relying only on color This is also a cornerstone of accessibility that so many miss. Colourblind. Text on background is usually fine, but things like colour-coded toggles, heatmaps, etc can be hard. — Dan (@phrawzty) 4 juni 2017 It’s really easy to test, just view your site in greyscale. Here’s an example of a toggle that’s really difficult to understand when you take colors away. Which one is on and which one is off? And it’s not only people who are color-blind who need information to be conveyed in other ways than color: Sleep disorder: I have to read after 5pm with f.lux cranked up all the way, so sites that assume hyperlinks can be blue w/no underline… — Taylor Hunt (@tigt_) 3 juni 2017 Mouse-focused sites Even in this day of the touch-screen-revolution, too many sites still rely on mouse interaction. Especially for navigation on large screens. That needs to change. I don’t have one but my mother has Parkinson diseas and mouse Interactions are really hard for her — A dev has no name (@KodierKroete) 4 juni 2017 The number of sites which insist on using mouse over as the only means of menu triggering. — Zack (@zkline) 3 juni 2017 For some users with motor impairments that navigate using only their keyboard, a clear focus outline is vital to being able to navigate the web. Lack of focus outlines. Especially on links (they look ugly to most designers so they remove them) and custom components (eg dropdowns). — nuton.dev (@NutonDev) 3 juni 2017 Too small touch-targets This topic is related to the mouse-focused heading above. Many people bring up the problem with too small touch targets. My brother-in-law has cerebral palsy, buttons and links are too small for him to use. He can only use touch because he can’t hold a mouse. — Gary Rozanc (@garyrozanc) 3 juni 2017 Mobile twitter is also rly hard bc I have a tremor + visual-spatial processing issues. Often will click on the wrong thing by mistake. — (((self crytptid))) (@plathituudes) 3 juni 2017 A great new insight for me came from Dave Ross who brought up the problem of too large click targets: (Sometimes I have hand tics that make precise mouse control hard or I tap a touchscreen screen unnecessarily) — Dave Ross (@csixty4) 3 juni 2017 Multi-touch gestures are also a deal-breaker for some users. Yes! Kindle app has this “tap twice & hold” to get to the menu 4 display settings on books and it is super difficult. (Hand deformity) — Kristen Anne Strater (@KristenAnneSF) 4 juni 2017 These are actually some of the more common problems we find in our Accessibility Reviews ever since mobile browsing became the norm. Fingers are never as precise as a mouse pointer, even with perfect motor skills. CAPTCHAS Finally, we end with a classic accessibility failure: the dreaded CAPTCHA. Annoying everyone who comes across it, but completely locking out many with visual impairments or learning disabilities. As to what drives her nuts, non-accessible captchas are the top. It can severely limit which services are available to her. — Danny Does Code (@DannyDoesCode) 3 juni 2017 Final thoughts Reflecting on the answers to this thread, a few things become clear: Web accessibility is about so much more than just blind people with screen readers. Basically everything that people with disabilities comment on are things that annoy everyone, so fixing these issues makes your interface better for all users! A lot of what people comment on is not covered by the Web Content Accessibility Guidelines. So you need to test with users with disabilities! So thank you Safia Abdalla for tweeting your question. And thanks for everyone who responded and taught me (@hampelusken), and many others, a lot about accessibility. WCAG 2.1 – what’s up and coming? Hampus Sethfors — Wed, 17 May 2017 08:53:24 +0000 The Web Content Accessibility Guidelines 2.1 are planned to be released in June 2018. Even though a lot may change before the release, we already have some indication of what’s going to be new in the 2.1 update. The journey ahead When I’m writing this, it’s just over a year before the planned release in June 2018. WCAG 2.1 is on a journey through seven iterations called “Working Drafts”. Right now “Working Draft 2” is out, and a new one will be released each month from now until November 2017. Everyone is invited to comment on the working drafts on the WCAG 2.1 GitHub. So what’s going to be in it? Well, it’s hard to know for sure right now. In the first working draft released last month there were 28 newly proposed success criteria. Compare that to the total of 61 success criteria in WCAG 2.0, and you understand that it would be quite a big update. However, in Working Draft 2, only 4 of the 28 new success criteria are left. So it’s hard to know how they will change in the future. A few of the 24 criteria that didn’t make the cut in Working Draft 2 will probably come back, but we don’t know which ones. One thing we do know is that WCAG 2.1 is going to be backward compatible with WCAG 2.0, meaning that if you fulfill 2.1 you’ll automatically fulfill 2.0. Four likely new criteria These are four newly proposed success criteria that will probably be in WCAG 2.1 in some shape or form: 1.4.10 – Resize content, level A Requires that content can be resized up to 400% without the loss of content or functionality. And without horizontal scroll. This is a change from the 200% requirement in WCAG 2.0 1.4.11 – Graphics contrast, level AA Extends the contrast requirements to include graphical objects that are “essential for understanding content or functionality”. So no more low contrast hamburger menus or tab icons allowed. However, logotypes are sadly excluded from this success criterion. 2.2.6 – Interruptions, level AA Requires an “easily available mechanism to postpone and suppress interruptions and changes in content”. They are trying to address popups that interrupt the users’ focus, which is annoying to everyone but extra tough on people with some cognitive impairments like adhd or autism. 3.2.6 – Accidental activation, level A This addresses a problem many people with lowered motor skills have: activating the wrong button or link by mistake. The success criterion requires activation to be on the up-event, so that a user can touch the screen, realize they are touching the wrong target and move their mouse or finger to the right target. Some proposed criteria that might make it Outside of the four likely new criteria, there are plenty of other proposals that might make it into WCAG 2.1. Here are a few that we think look extra interesting: Target sizes. Require at least 4444 pixel target sizes for touch and 2222 pixels for mouse targets. Plain language. “Instructions, labels, navigation, error messages in simple tense, common words, basic rules of grammar, clear writing.” Animations. “No motion over 3 seconds as a result of a user activating something, or provide a way to turn it off. Addresses parallax scrolling.” Interested in more? Read this great blogpost by David MacDonald on all proposed news: Quick guide to WCAG.2.1 Milestones in the past and future Here’s a quick summary of the long history of the WCAG, and some planned milestones in the future. As you can see, the standard really does move forward at great speeds compared to glaciers. 1999 – WCAG 1.0 2008 – WCAG 2.0 2018 – WCAG 2.1 (planned) 2020 – WCAG 3.0 (planned) A lot has changed in the world of tech since 2008, so the 2.1 update is welcome. For example, the use of touch screens has exploded and so has the knowledge of cognitive impairments. We’re happy to see that WCAG 2.1 addresses both of those changes, with quite a few new criteria focusing on touch and cognition. Follow us on Twitter for more accessibility news and tips @hampelusken and @axesslab Seven tips for user testing with users with disabilities Hampus Sethfors — Tue, 16 May 2017 14:32:41 +0000 Like regular user tests, it’s not rocket science to test with users with disabilities. And it will give you so much more than reading checklists or testing with non-disabled users. Tips for testing Earlier, I wrote an article on why you should test with people with disabilities: Skip WCAG! User tests with users with disabilities instead. So in that article I go through why. But now I’d like to focus on how. Below are seven practical tips that I’ve learned through years of conducting user tests on digital products with people with disabilities. 1. Don’t call it “user test” The word “test” is something most people associate with anxiety, failure and other rotten feelings. And it can be extra negatively loaded for many people with disabilities, who may have been forced to go through tests to show they have a lowered intelligence or lowered functional ability. So call the user tests something else when you communicate to test subjects. For example: “Feedback session”. This makes it clear to the users that you’re looking to improve your product, so they know they can’t do anything wrong. 2. Get help recruiting test subjects People are often very supportive when you say you want to improve the accessibility of your product. So go search for groups to collaborate with. Maybe find someone in charge at an elderly center nearby or post in a Facebook group for people with autism. Or if it’s too big of a hassle, contact us and we will recruit and do the tests for you. 3. Give some love to the invitation A good invitation will both make the test subject feel more comfortable and reduce the number of people who don’t show up to the test session. So make it clear in the invitation on what is going to happen at the user test. This is extra important for people with cognitive impairments who might have a hard time imagining what will happen. Include this in the invitation: Image and name of the people they’ll meet, for example the test leader. Time – how long will the session last. Address and direct link to a map. Details on what to do when I get there. Which level to go to? Is there a code to get in? Who do they ask for when they get there? Contact information and what to do if they’re late or have to cancel. What to bring. For example: “If you use any assistive technology like a screen reader, it would be great if you bring it to the session”. 4. Send Reminders Send at least one reminder before the user test. Preferably in a text message. This will be super helpful for everyone and reduce your no-shows. And for people who have a hard time with time management, these reminders will be crucial. In Sweden we are using a service called “There-in-time” but you can use any reminder service out there really. 5. Don’t ask questions, give tasks I still fail at this a lot. When leading a user test, I find myself asking “What would you do to find the contact information?” And the user starts explaining instead of actually doing it on the computer: “I would probably go to Google and search for it.” And I have to ask them “Well, please do that!” which makes them feel stupid for not understanding they were meant to actually do it, and I feel stupid for asking such a bad question. Instead go straight to the point: “Find the contact information”. 6. Be patient It can often take a person with disabilities more time to complete a test scenario, get set up with their assistive technology, process information, navigate the site etcetera. Be patient as a test leader. Skip a test scenario if there is not enough time at the end of the test instead of speeding through all of them. 7. Don’t force users to speak out loud Many user tests apply the think-aloud-method, where you want the user to say what they think. You can still use this for most users with disabilities, but make sure to give alternatives. Some people find this type of communication really hard. So instead of saying: “Tell me what you’re thinking when using the site” say “If you want to, you can say what you’re thinking when using the site. Otherwise you can tell me after we’re done.” If you need help getting started, we can help, or we can even do the user testing for you. In any case, we hope this guide was useful. We are Axess Lab Hampus Sethfors — Tue, 16 May 2017 13:57:02 +0000 Hello! We are Axess Lab, a Swedish startup focusing on digital accessibility. Glad you’ve found us! We work as hard as we can to make everyday life easier for everyone, regardless of disability. We build digital products and help others who share our mission. Access Lab What’s the story behind the name Axess Lab? Well, we create innovative technology that give more people access to society, so we think Axess Lab suits us well. But why not just “Access Lab”? Simply because everything is cooler with an x! We’ll use these articles to share what we know with you. Enjoy!

for tables (TH and TD stand for table header and table data)

and

for lists (List and List Item)

This structure is core in making the document accessible and usable for assistive technology users.

Figure out how accessible your system generated documents are

If you have Adobe Acrobat Pro, this is fairly easy:

Open the Accessibility Tags panel
Run Adobe’s Accessibility Checker

You’ll quickly get a high-level view of what’s working and what’s not.

No Acrobat Pro? Reach out and we’ll help you with an initial assessment: [email protected]

Three ways to approach the challenge

There are three common strategies for improving accessibility in system-generated documents, and which one you chose will likely depend on the current state of your organisation.

System upgrade or migration – we can call this “Accessibility by design”.
Accessibility add-ons – “Accessibility by remediation”
Change to HTML (with PDF as alternative) – “Accessibility by default”

Let’s go through them one by one!

1. System upgrade or migration – “Accessibility by design”

This is the most robust—but also the most time-consuming—approach to achieving accessibility in system-generated documents.

Pros:

One-off implementation effort
Long-term, maintainable solution
Supports all aspects of accessibility, not only technical compliance

Cons:

Can be time-consuming and complex
May require a new installation
Does not address historical documents

Most system generated documents are produced using a Customer Communication Management (CCM) system. The three major CCM providers are OpenText, Quadient and Smart Communications.

All three offer platforms that support accessible PDF generation, including:

OpenText Communications
Quadient Inspire Flex
Quadient Inspire Evolve
Smart Communications SmartCOMM

Accessibility support in these platforms has matured significantly in recent years. When running on the latest released versions, all three vendors provide strong support for accessible PDF output.

Introducing accessibility through a system upgrade requires all document templates to be reviewed and updated with correct semantic structure and tagging. This includes proper handling of headings, tables, images, lists and other artefacts that affect the user experience for users of assistive technologies like screen readers.

The organisation must decide on the migration strategy—whether to perform a 1:1 migration or to rationalise templates. We generally recommends starting with template rationalisation workshops to reduce scope and identify synergies. This approach has proven effective in shortening time to market while also future-proofing the CCM setup.

A system upgrade supports accessibility by design for all new documents. It also allows organisations to address not only technical compliance, but also qualitative aspects such as clearer language, improved typography, and better contrast—resulting in a more inclusive user experience. In many cases, this is also a suitable opportunity to review the CCM solution as a whole.

However, if the accessibility initiative is subject to tight deadlines, this approach may be challenging due to implementation time and, depending on the selected platform, higher costs.

2. Accessibility Add-Ons – “Accessibility by Remediation”

With this approach, accessibility features such as tagging and reading order are added after the PDF has been generated. The visual layout and content of the PDF remain unchanged, although content updates can of course be handled separately if required.

Pros:

Short time to market
Source-agnostic (depending on licence model)
Can support historical documents

Cons:

Increased complexity due to dual code bases (CCM + remediation)
Primarily addresses technical accessibility

Post-composition remediation is a fast and effective way to create value early in an accessibility initiative. Both OpenText and Quadient provide remediation tools:

OpenText Accessibility Add-On
Quadient Inspire Adapt

If the technical prerequisites are met—such as a suitable CCM project setup or compatible source systems—the remediation work can be divided into multiple parallel streams. This makes the approach well suited for projects with tight deadlines.

The primary advantages are speed and flexibility. The approach can be largely source-agnostic, and depending on the licensing model, it may also support both new and historical documents. Implementation is typically straightforward.

However, remediation introduces two separate code bases: one for document generation and one for PDF remediation. This requires disciplined governance, controlled change management, and a robust testing framework to ensure both layers remain aligned over time.

3. Change to HTML (with PDF as alternative)

Delivering content in HTML format often results in significantly higher accessibility. HTML is inherently well suited for assistive technologies, offering strong support for semantic structure, responsiveness, navigation and user-controlled presentation. For many use cases, HTML can therefore serve as the primary delivery format, while PDF is retained as a backup or archival version.

Pros

Higher level of accessibility can be achieved
Low software and tooling costs
PDF can be retained as complement or for legal, audit and archival purposes

Cons

Not suitable as a replacement for PDFs in all legal contexts
Requires investigative and modelling work
Potential double maintenance (HTML delivery and PDF generation)

In digital inboxes, users typically interact with transactional information through an HTML-based view optimised for accessibility and usability, while still having the option to download the corresponding PDF for reference or storage when needed.

A HTML-based letter in digital inboxes will be easy to read with assistive technologies, text is usually resizable among other benefits.

This approach shifts the focus from making PDFs accessible to ensuring that users receive information in a format that is accessible by default. The PDF is still generated and stored where required—for example, for legal compliance, auditing, or long-term archiving—but it is no longer the primary interface for the end user.

When does an HTML-first approach make sense?

From a CCM perspective, this approach is particularly relevant when:

A full system upgrade is not immediately feasible
Accessibility legislation, such as the European Accessibility Act (EAA), must still be met
Documents are primarily informational rather than legally binding

In these situations, organisations can deliver content in HTML while keeping the PDF as a complementary, secondary or fallback format. This enables progress toward accessibility compliance without delaying longer-term CCM modernisation initiatives.

An HTML-first approach also allows improvements to language clarity, structure, typography, and contrast—similar to what is possible in a fully upgraded CCM environment. Some investigative and modelling work may be required to extract or re-structure document logic, particularly for older templates, but this approach often provides a pragmatic and scalable path to accessibility.

Where to Start?

Begin by identifying which approach—or combination of approaches—best fits your organisation’s document landscape, timelines, and regulatory obligations.

Book a meeting with Axess Lab and Enit, and we will help you assess your current situation and define the most effective path forward: [email protected]

Optimizing VoiceOver in an iOS E-Commerce App with Conditional Accessibility

Diogo Melo — Thu, 08 Jan 2026 10:19:02 +0000

In the previous articles, we built an iOS e-commerce app accessible to VoiceOver, Full Keyboard Access, and Voice Control users. This article explores how we can optimize the VoiceOver experience without breaking Full Keyboard Access or Voice Control in the process.

On the Product Detail Page, we saw how fixing VoiceOver issues in SwiftUI almost automatically produced the expected behavior for keyboard and voice interaction. In the Product List Page and Wishlist, SwiftUI and UIKit fixes targeting VoiceOver similarly translated to other assistive technologies.

However, the Product List Page exposed an important trade-off. To make the Cart and Wishlist buttons reachable by Full Keyboard Access and Voice Control, we had to change how VoiceOver navigated the list. Instead of a single swipe per product with contextual actions, VoiceOver users now had to swipe through three separate elements per item.

As I wrote in the previous article:

“Using VoiceOver, navigation now requires more swipes per product because each element is treated separately. From my perspective as a VoiceOver user, although the interface is functionally correct, I prefer the original single-element approach with accessibility actions, which allows quicker navigation and easier access to all available options.”

Conditionally Grouping PLP Elements (Actions Included)

At this point, we can treat the accessible implementation from the previous article as our baseline, and focus on improving the VoiceOver experience further, but only when VoiceOver is actually running.

SwiftUI exposes several accessibility-related environment values that describe the current accessibility context. Many of these relate to visual presentation, such as Increased Contrast or Differentiate Without Color. There’s no equivalent signal for Voice Control or Full Keyboard Access, but there is one for VoiceOver.

We can read it directly from the environment:

@Environment(\.accessibilityVoiceOverEnabled)

private var isVoiceOverEnabled

Because this value is a simple Bool, we can use it to conditionally apply VoiceOver-specific enhancements, without changing how the UI behaves for other assistive technologies.

With that information available, we can start adapting how elements are grouped depending on whether VoiceOver is running.

In the earlier articles, we used .accessibilityElement(children: .ignore) to prevent VoiceOver from navigating individual decorative elements (such as stars). This effectively hides the children from the accessibility tree, allowing us to expose a single parent element and manually provide its accessibility label and traits.

SwiftUI provides two additional grouping strategies particularly useful in this context:

.combine, which makes VoiceOver merge all child elements into a single accessibility element
.contain, which keeps inner elements independent but ensures they are navigated consecutively

By reading @Environment(\.accessibilityVoiceOverEnabled), the PLP can adapt its child grouping behavior at runtime. When VoiceOver is running, the product information and its actions are presented as a single combined element. When it is not, the elements remain separate and independently focusable for Full Keyboard Access and Voice Control.

HStack {

    NavigationLink(destination: ProductDetailView(product: product)) {

        ProductCellNoButtons(product: product)

    }

    VStack {

        // Cart and Wishlist Buttons

    }

}

.accessibilityElement(children: isVoiceOverEnabled ? .combine : .contain)

Now that the elements are grouped so VoiceOver can navigate each product as a single unit without affecting other assistive technologies, the question becomes: where should the accessibility actions live? In this case, nowhere at all.

When using .combine, buttons are not merged into the spoken label; instead, they are automatically exposed as accessibility actions. We just need to provide them with the correct label beforehand and the magic happens.

The result is a single, efficient element with contextual actions when VoiceOver is enabled, and three distinct, independently focusable elements when it is not.

In this case, optimizing for multiple assistive technologies resulted not only in a more accessible interface overall, but also in the same VoiceOver navigation with less code.

Once we accept conditional accessibility as a valid pattern, it opens the door to more ambitious VoiceOver optimizations elsewhere in the app.

PDP Options Becoming Adjustable

One advantage of native mobile development over the web is the richer toolkit it offers to assistive technology users, especially when it comes to optimizing navigation for screen readers.

SwiftUI offers the accessibilityRepresentation modifier, which lets us expose an alternative accessibility-only control for a complex UI.

For color and storage selection, a picker could be much faster to navigate for VoiceOver users, presenting a single element to focus on, where its value can be changed by flicking up and down. So, at the end of the VStack containing the color label and options, we can add:

.accessibilityRepresentation {

    Picker("Please choose a color", selection: $selectedColor) {

        ForEach(colors, id: \.self) {

            Text($0.description)

        }

    }

    .pickerStyle(.wheel)

}

This works beautifully once focused, but in iOS 18 it doesn’t always appear in the expected place in the swipe order.

To fix the order while preserving the same interaction model, we can manually implement adjustable behavior using accessibilityAdjustableAction. This lets us define what happens when the user performs an increment or decrement gesture. We also set an accessibility label, ignore children, and provide a meaningful value for VoiceOver to report when the user performs the adjust gesture.

So, instead of accessibilityRepresentation, the color selection VStack gets these modifiers:

.accessibilityElement(children: .ignore)

.accessibilityLabel("Available colors")

.accessibilityValue(colors[selectedColor].description.capitalized)

.accessibilityAdjustableAction { direction in

    switch (direction) {

        case .decrement:

            if selectedColor > 0 { selectedColor -= 1}

        case .increment:

            if selectedColor < (colors.count - 1) { selectedColor += 1}

        default:

            break

    }

}

How does VoiceOver behave now?

The UI doesn’t visually change, but VoiceOver now announces the whole group as “Available colors: Blue, adjustable.” Flicking up or down cycles through the color options, and the visual selection updates accordingly. The same logic was implemented in the storage options.

When One Fix Breaks Another

What happens to Full Keyboard Access once we introduce the adjustable elements used to improve VoiceOver navigation?

Full Keyboard Access now treats the color and storage selectors as single focusable elements, just like VoiceOver does. Using the left and right arrow keys adjusts their values.

Unlike VoiceOver, however, there’s no spoken feedback when the value changes. Whether this is an optimal experience for keyboard-only users is debatable.

This highlights an important point: improving one assistive technology can subtly affect others, sometimes positively, sometimes in ways that need further iteration.

And how does Voice Control react to these VoiceOver enhancements?

This is where things start to fall apart.

By turning the color and storage options into adjustable elements for VoiceOver, Voice Control effectively stops working for those controls. What were previously exposed as individual, actionable buttons can no longer be reliably targeted using voice commands once they become a single adjustable element.

Nothing changed visually and the VoiceOver experience improved significantly, but for Voice Control users these controls effectively disappeared.

Optimizing VoiceOver Without Collateral Damage

Once again, we can rely on @Environment(\.accessibilityVoiceOverEnabled) to apply VoiceOver-specific enhancements, without negatively affecting Full Keyboard Access or, especially, Voice Control users.

When VoiceOver is enabled, we use adjustable actions to make navigation faster and more efficient. When it is not, we fall back to the original implementation, exposing individual buttons that work well with Voice Control and Full Keyboard Access.

To avoid duplicating layout code, we can extract the original color options into a @ViewBuilder property and reuse it in both cases. The same pattern applies to the storage options.

if isVoiceOverEnabled {

    colorOptions // our @ViewBuilder property

    .accessibilityElement(children: .ignore)

// all previously used VoiceOver-specific adjustable modifiers

} else {

    colorOptions // just the normal View

}

Does this approach restore Voice Control?

In the video, I turn VoiceOver off and use Voice Control to tap individual color and storage options, exactly as before introducing the VoiceOver enhancements. When VoiceOver is turned back on, those same controls are once again exposed as adjustable elements.

Each assistive technology now gets the interaction model it expects.

What about Full Keyboard Access?

Here too, the behavior returns to what keyboard users expect. I can navigate between individual buttons using the arrow keys, and selections only change when I explicitly activate a control, rather than adjusting values automatically with every left or right press.

Navigation is now accessible to Full Keyboard Access and Voice Control users, and when VoiceOver is running, the already accessible interface becomes even more efficient for VoiceOver users.

Same Pattern Added to the Wishlist

The same conditional accessibility pattern used in SwiftUI can also be applied to the Wishlist, which is implemented in UIKit using a UICollectionView.

UIKit doesn’t expose accessibility state through an environment like SwiftUI does. Instead, we need to query VoiceOver directly and react to changes imperatively.

We can check whether VoiceOver is currently running using UIAccessibility.isVoiceOverRunning. And because UIKit is notification-driven, we should also observe changes to that state:

NotificationCenter.default.addObserver(

    self,

    selector: #selector(voiceOverStatusDidChange),

    name: UIAccessibility.voiceOverStatusDidChangeNotification,

    object: nil)

This allows us to switch between two accessibility configurations at runtime: one optimized for VoiceOver, and one that preserves the expected behavior for Full Keyboard Access and Voice Control.

When VoiceOver is running, instead of exposing the product information stack and the Cart/Wishlist buttons as separate elements, we make the entire cell accessible as a single element and attach accessibility actions.

For VoiceOver users, this results in:

One swipe per product
Product information read as a single coherent summary
A standard double-tap that opens the Product Detail Page
Cart and Wishlist actions available via the rotor

To do this, we mark the entire cell as an accessibility element and provide a meaningful label, hint, and traits, and then we add the Cart and Wishlist actions:

self.isAccessibilityElement = true

self.accessibilityLabel = "\(product.name), \(product.price), rated \(product.ratingAsString)"

self.accessibilityHint = "Swipe up or down to select a custom action"

self.accessibilityTraits = [.button]


let addToCartAction = UIAccessibilityCustomAction(name: "Add to Cart") { _ in

    self.onAddToCartButtonTap?()

    return true

}

let wishlistAction = UIAccessibilityCustomAction(name: "Remove from Wishlist") { _ in

    self.onWishlistButtonTap?()

    return true

}

self.accessibilityCustomActions = [addToCartAction, wishlistAction]

Finally, we restore the default VoiceOver behavior of opening the Product Detail Page when the user double-taps the element. In UIKit, this is done by overriding accessibilityActivate:

override func accessibilityActivate() -> Bool {

    self.onAccessibilityActivate?()

    return true

}

The collection view controller already knows how to open the PDP via didSelectItemAt, so it simply provides the same logic through the onAccessibilityActivate closure.

One Wishlist, Various Wishes Fulfilled

So how does VoiceOver navigate now, and how does this affect the other assistive technologies?

In the video, I start with VoiceOver enabled. The Wishlist behaves as intended: each product is a single element, with custom actions for adding to the cart and removing from the wishlist, and a standard activate action that opens the Product Detail Page.

I then turn VoiceOver off and back on again. Because of an intentional bug in the demo, the VoiceOver-optimized configuration is not re-enabled, and the interface remains in its original accessible configuration even with VoiceOver running.

In this state, the product information and buttons are exposed as separate elements. This allows Full Keyboard Access users to navigate between the product information, the Cart button, and the Wishlist button using arrow keys or Control–Tab, and to activate each one directly. This mirrors the original behavior that also allows Voice Control users to reliably target and activate individual buttons.

If the VoiceOver-style custom actions were always enabled, Full Keyboard Access users would need to press Tab + Z to reach the Cart and Wishlist actions, and Voice Control users would lose access to those controls.

By switching accessibility behavior based on whether VoiceOver is running, each assistive technology gets the interaction model it expects, without forcing compromises on the others.

Final thoughts

Improving the VoiceOver experience is second nature to me as a VoiceOver user, and I usually know early what kind of navigation and interaction I want.

In the previous articles, I faced a familiar challenge: optimizing for VoiceOver can sometimes conflict with Full Keyboard Access or Voice Control. That’s why I first made the PDP, PLP, and Wishlist accessible to additional assistive technologies, and only then introduced VoiceOver-specific refinements in this article.

With the foundation in place, we could optimize the interface for VoiceOver users. In SwiftUI, this meant reading environment values to detect when VoiceOver was active; in UIKit, we queried UIAccessibility.isVoiceOverRunning and responded to state changes. We also implemented several strategies to streamline navigation and interaction: adjustable controls for faster option selection, .combine to merge elements while exposing buttons as actions, and custom accessibility actions in UIKit.

Nothing changed visually, and nothing was removed. Yet each assistive technology now receives an interaction model tailored to how it works. Different tools, different APIs, same result: a more efficient and intuitive VoiceOver experience, fully accessible to Full Keyboard Access and Voice Control users.

I’m deeply passionate about both iOS development and accessibility. If your iOS team needs someone who truly cares about accessibility and great user experience, I am open to new assignments. Drop me an email at [email protected].

Making an iOS E-Commerce Product List Accessible to VoiceOver and Beyond

Diogo Melo — Thu, 08 Jan 2026 10:17:13 +0000

For a webinar on November 11, I wanted to show how I code and test iOS apps using VoiceOver as a blind developer. To make it realistic, I built a small e-commerce prototype that naturally ended up with the same types of accessibility issues I often encounter in real projects. The premise was simple: build the app “normally,” without deliberately creating accessibility issues, and then fix whatever emerged, all without changing a single pixel of its visual design. This article walks through how I improved the VoiceOver experience on the Product List Page (PLP) and the Wishlist, and how those changes impacted Full Keyboard Access and Voice Control.

The article about the Product Detail Page can be read here: Making an iOS E-Commerce Product Detail Page Accessible to VoiceOver and Beyond

And the full webinar recording is available here: Webinar Developing and testing iOS Apps using a screen reader with Diogo Melo

Product List Page: The Hidden Problems

The PLP is built in SwiftUI using a NavigationStack. Each row is a product cell containing:

A small image on the left
The product’s name, description, price, and a star-based rating in the middle
Tapping the product name or information opens the Product Detail Page
“Add to Cart” and “Wishlist” buttons on the right, with the heart icon reflecting the wishlist state)

In code terms: an HStack containing the image, a VStack with product information (including an HStack for the stars), and a second VStack for the action buttons.

In the first implementation, VoiceOver skipped the star rating entirely and didn’t expose the Add-to-Cart or Wishlist actions. Because the entire row sat inside a NavigationLink, VoiceOver treated everything as one big “button,” leaving the product actions completely unreachable.

Labels and Actions: Fixing the PLP

The star icons were not being read at all. To fix this, I gave them a proper label. Since they’re rendered inside a ForEach, I needed to collapse them into a single accessibility element to avoid repeated labels and present the rating as one meaningful unit.

HStack {
ForEach(0..
Now VoiceOver announces a clean “Rating: 4.5” instead of ignoring the stars or reading “star, star, star…”
To expose the Add to Cart and Wishlist options, I used accessibility actions. Embedding interactive controls inside a NavigationLink is inherently problematic for VoiceOver, so actions were the cleanest approach. At the very end of the product cell, I added:
.accessibilityAction(named: existsInWishlist(product)
? "Remove from Wishlist"
: "Add to Wishlist") {
addOrRemoveFromWishlist(product)
}
.accessibilityAction(named: "Add to Cart") {
addToCart(product)
}
SwiftUI uses a LIFO order when presenting actions to VoiceOver, so I wrote them in reverse to get the correct order in the rotor.

With these changes, VoiceOver now announces the product rating properly and clearly indicates that actions are available. The user can swipe up or down to pick “Add to Cart” or “Add to Wishlist” and the Wishlist action is dynamically updated (e.g., “Remove from Wishlist” after adding).
This preserves the visual layout while giving screen-reader users full, efficient control.
Wishlist: Too Much Information
The wishlist is implemented in UIKit using a UICollectionView. Each cell contains:

A vertical stack of product name, price, and rating
Tapping any of these informative elements opens the Product Detail Page
Buttons to add to cart and remove from wishlist

VoiceOver originally treated every subview in the cell as its own element. The star rating came through as an image, and the Wishlist button even switched languages briefly before just saying Wishlist.

Navigating a single product required multiple swipes. Imagine doing that across dozens of items.

Fixing the Wishlist: Grouping Information

To make the experience smoother, the product information needed to be treated as one coherent unit.
To group and label the information stack, I set it as an accessibility element and gave it a proper label. I also gave the Wishlist button a clear, explicit label:

infoStackView.isAccessibilityElement = true
infoStackView.accessibilityLabel = "\(name), \(price), rated \(ratingAsString)"
wishlistButton.accessibilityLabel = "Remove from Wishlist"

Now VoiceOver focuses the entire information block at once and reads it naturally as a single product summary, just like a sighted user perceives it visually.

VoiceOver focuses first on the product information and then navigates to the Cart and Wishlist buttons. It still requires more than one swipe per product, but the flow is much improved.

Added to the Wishlist: Keyboard and Voice Control

After fixing the Wishlist for VoiceOver, I tested the same implementation with Full Keyboard Access to see whether the changes translated beyond screen-reader use.

Using Tab or arrow navigation, Full Keyboard Access can now reach all three meaningful elements in each cell: the grouped product information (which opens the Product Detail Page), the Add to Cart button, and the Remove from Wishlist button.

Grouping the product information for VoiceOver also made it reachable by Full Keyboard Access. Before this change (not shown in the initial demo), keyboard navigation could reach the buttons but skipped the product information entirely.

I then tested the same Wishlist implementation using Voice Control.

Voice Control correctly presents numbers for each actionable element: one for the product information that opens the Product Detail Page, and separate numbers for the Add to Cart and Remove from Wishlist buttons.

In this case, improving element grouping for VoiceOver also produced immediate benefits for Voice Control. Even when using “Show Numbers,” Voice Control exposed all elements with their correct, meaningful labels.

We have a PLP Problem

Testing the improved Product List Page with Full Keyboard Access produced mixed results.

On the one hand, keyboard navigation could move between products using arrow keys or Control–Tab. On the other hand, the Add to Cart and Add/Remove from Wishlist buttons were not focusable at all.

Full Keyboard Access users can still reach these actions by pressing Tab + Z, which opens the accessibility actions menu and allows the selected action to be activated.

However, accessibility actions are not exposed to Voice Control at all. As a result, Voice Control users can only open the product page and cannot access the cart or Wishlist actions at all.

Breaking the Original Premise

Earlier, I set a constraint for this demo: I would not change a single pixel of the original design. To resolve this issue, I had to slightly relax that rule.

On the Product List Page, instead of wrapping the entire product cell in a NavigationLink, I limited the link to the product image and information. The Cart and Wishlist buttons were moved outside of it.

HStack {
NavigationLink(destination: ProductDetailView(product: product)) {
ProductCellNoButtons(product: product)
}
VStack {
// Cart and Wishlist Buttons
}
}

Visually, this moves the chevron indicator so that it appears before the Cart and Wishlist buttons rather than after them. As a blind developer rather than a visual design expert, I can’t say which layout is more common, but the change is subtle and does not alter the overall structure of the list.

With this structure, Voice Control users can now activate all product actions directly.

Because VoiceOver and Voice Control do not always cooperate (Voice Control overlays are not consistently read by VoiceOver), in this demo I activate actions without VoiceOver feedback and confirm them afterward.

I could add a product to the Cart by saying “Tap 2,” add and remove it from the Wishlist using “Tap 3,” and finally open the Product Detail Page with “Tap 1”

And the same approach works to Full Keyboard Access users.

Navigating with the arrow keys or Control–Tab now focuses on the three actionable elements per product: the product information, the Add to Cart button, and the Wishlist button. Each can be activated directly using the Space bar, without invoking the accessibility actions menu.

Using VoiceOver, navigation now requires more swipes per product because each element is treated separately. From my perspective as a VoiceOver user, although the interface is functionally correct, I prefer the original single-element approach with accessibility actions, which allows quicker navigation and easier access to all available options.

In a future article, we will explore strategies to optimize for VoiceOver navigation without conflicting with other assistive technologies.

Final thoughts

Making the Wishlist accessible in UIKit turned out to be relatively straightforward. By grouping elements the way sighted users visually perceive them and providing clear, explicit labels, VoiceOver navigation improved immediately. Those same changes translated automatically to Full Keyboard Access and Voice Control, without requiring any additional adjustments.

The Product List Page required more iteration. Wrapping the entire product cell in a NavigationLink is a common SwiftUI pattern and works well visually, but it hides secondary actions from assistive technologies. Exposing those actions through accessibility actions improved the experience for VoiceOver and, to a degree, Full Keyboard Access. However, it left Voice Control users unable to interact with the Cart and Wishlist buttons.
By separating navigational content from action buttons, all assistive technologies could access every available action directly. The visual change was minimal, but the accessibility impact was significant.

This process highlighted an important distinction between assistive technologies. VoiceOver and Full Keyboard Access can benefit from accessibility actions, assuming users are informed of their existence. Voice Control, however, relies much more heavily on directly exposed, clearly labeled controls. If something is not a button, it is effectively invisible to voice interaction.

As someone who relies primarily on VoiceOver, this was a valuable perspective shift. Supporting Voice Control required rethinking interaction patterns I normally take for granted, and ultimately led to a more robust and inclusive Product List Page overall.

Making an iOS E-Commerce Product Detail Page Accessible to VoiceOver and Beyond

Diogo Melo — Mon, 22 Dec 2025 08:54:10 +0000

For a webinar on November 11, I wanted to show how I code and test iOS apps using VoiceOver as a blind developer. To make it realistic, I built a small e-commerce prototype that naturally ended up with the same types of accessibility issues I often encounter in real projects. The premise was simple: build the app “normally,” without deliberately creating accessibility issues, and then fix whatever emerged, all without changing a single pixel of its visual design. This article walks through how I improved the VoiceOver experience on the Product Detail Page (PDP), and how those changes impacted Full Keyboard Access and Voice Control.

The article about the Product List Page and Wishlist can be read here: Making an iOS E-Commerce Product List Accessible to VoiceOver and Beyond

And the full webinar recording is available here: Webinar Developing and testing iOS Apps using a screen reader with Diogo Melo.

The Accessibility Issues Hiding in Plain Sight

The Product Detail Page is implemented in SwiftUI and presents quite a lot of information:

A large product image — in this demo it’s an SF Symbol rather than a real image
The product name as the page’s headline
The product star rating and price
The product’s color and storage options, represented as buttons with hard-coded demo values
A generic product description
A small text label that announces the currently selected color and storage (added purely for early accessibility testing)
The Add to Cart and Add to Wishlist buttons, with the latter updating visually depending on wishlist status

In code terms, everything lives inside a VStack within a ScrollView, with inner HStacks for the star rating, color options, storage options, and the Cart/Wishlist buttons.

Testing the first (accessibility-unfocused) version with VoiceOver revealed several issues. The most noticeable one was the star rating: each individual star was treated as a separate image, and VoiceOver tried to run image recognition on each one (“A yellow star against a black background”). The color buttons produced even stranger results (“night sky”, “outdoor”, “chart”, or nothing at all), and VoiceOver didn’t even identify them as buttons.

There were also structural issues:

The decorative product image should not be spoken at all
The product name and description were not identified as headings
The wishlist button didn’t reflect its current state
While VoiceOver could read the storage options, it didn’t indicate which one was selected.

Hide-and-Seek (Labels and Headings)

I started by collapsing the star rating into a single accessibility element, to avoid it being navigated repeatedly, and to give it a single clear label.

HStack {
    ForEach(0..<5, id: \.self) { _ in

        Image(systemName: "star.fill")

    }

}

.accessibilityElement(children: .ignore)

.accessibilityLabel(ratingAsString)

Next, I hid the decorative product image and marked the product name and the “Description” label as headings:

Image(systemName: product.imageName) // proper formatting skipped

.accessibilityHidden(true)

...

Text(productName)

.font(.title)

.accessibilityAddTraits(.isHeader)

...

Text("Description")

.font(.headline)

.accessibilityAddTraits(.isHeader)

.accessibilityHeading( .h2)

Since iOS 18, VoiceOver supports heading levels (1 to 6), just like on the web. I used level 2 here to maintain a logical structure. As far as I can tell as a VoiceOver user, the levels don’t currently change the interaction experience, but I’d love for that to matter one day. For now, I’m just trying to get developers to include any headings at all.

Finally, the wishlist state needed to match the visual toggle. If the app uses one dynamic button, we can simply attach a dynamic label:

// button whose state depends on whether the product is on the wishlist

.accessibilityLabel(existsInWishlist(product) ? "Remove from Wishlist" : "Add to Wishlist")

If the UI uses two different buttons, one for each state, each button just needs its own static label:

If existsInWishlist(product) {

// button to remove product from wishlist

.accessibilityLabel("Remove from Wishlist")

} else {

// button to add product to Wishlist

.accessibilityLabel("Add to Wishlist")

}

Turning Visual Selection Into Accessible Feedback

The storage button was already labeled properly, but VoiceOver had no idea which storage option was selected. To fix that, I added the .isSelected trait so the accessibility state reflects the visual state:

Button(storage) {

    selectedStorage = storageOptions.firstIndex(of: storage) ?? 0

}

.background(storageOptions[selectedStorage] == storage ? Color.blue : Color.gray)

.accessibilityAddTraits(storageOptions[selectedStorage] == storage ? .isSelected : [])

For the color options, the logic is similar. We add the .isSelected trait, give each option the .isButton trait (as explained in this previous article), and give each option a meaningful label:

Circle()

.fill(color)

.overlay(

    Circle()

    .stroke(colors[selectedColor] == color ? Color.blue : Color.clear)

.onTapGesture {

    selectedColor = colors.firstIndex(of: color) ?? 0

}

.accessibilityLabel(color.description.capitalized)

.accessibilityAddTraits( colors[selectedColor] == color ? [.isButton, .isSelected] : [.isButton])

Let’s see how all of this changes the experience.

Bringing the Page to Life With VoiceOver

With these fixes, navigating the product page with VoiceOver starts behaving exactly how a sighted user would expect.

The product name is now read as a heading, and the star rating is a single, clear element.

Color and storage options are read as buttons, and double-tapping to select one announces the new choice as Selected.

The description header can be navigated via the rotor’s heading mode.

And the wishlist button correctly reports whether it will add or remove the item. It also reports the “Remove from Wishlist” button as Selected using the .isSelected trait. This is more of a personal preference, as some apps do this and I intuitively expect it as a VoiceOver user.

In short, the PDP now communicates structure, meaning, and state, not just raw UI fragments.

A Little Less Full Keyboard Access

Testing the accessible version of the PDP with Full Keyboard Access (FKA) mostly works as expected.

Using Tab navigation, I can reach:

The back button
All the color and storage options
Add to Cart
Add to Wishlist / Remove from Wishlist

However, one unexpected element appears in the tab order: the star rating.

Even though it isn’t interactive, Full Keyboard Access treats it as focusable. This happens because collapsing the stars into a single accessibility element implicitly marks it as something the user might want to interact with.

To fix this, we can explicitly mark the element as static text by adding the .isStaticText trait:

HStack {

    // ForEach with star rating

}

.accessibilityElement(children: .ignore)

.accessibilityAddTraits(.isStaticText)

.accessibilityLabel(ratingAsString)

This tells Full Keyboard Access exactly what this element is: decorative information presented as text. Once marked correctly, it’s skipped during keyboard navigation.

Voice Control Comes Along for Free

Testing the PDP with Voice Control shows that the same accessibility improvements translate cleanly to voice-based interaction, with no additional effort.

Like with Full Keyboard Access, all interactive elements are exposed correctly:

All color and storage options
Add to Cart
Add to Wishlist / Remove from Wishlist
Tab bar navigation

Voice Control identifies these elements as tappable and allows them to be activated using spoken commands.

Because Voice Control relies heavily on accessibility labels, the earlier work of adding meaningful labels, button traits, and selected states pays off here without any Voice Control–specific code.

Final thoughts

Making the Product Detail Page accessible to VoiceOver turned out not to be a complex or disruptive task. Most of the work involved hiding or collapsing purely decorative elements, providing meaningful labels, and using the correct accessibility traits to reflect structure and state. None of these changes required visual redesigns or custom accessibility workarounds, just more intentional use of the APIs SwiftUI already provides.

Even though this article focused primarily on VoiceOver, testing along the way showed an important pattern: improvements made with VoiceOver in mind often benefit other assistive technologies as well. Full Keyboard Access became more predictable once roles were clearly defined, and Voice Control was able to expose and activate all interactive elements without any technology-specific code.

In that sense, Voice Control works as a powerful validation tool. If an element can’t be easily activated by voice, it’s often a sign that its accessibility role, labeling, or structure needs improvement.

In the webinar, I also presented a more VoiceOver-optimized version of this Product Detail Page, exploring what happens when we go beyond baseline accessibility and start enhancing navigation and interaction patterns. That version, and how to make it work without breaking Full Keyboard Access or Voice Control, will be covered in the next article.

Accessibility of Fuel and EV Charging Stations: Wheelchair user insights and the European Accessibility Act

Nathalie Pentler — Fri, 12 Dec 2025 16:38:03 +0000

Wheelchair users experience accessibility challenges at fuel and charging stations that most people never notice. The issue isn’t our disabilities, but the way fuel and charging stations are designed. This is finally starting to change. The European Accessibility Act (EAA) now requires self-service terminals to be accessible, which is a big deal for anyone who has ever struggled with a poorly placed payment screen.

Many people don’t realize that a large number of wheelchair users drive their own cars. As a result, it is often challenging or even impossible to refuel or charge cars independently.

For an example of how some wheelchair users drive or get in their cars, have a look at this video by Kathryn Granger.

What Wheelchair Users Experience at Fuel or Charging Stations

I use a wheelchair myself, but I don’t have a driving license yet. Since the European Accessibility Act (EAA) is now law all across the EU, I wanted to ask drivers with disabilities how it actually works for them to charge or refuel their cars here in Sweden. Spoiler alert: It is not going very well.

1. Needing assistance because of the inaccessibility

Many wheelchair users can’t refuel or charge independently because of the inaccessible stations. Having to depend on others is frustrating and can be very time-consuming.

“I can’t do it myself, I always need to bring someone that can help me.”

“I need to call the store and ask the staff to come out and help me”.

“Last time, along the E4 highway, it took over 40 minutes before anyone had time to help me.”

“My partner refuels the car for me. Otherwise I would probably call the station and ask someone to help me solve the problem.”

2. Steps and Curbs Are Major Obstacles

A single step or curb can make a station inaccessible. Poorly placed payment terminals that are high up or tucked away on narrow platforms are difficult or impossible to use independently.

“Many times there’s a step up to the card machine or the fuel pump.”

“The payment terminal is placed high up because of the curb and because it’s positioned further in on the platform. Many of them can’t be reached at all when they’re placed far back on a high, narrow ledge”.

3. Equipment is Out of Reach

Even without steps, equipment is often mounted too high. Buttons to select fuel type, card readers, and screens are designed for standing users.

“Many have a small ledge/plateau on which the machines stand, making them difficult to reach. On others, the number pad for the card terminal is positioned far too high.”

“The difficult part is that some diesel pumps have buttons to choose between car or truck fueling placed too high. I’ve learned that if you wait, it will start in car mode anyway, but it was really frustrating before I figured that out, and I had to ask passersby to press the button.”

4. Unstaffed Stations Are a Problem

When no staff are available, wheelchair users have to rely on other people or plan their drives based on where the staffed stations are. This creates both practical and safety concerns.

“I try to avoid unstaffed stations, but sometimes there’s no choice. I didn’t choose an electric car because I feared it would be even harder.”

“I try to plan to refuel on one of the days I have an assistant, but sometimes I forget, so then I have to try to find a staffed station.”

“Unstaffed stations are often difficult, with a step up to the card reader. If it had at least been turned around, it would have worked better and been accessible from the side.”

5. Big Differences Between Stations

Not all stations are equal. Some chains have pumps and card readers at lower heights. Others still require climbing onto concrete platforms.

“I almost always refuel at the same chain, and I never experience any issues there. The payment terminal is angled outward and even though it’s mounted a bit higher, it’s still reachable from a wheelchair.”

“The station where I live has a lower pump that I can use from my wheelchair.”

“Certain pumps work well because I can reach to insert my card and enter my PIN while staying in my wheelchair. The least accessible ones are those where you have to get up onto a concrete platform just to use the card reader.”

6. Apps Make it Easier

More and more companies are making it possible to use apps to control refueling or charging, which can solve many of these problems. But it’s important to remember that while digital solutions make it much easier for many, the apps themselves need to be accessible as well.

“Many providers offer the option to control the refueling process through a mobile app instead of using the physical terminal on site.”

“I use a fuel provider that also has an app where I can select the pump and start refueling, so I don’t have to deal with the barrier around the pump that makes it hard to reach the card terminal.”

Summary of wheelchair users’ experiences at fuel and charging stations

Many need assistance and are forced to plan their trips accordingly.
Steps and curbs are both common and major obstacles.
Reaching pumps, chargers, and payment equipment is often difficult.
Unstaffed stations are even more challenging since no help is available.
The level of accessibility varies between stations.
Apps can simplify refueling and charging.

Fuel and Charging Stations under the European Accessibility Act

The European Accessibility Act has been in place since June 28 2025. This law covers products such as payment terminals and self-service terminals at fuel and charging stations and in other settings.

The EAA states that controls and interfaces should be within reach and not require great strength or fine motor skills. Detailed requirements are specified in the European standard EN 301 549. According to the current version of the EN standard, controls or “operable parts” should be placed roughly between 38 cm and 122 cm from the ground (the exact measurements are under revision and will be specified in the upcoming version of EN 301 549).

Other requirements include possibilities to extend the time given to perform a task, which is important for wheelchair users who might need extra time to navigate the fuel or charging stations.

For a deeper dive into the legal requirements and detailed examples from the EAA, you can read our article European Accessibility Act (EAA) – Kiosks, touch screens and physical devices.

It is also important to note that inaccessible fuel or charging stations may fall under national discrimination laws and lead to legal consequences. This has already happened in Sweden, where a fuel station company was found guilty of discrimination against a wheelchair user. Read more in an article by DHR (in Swedish).

A new specification for accessible charging stations has been published

A new Swedish accessibility specification for charging stations has been published by SIS in collaboration with disability organizations like DHR and BraunAbility. The specification is called Tillgängliga laddningsplatser för elfordon – Krav och rekommendationer (Accessible recharging stations for electric road vehicles — Requirements and recommendations).

The goal of the technical specification is to create clear requirements for how charging sites should be designed in order to be usable for people with different levels of mobility, length or hand strength. The specification covers everything from site layout to digital interfaces and other interactive systems that are required for charging an electric vehicle. It is intended to guide both new construction and upgrades of existing stations. If widely adopted, this work can remove many of the barriers wheelchair users face today and make it possible for us to charge our cars more independently.

Want a helping hand?

We can help you audit and user test payment terminals, self-service terminals, and other physical machines. You will receive a clear report that shows whether your solution meets the requirements of the European Accessibility Act and EN 301 549.

Even when a product is not formally covered by the EAA, we can still support you in making it easier to use for people with disabilities.

If you would like help from accessibility specialists like me on your specific product or service, you can find our contact details in the footer below.

The independence that comes with driving your own car should not be taken away from people with disabilities, especially when other forms of transport can be even less accessible. Improving accessibility at fuel and charging stations is essential and benefits everyone, with or without disabilities.

Check out our accessibility consulting services or just drop us a message at [email protected] – we’re happy to help!

ADA’s New 2026 Deadline: What Tech Vendors Need To Know

Joel Holmberg — Wed, 10 Dec 2025 15:36:58 +0000

If your company builds websites, apps, or digital services for cities, counties, school districts, or any other state or local government body in the US—there’s a major accessibility deadline coming your way.

In April 2026, new ADA requirements come into force that make accessible digital services mandatory for state and local governments in the US. And since most of these governments depend heavily on external vendors for their digital solutions… it may also affect you.

This article walks you through:

What the ADA update says
Who must comply
The April 2026 deadline
Key exceptions
What vendors need to do now
How Axess Lab can help with accessibility audits and VPATs

Let’s dive in.

What’s happening in April 2026?

In 2024, the U.S. Department of Justice (DOJ) finalized a major update to the ADA—specifically focusing on State and local government websites, mobile apps, and digital services.

The rule requires all digital content provided by these public entities to meet WCAG 2.1 Level AA, the globally recognized accessibility standard.

The enforcement deadline is April 24, 2026 for larger public entities, with smaller ones getting a bit more time.

In short: accessibility is no longer a nice-to-have. It’s a legal requirement.

Who does this affect?

The rule applies to State and local governments in the US, but it has massive consequences for:

1. Tech vendors selling to US governments

If you provide:

Websites
Mobile apps
SaaS platforms
Ticketing systems
Payment portals
Parking apps
Transit apps
Public service kiosks
Scheduling or permit systems

…your software must be compliant.

2. Integrators and service providers

Companies that integrate digital systems for cities will also need to demonstrate conformance.

3. Agencies using off‑the‑shelf software

Even if a government entity buys a product “as is,” they are still legally responsible for its accessibility. Which means they’ll put pressure on you—the vendor.

When is the deadline?

The compliance deadlines depend on the size of the public entity:

Large public entities (50,000+ population): April 24, 2026
Smaller public entities: April 26, 2027

But here’s the key part for vendors:

You will start getting accessibility requirements from government clients long before 2026.

Cities and counties are already preparing their budgets, procurement language, and vendor requirements.

If your product isn’t accessible or you can’t provide a VPAT, you risk being excluded from bids.

Are there any exceptions?

Yes, but they’re limited;

Archived content

Old content not needed for active use may be exempt.

Third‑party content

Information posted by third parties on government platforms may not always be covered.

Certain live content

Real‑time streams without the technical ability to caption may have temporary exceptions.

Legacy documents

PDFs and documents published before the compliance date may have limited exceptions.

But the rule is clear: websites, apps, and core digital services must meet WCAG 2.1 AA.

Most exceptions do not apply to vendor‑provided apps or SaaS platforms.

What should tech vendors do now?

Government agencies will increasingly ask for formal proof of accessibility.

Here’s how to prepare:

1. Get an accessibility audit

A WCAG audit by independent specialists gives you:

A full list of accessibility issues
Clear remediation instructions
Prioritized fixes
Evidence for procurement reviews

Accessibility Audits

2. Publish a VPAT

A VPAT (Voluntary Product Accessibility Template) is often required during procurement.

It tells government buyers exactly how your product meets accessibility standards.

VPAT Services

3. Start remediation early

Fixing accessibility takes time—especially if your product has grown organically over many years.

Starting early avoids rushed fixes and failed procurement bids.

4. Train your teams

Developers, designers, product managers, and QA teams should understand accessibility basics.

Government clients increasingly expect vendors to prove accessibility maturity.

In order to stay compliant over time you need your teams to master at least the basics of accessibility without relying on external specialists.

Accessibility training, workshops and talks

Why this matters: more than compliance

Beyond legal risk, accessible products perform better:

Better UX for everyone
Improved SEO
Improved AI discoverability
Better performance on mobile
Expanded market reach
Lower future remediation costs

And of course—you help ensure equal access to public services.

How Axess Lab can help

We help Saas companies and tech vendors meet accessibility requirements by offering:

Professional accessibility audits

Identify issues early and get a clear roadmap for compliance.

VPAT creation & publication

We create accurate and industry‑standard VPATs that help you win government contracts.

Developer & designer training

Empower your teams to build accessible features from the start. We offer live teacher-led training remote or on-site as well as on-demand online courses.

Ongoing accessibility support

We partner with companies long‑term to maintain compliance as products evolve. From a shared Slack channel for quick questions to a full time Accessibility Lead from Axess Lab – whatever works best for you!

Book a chat with our team

Final thoughts

The April 2026 ADA deadline is coming fast—and state and local governments are already preparing.

If you provide digital solutions to the public sector, accessibility is now a mandatory part of your product.

The good news? You don’t have to navigate it alone.

Axess Lab is here to help you meet the requirements, win bids, and build products that everyone can use.

Check out our accessibility consulting services or just drop us a message at [email protected] – we’re happy to help!

VPAT – Volountary Product Accessibility Template

Joel Holmberg — Wed, 10 Dec 2025 11:00:23 +0000

Are you looking to comply with the ADA, perhaps in order to win government contracts in the US, or just to show the world you care about accessibility and inclusion? Then you need something called a “VPAT”. Here is what that means!

What is a VPAT?

The Voluntary Product Accessibility Template is a document outlining how well your product complies with accessibility regulations.

It contains information about any existing accessibility issues and how well you conform with each requirement in standards like the WCAG.

This document allows buyers to assess how well your product will work for users with disabilities, so that they can decide if they want to, or even are allowed to purchase and use your product in their daily operations.

You can create this document yourself. However it usually requires an accessibility audit be done to find any accessibility issues first. That can be difficult and time consuming for a non specialist to do.

Why use a VPAT?

The Americans with Disabilities Act (ADA) was recently clarified to enforce state and local governments in the US provide accessible websites and apps to their citizens. This includes such software provided via 3rd party vendors.

You can read more about what this means for vendors but basically:

IF you sell to state or local governments in the US
And IF your product or service includes a website or app
THEN the website or app has to comply with accessibility guidelines (WCAG 2.1 AA) for governments to be allowed to buy it
The VPAT document is the formal way to show them how your product conforms to such guidelines

How do I get one?

In order to put together a VPAT you need to know all accessibility issues your product or service has. Preferably you’ll want to fix any major issues before publishing a VPAT which contains the remaining issues and workarounds for them.

Contract a specialist to audit your website or app and compile a list of issues
Work on solving the major issues (Axess Lab reports are prioritized and contain suggested solutions in design and code)
Check for any remaining issues (for reference, acceptance tests are 30% of the original audit price at Axess Lab)
Create a VPAT using the report of remaining issues, or have someone like Axess Lab do it for you
Publish it on your website or link to it wherever you sell or describe your product, and have it ready to upload as a document in tenders or procurements.

What does it cost?

The big cost is finding the state of accessibility in your product. A VPAT document can be added for ~$1000 (Axess Lab price example) once there is a report to base it on.

You can also create it yourself using templates found online, if you know what you’re doing. Otherwise, feel free to book a free meeting with us and we can guide you through the whole thing:

Book a chat with our team

How Button Traits can make a chaotic iOS app accessible

Diogo Melo — Fri, 05 Dec 2025 12:18:37 +0000

A while ago, I was using an iPad app where the main call-to-action wasn’t marked as a button. As a blind VoiceOver user, I simply couldn’t find the one thing the entire screen was built around.
I tried tabbing with Full Keyboard Access; nothing.
I tried Voice Control; still nothing to target, nothing to say.

As an iOS developer, I remember thinking: “Surely this is easy to fix. Why does this problem still happen?”

So, naturally, I decided to intentionally build the most impossible-to-fix iOS app I could imagine, just to prove a point: if this can be fixed, then the same method can fix anything.

The Most Chaotic App I Could Build (On Purpose)

I built a tiny “game” that’s basically a psychological experiment disguised as a SwiftUI app: a 3×3 grid of playful tiles numbered 1 through 9. Behind them are four zeros, three small prizes, one €1M tile, and one haptic “shock.”
Players can take their single chance by tapping a tile, use “Hide Zeros” to remove the duds (at the cost of halving all prizes), or simply forfeit.
To push accessibility to its absolute limits, I deliberately filled the UI with decorative shapes stacked everywhere, purely to confuse assistive technology.

Watching Three Accessibility Systems Fall Apart

VoiceOver completely falls apart in this UI.

It treats every tile as several unrelated elements instead of a single action.
It first navigates a row of decorative images, then the tile numbers, then another row of decoration. Each tile ends up being five separate, non-adjacent items, none of them announced as buttons.
The “Rules”, “Forfeit”, and “Hide Zeros” elements are split into a pair of items each, and double-tapping the latter doesn’t work.
Navigating becomes a maze of noise.

To Full Keyboard Access, the interface is impossible to navigate.

Because I rely on VoiceOver, it is running in all demos.
Pressing Tab cycles only between the Screen Recording button and a single “disabled” region that represents the entire app.
None of the app’s elements can receive focus.
To the system, there is literally nothing interactive on screen.

Same issue with Voice Control: nothing is recognized as a button.

Voice Control offers zero commands in the app, not a single button name appears.
Even the tile numbers (“one”, “two”, “three”, etc.) don’t work as voice commands: the UI has no semantic structure, so the system can’t guess what’s interactive.

For all three accessibility systems, this app is a complete void.

Small Fixes With Great Impact on Usability

At this point, you’d think the solution requires custom actions, accessibility overlays, rewritten components, or rebuilding the app from scratch.
But no. All I needed were two tiny changes:
Group each tile’s internal visual elements so VoiceOver perceives the tile as a single thing, not many fragments.
Add the .accessibilityAddTraits(.isButton) modifier so iOS knows these elements are actions.

Here’s the simplest version:

// code block 1
ZStack {
    // unchanged chaotic visual layers
}
.accessibilityElement(children: .combine)
.accessibilityAddTraits(.isButton)

Sometimes combining the children wasn’t ideal, so I ignored them and added a custom label. Also, I needed a different approach when the user would hide zeros.
So a second pattern was necessary:

// code example 2
ZStack {
    // unchanged chaotic visual layers
}
.accessibilityElement(children: .ignore)
.accessibilityLabel(hideZeros ? "0" : tileNumber)
.accessibilityAddTraits(hideZeros ? .isStaticText : .isButton)
.disabled(hideZeros)

That’s it. No magic, no custom routing, just proper semantics.

Three Accessibility Systems Fixed at Once

Using VoiceOver, all the decorative noise disappears.

Each tile is now a single clearly announced element like “1, button,” “2, button,” and so on, plus the three action buttons.
VoiceOver even correctly reports dimmed zero tiles after using the “Hide Zeros” option.
Navigation becomes linear, predictable, and effortless.

Using Full Keyboard Access, all elements can be navigated through.

With semantics in place, the system can finally tab to each tile and to the “Hide Zeros” button.
Dimmed elements correctly prevent activation.
Nothing else changed, only the traits.

And with Voice Control, everything works now.

With proper names and traits, Voice Control immediately identifies the tiles and UI actions.
Users can activate actions by speaking the tile numbers or the action buttons, and it just works!

No special routing, no custom speech commands, no keyboard-shortcut handling…
Just proper semantics.

Final Thoughts: Accessibility Isn’t About Extra Work — It’s About Clarity

My absurd little 3×3 experiment taught me something important: .isButton isn’t just a convenience trait — it’s a foundational piece of accessibility across the entire iOS ecosystem. VoiceOver, Full Keyboard Access, Voice Control, Switch Control, and other assistive technologies all depend on these semantics.
Grouping elements and adding a single trait was all it took to turn an impossibly inaccessible interface into a fully navigable one.

Accessibility doesn’t mean adding complexity, it means giving the system the information it needs to help every user regardless of how they interact with your app.

If a UI as chaotic as this can be fixed with two modifiers, imagine how much impact you can have on a real-world interface.

EAA deadlines, why you probably can’t wait another 5 years!

Joel Holmberg — Fri, 28 Nov 2025 15:52:37 +0000

The European Accessibility Act (EAA) – formally Directive (EU) 2019/882 – became EU law 2019 and forces private companies to provide digitally accessible products and services to EU consumers. But when? Deadlines for companies can be hard to grasp because … it depends! Don’t worry though, this guide will clear it up!

Short version

Software like websites and apps need to be accessible by June 28, 2025.

Existing physical products sold or installed before June 28 2025 can remain in use for 5-20 years.

The basics

We go through the basics of EAA in our article European Accessibility Act (EAA) – What you need to know.

For self-service terminals, we explain more here: European Accessibility Act (EAA) – Kiosks, touch screens and physical devices.

But in a nutshell:

This EU directive was enacted 2019, and a grace period (let’s call it GP1) allowed EU countries until 2022 to enact this directive into local law.
The law was to give another grace period (GP2) for companies to comply until June 28, 2025. This gave companies three years to make their products and services accessible.
Since June 28, 2025, services like websites and apps, and digital products, like e-reader and TVs, must be accessible.
Some extended grace periods exist:
- Self-service terminals like ticket machines that are in place and which cannot reasonably be made accessible are allowed to stay inaccessible until replaced, but at most 20 years (GP3).
- Inaccessible physical products used to provide services can be used for up to 5 years. For example old ATMs or POS systems installed before June 28 2025 (GP4).
- Existing contracts signed with consumers before june 2025 can stay in place unchanged for up to 5 years (GP5).

Especially grace periods GP3-GP5 cause a lot of confusion, so let’s clear it up!

And to be clear, we are not lawyers so this is not legal advice, but we do know digital accessibility!

The confusion

The grace periods that exist after 2025 do indeed offer deadlines farther into the future. But it’s important to understand why they exist, and when it is allowed to use them.

Websites and apps are not products!

Extended grace periods are available for “products used to provide services”. However, this only means physical products! Websites and apps are not products! They are considered part of the service being provided.

Definition of “product” from Article 3 (2) in the EAA

‘product’ means a substance, preparation, or good produced through a manufacturing process, other than food, feed, living plants and animals, products of human origin and products of plants and animals relating directly to their future reproduction;

Products in place before June 28 2025

Products that cannot reasonably be made accessible after they have been installed are allowed to stay inaccessible until they are replaced or reach their end-of-life. This is intended for things like payment terminals or physical kiosks like ticket-machines that don’t go through regular updates, and where a re-design would require replacing the whole machine. Doing so would mean “old” but still functioning machines would be destroyed, which would be economically and ecologically unwise. A grace period exists for 5 years for such products, or 20 years for self-service terminals.

No such grace periods exist for websites and apps used to provide services.

Grace period wording in the EAA

“In order to allow service providers sufficient time to adapt to the requirements of this Directive, it is necessary to provide for a transitional period of five years after the date of application of this Directive, during which products used for the provision of a service which were placed on the market before that date do not need to comply with the accessibility requirements of this Directive unless they are replaced by the service providers during the transitional period.”

and

“Given the cost and long life-cycle of self-service terminals, it is appropriate to provide that, when such terminals are used in the provision of services, they may continue to be used until the end of their economic life, as long as they are not replaced during that period, but not for longer than 20 years.”

Existing contracts

If an EU consumer signed a contract before June 28, 2025 to use a service covered by the EAA, the company is allowed to keep that contract in place unchanged for up to 5 years even if the contract would break the EAA after June 28 2025. This includes if the contracts format and formalities are not fulfilling EAA requirements, as well as if the service that the contract is for is inaccessble.

This clause was likely added to the EAA because the EU wanted to avoid forcing companies to immediately rewrite millions of existing consumer contracts on 28 June 2025.

Many accessibility obligations affect:

terms & conditions
onboarding and account information
invoices, statements, contractual notices
customer support channels

If this exception didn’t exist, telecoms, banks, transport operators, etc. would need to terminate or renegotiate all current consumer contracts — which would be disruptive and legally risky.

Confusion

“Contracts” only means contracts between the service provider and consumer! Contracts between the service provider and its suppliers and subcontractors are irrelevant!

So for example if you are a bank and allow your users in the EU to trade stocks using a 3rd party software integrated in your banking app – it doesn’t matter that you signed the contract with the trading platform before June 2025 – the platform still has to be accessible by June 28 2025! Otherwise you are not allowed to accept new customers!

If you have a webshop where a 3rd party chatbot handles customer questions – and you signed the deal for the chatbot in 2024 – that doesn’t matter. The chatbot still must be accessible by June 28, 2025!

Here is a statement from the Swedish auditing agency PTS about their interpretation of this clause:

“Our interpretation is that transitional provision 4 refers to agreements between the service provider and the consumer, which I also understand to be your interpretation. This means that other agreements, for example an agreement between a service provider and a subcontractor, are not covered by the transitional provision according to our assessment.”

If you have an old service that you no longer offer to new customers after June 28 2025 – one that you make no updates for – then you are allowed to keep providing that inaccessible service for those customers who signed up before June 28 2025 until the contract ends, but at most 5 years. But you are not allowed to offer this service to new customers! So this exception is likely not for you!

Lets look at some cases to make it more concrete:

E-commerce website

Case: The website “Fashion Lab” sells clothes online. The website was built 2024 and has not changes since. Ana from Spain buys a T-shirt there in August 2025.

Question: Does the website have to be accesible?

Answer: Yes! The website is providing a service (e-commerce) which is a service covered by the EAA. Ana is an EU consumer so she is covered. The purchase means a new contract or transaction is made after june 28 2025. This means “Fashion Lab” cannot claim the grace period that allows existing contracts for use of inaccessible products or services to stay in place even after 2025. They cannot claim any of the grace periods for products since a website is not considered a product.

Banking app

Case: A banking app uses 3rd party software for some of the features they provide to consumers on the EU. They signed a contract for a trading platform and a peer-to-peer lending platform 2024, and provide access to these services through their own app. They are not accessible yet, but the bank accepts new customers daily.

Question: Does the app, including the trading and peer-to-peer lending features have to be accessible, and when?

Answer: The app provides banking services to EU consumers which means the service is covered by the EAA. For existing customers the app is allowed to keep providing these services until the next major release. However, since it’s possible to make the next release accessible (let someone audit and find issues, then fix them) there is no grace period that allows them to wait until 2030 to make the app accessible. And since there is no existing contract from before June 2025 with any new users – those have to be offered an accessible service from the day they sign up. So to summarize – yes, the app and all 3rd party software in it needs to be accessible for the bank to legally provide these services to new consumers after June 28 2025. The only way that the software can legally stay inaccessible is if they block new users, and make no updates, and allow only the current users access during their current contracts, but no longer than 5 years. In all other cases, it has to be accessible now, since June 28 2025!

Parking tickets, machine and app

Case: A parking company allows users to pay with an app, or use a physical self-service machine that takes card or coin payments. The machine has a touch-screen and buttons, but they are not reachable for wheelchair users, and the touch screen doesn’t conform with the EAA regulations. The app is not accessible.

Question: Is the company allowed to keep the machines installed and in use, and for how long?

Answer: Yes! Ticket machines are considered “Self-service terminals” and they have a grace period until end of life, at most 20 years. The next time the physical machine is replaced, the new version must conform with accessibility requirements. If a new release of the software is made for the machine, it needs to be accessible in the ways that it’s possible.

Question: Are they allowed to let their app be inaccessible, and for how long?

Answer: No! Apps are services, not products, and all services must be accessible from June 28, 2025. Technically they are allowed to keep pre-deadline users using the inaccessible app. But if they accept new users – they have to get an accessible version directly – so that exception is likely not relevant for most companies.

Question: If the app is made accessible, can they then keep installing new inaccessible machines after June 2025 since they provide an accessible option?

Answer: No! There is no exception for new self-service machines placed on the market after June 28 2025. Having an accessible app is great, and often the best way to allow users to use their own device and assistive tech to make sure they can use your services. But there is no exception for “equivalent accessible service” in the EAA. Notice that the law doesn’t care when your company purchased the machine, only when it was installed and “provided to the market”. So if you have a stockpile of inaccessible hardware that was purchased before June 28 2025, you are still not allowed to install it after this date.

Summary

Websites and apps used to deliver services covered by the EAA have to be accessible now. Even if you have supplier contracts signed before 2025 for software that you use.

And even though you are allowed to provide inaccessible experiences to existing customers for the remainder of their contracts signed before june 2025, you are still not allowed to sign up new customers for inaccessible services.

So if you havn’t started your accessibility journey yet – it’s probably time! Feel free to reach out and we’ll happily give you some suggestions on what you can do yourselves, and when it is appropriate to involve a specialist like Axess Lab.

If you have a case not covered by this post, let us know and we will make updates continuously!

Need help?

Check out our accessibility consulting services or just drop us a message at [email protected] – we’re happy to help!

Ads and accessibility mismatch

Erik Gustafsson Spagnoli — Fri, 21 Nov 2025 13:49:49 +0000

Ads online today are not built with accessibility in mind. I’ve asked if there are good ad-platforms out there and the answer is a silent tumbleweed rolling slowly across the dessert. Why is it like this? Time for advertisement platforms to step up!

Examples when it does not work

Contrast issues

Contrast issues affect all users and impacts users with vision loss most. It puzzles me that companies paying for ads do not think of visibility since they pay for creators the work and for the placement. This is too common on bus-ads where you have so little time when you are behind the bus driving or as a pedestrian. You should really, with good vision, be able to see it from 100m away. Don’t get me started on company cars with bad screen print, that’s format for another ranting article.

It’s important to have a look at 1.4.3 Contrast (Minimum) which says text must have 4.5:1 for regular text in contrast ratio. Large text can pass with 3:1.
Remember this is the minimum level and not maximum allowed level, so aim higher!

Ad for Elgiganten on Dn.se, default view:

Ad for Elgiganten, where green text has low contrast of 2.92:1 in contrast ratio:

Ad for Elgiganten, play button has very low contrast, 1.67:1 in ratio:

This ad for Skoda must win the contrast ratio with a staggering 1.01:1 in ratio:

ALT-text is missing

When making image ads that have a clear message to donate to a cause, in the example from Aftonbladet. Without vision you cannot donate to the cause since the ALT-text is missing. Thus you are being excluded.

I haven’t found any ads with meaningful alt-texts. Sometimes there’s a generic alt=“Ad” but this means you’re both excluding users and not getting the ad across to all potential users.

Text cut off on zoom

Some ads do resize with the content on zoom even if it’s an image, but the bounding box does not allow for increasing the space or changing from a 3 column view to 2 or 1 columns. The example on Coop.se shows content gets cut-off after 200% zoom and text-resize.

Default:

200% Zoom:

Text-resize of 200% (32px):

Overlapping when text is resized

Some ads actually have real text. But, the website or the advertisement platform is not adapting. While this ad probably works better in a screen reader, it’s impossible to read with larger text size set.

The example shows Dn.se Allsvenskan MAX ad fails resize text getting overflowed.

Default view:

Text resize 200% (32px) overlapping the text on top of each other:

Resize of page does not affect the ads.

Ads not affected by text-resize

For most people using text-resize in the browser the company will pay form the ad-view but the user will not see the ad text.

Text has been resized but does not affect the ad for Jula.

Default view without text-resize enabled:

Volkswagen ad does not resize the text:

Overflow fail

People use different widths on their browsers, sometimes to be able to use multiple programs on the same screen. Overflow fails when you narrow the window and the ad is just an image.

Example of SVD.se:

Strange inverted zoom

Ad on Aftonbladet.se for Blocket. Zooming in on content does the opposite for the ad and actually zooms out and decreases size. Clearly they have not tested this at all with accessibility in mind.

Let’s make it better

Use real text – not text as part of images

In the world of ads, sometimes you do not have a choice or it’s not easy to do. There are of course benefits to using real text since you can change the zoom without loosing quality – an image becomes pixelated when zooming.

Other benefits:

Text-resize
Change of color
High contrast modes
Font flexibility
It is possible to translate
Content is reusable for different formats and platforms.
Easier to adopt to dark mode

Links in images

If you do use a link (URL) in the image, be sure to make it short so the ALT-text also can be understandable. An image with a QR-code should state that the QR-code is in the image and also where it leads. Using a QR-code could be easier for some since they do not have to memorize the link.

For all text content in an image you need to consider 2.5.3 Label in name.

What should you include in ALT-text?

As all ALT-text you should start with the most important part and continue with less important parts. The basics of writing ALT-text can be read in Alt-texts: The Ultimate Guide.

Practical example

Let’s look at an example where AI-services have done complicated things on an ad with a lot of text in it.

AI suggestion:

Original in Swedish:
ALT=”ICAKaviar_Mildrökt_VälbalanseradRökigFastGod_TestAlltOmMat_20241014_DisplayAnnons_GAM360”

Translated to English:
ALT=”ICAKaviar_Mildrökt_WellbalanceSmokeyFirmTasty_TestAlltOmMat_20241014_DisplayAd_GAM360”

Underscore and capitalized words makes the ad unnecessary verbose and hard to read. Not all contents is added and the AI function cannot know the context and what is important.

Better example:

Original in Swedish:
ALT=”Annons från ICA för ICA Kaviar mildrökt. Utsedd till bäst i test enligt Allt om Mat 14 oktober 2024: Välbalanserade smaker med tydlig rökighet. Bra lagom fast konsistens. God eftersmak. Gå till ICA.se för att se produkten.”

Translated to English:
ALT=”Advertisement from ICA for ICA Kaviar mildrökt. Named best in test according to Allt om Mat 14 October 2024: Well-balanced flavours with a distinct smokiness. Good, firm consistency. Delicious aftertaste. Go to ICA.se to see product.”

End with the action, “Go to Ica.se to see product”. It might be too verbose starting with “Advertisment” so test it with users on your platform.

Depending on context, use clarifying wording that it’s an ad. Put all the text in the ALT-text.

Video ads

Start with making sure the script for the video production includes verbal descriptions of such things as names or texts on display in the video and important visuals. This decreases the need of alternate video with audio description tracks. Always include captioning since most people view video content on social media without sound. They can be on a bus without headphones or putting kids to bed and rather not wake them up. So if you miss captions in the content you miss the chance to sell to a lot of people. Some platforms do not allow captions with files ( such as .srt or .vtt formats), embed the caption in the video in these cases since it is better than no caption at all.

For audio, people can listen to video content but move focus when the ads arrive. If you miss the visual description in the audio track you’re missing a lot of users. Personally I am in the habit of multi-tasking and focusing on something else. So if you don’t even verbally tell me the company name or pitch you pay for views without value.

Other parts of importance:

Put text on solid backgrounds with good contrast.
The video and audio should be easy to follow, so don’t go too fast.
Make sure captions come synchronized and at least one line at a time.
Avoid very high sound in the beginning and keep volume at the same level.
Autoplaying sticky videos should be avoided.
Make sure not to have ARIA-LIVE reading out updates such as the number of seconds to the next video. It interrupts the user.

Conclusion

Ads suck today, either the advertisement platforms do not support what is needed for accessibility or the publisher platform has restrictions. Let us increase the demands when choosing and procuring a platform. Everyone should be able to read ads if they want to.

Want our help with making your ads and services better?

We’ve guided many organisations through this process before and can make it a whole lot easier for you too. Check out our accessibility consulting services or just drop us a message at [email protected] – we’re happy to help!

Accessible iOS design: how Forza Football included blind users

Diogo Melo — Tue, 04 Nov 2025 09:50:31 +0000

In my early teens, when my sight was slowly entering the low-vision territory, I loved football (soccer, if you’re American). These days, despite being blind, I still follow scores and a few leagues. My favorite iOS app for keeping up with football is Forza Football, thanks to its outstanding support for VoiceOver, Apple’s built-in screen reader for blind and low-vision users.

An unexpected accessibility champion

If you haven’t seen it, Forza Football doesn’t just show match scores and league tables — it also presents lineups in a clean view that’s fully accessible to VoiceOver users.

In this video you can hear VoiceOver navigating Forza’s lineup view — first Real Madrid’s starting lineup from goalkeeper to forward, then Barcelona’s, from goalkeeper to forward in reverse vertical order.

Team lineups are one of the most visual parts of any football app, but Forza has made them incredibly accessible to VoiceOver users like me. It’s so well done that I, as an iOS engineer, just had to replicate their navigation logic to understand how they did it!

How VoiceOver Reads a Football Pitch

As you may know, in left-to-right languages, VoiceOver typically navigates from bottom to top, and from left to right. In football commentary, lineups are usually described from defense to attack (goalkeeper to forwards) and from right to left.

Forza represents the pitch vertically — one goal at the top and one at the bottom. Since lineups show pre-match positions, the topmost player represents the home team goalkeeper, and the bottommost player is the away team goalkeeper, with both teams’ forwards being on either side of the center of the pitch.

For the home team, VoiceOver’s default navigation naturally follows football’s logic: it reads the goalkeeper first, then moves across defenders, midfielders, and forwards — from left to right on screen (which is right to left from the team’s perspective).

However, for the away team, things get trickier. The goalkeeper is at the bottom and the forwards at the top. VoiceOver, by default, reads in the opposite order to what a football fan would expect — forwards first, goalkeeper last. A user could adapt by finding the away goalkeeper and then swipe left, but that would be poor usability. Thankfully, Forza’s developers went a step further.

In this video, you can hear VoiceOver navigating my app’s initial lineup page — reading the home team correctly, but the away team from forwards to goalkeeper.

The Trick: Accessibility Priorities

iOS provides a property called accessibilitySortPriority. This accepts a numeric value — the higher the priority, the earlier VoiceOver reads that element during normal swipe navigation. By default, each view has a priority of 0 (zero). It doesn’t affect where items appear on screen (exploring by touch still works), but it changes the logical order in which VoiceOver moves through the elements.

I don’t know exactly how Forza implemented its lineup logic, but here’s how I replicated it.

My implementation starts with an array of players ordered “footballistically” (goalkeeper to forward, right to left);
This array is divided into subarrays, one per sector: goalkeeper, defenders, midfielders, etc;
In SwiftUI, I render each sector vertically and each player horizontally within it — left to right.

That works perfectly for the home team — once each player’s position is added to their accessibility label, VoiceOver reads the lineup exactly as it should.

But for the away team, since SwiftUI can’t reverse the view creation order, I invert the formation (for example, 4-5-1 becomes 1-5-4) before creating the sector arrays. The result is a correct visual layout — but VoiceOver now reads from forwards to goalkeeper. To fix that, I assign an increasing priority value to each player while iterating in reverse order. The goalkeeper ends up with the highest priority, ensuring VoiceOver reads from goalkeeper to forwards, just as football fans would expect.

// Setting the reversed priorities

func playersByPosition() -> [[PlayerPrioritized]] {
  var players = awayLineup.reversed() // from forward to goalkeeper
  var sectors = [[PlayerPrioritized]]()
  var priority = viewSortingPriority

  for (i, sector) in formation.reversed().enumerated() {
    // creating inner array per formation sector
    sectors.append([PlayerPrioritized]())
    for _ in 0..

Since this property affects the entire view, I also adjusted priorities for the home team and bench sections. To keep things simple, I used a small increment value (0.08) for each away player’s priority.
In this video, you can hear VoiceOver navigating my app’s fixed lineup page, finishing the home team lineup, then reading the away team from bottom to top — goalkeeper to forwards, as intended.

Handling Substitutes
Unlike Forza, I decided to display both teams’ substitutes side by side. Without custom priorities, VoiceOver would alternate between home and away substitutes, reading one from each side.
Here, you can hear VoiceOver reading substitutes alternately — one from the home team, then one from the away team.

By assigning a higher priority to the home team substitutes view, VoiceOver reads the entire home bench first, then the away bench. Within each group, it uses the default navigation order.
// LineUps View

var body: some View {
  ScrollView {
    HomeTeamView(home: homeTeam)
    .accessibilitySortPriority(3)

    AwayTeamView(away: awayTeam,
    sortingPriority: 2)

    Text("Substitutes")
    .accessibilitySortPriority(1)

    HStack {
      BenchView(team: homeTeam)
      .accessibilitySortPriority(0.9)

      BenchView(team: awayTeam)
      .accessibilitySortPriority(0.8)
     }
  }
}
In this last video, VoiceOver reads all home substitutes first, then the away substitutes, in the correct order.

Conclusion
If Forza can make something as visual and complex as football lineups both accessible and fun to explore, then surely simpler apps can do the same — with much less effort. Accessibility isn’t just a technical checkbox — it’s a chance to make more people feel included, informed, and part of the game.
I’m deeply passionate about both iOS development and accessibility. If your iOS team needs someone who truly cares about accessibility and great user experience, I am opened to new assignments. Drop me an email at [email protected].

How to handle accessibility reporting under the European Accessibility Act (EAA)

Hampus Sethfors — Tue, 30 Sep 2025 09:04:12 +0000

If your company is covered by the European Accessibility Act (EAA), you’ll need to handle two types of accessibility reporting: a publicly available accessibility statement and a report to the national monitoring authority whenever you discover an accessibility issue. Here’s a hands-on guide to both.

1. Accessibility statement – what you must publish

The Directive (EU) 2019/882 (Chapter 4) states:

Service providers shall… explain how the services meet the applicable accessibility requirements. The information shall be made available to the public in written and oral format, including in a manner which is accessible to persons with disabilities.

In practice, this means you need:

Written format: A public accessibility statement describing how your service meets accessibility requirements.
Oral format: Customer support staff trained to answer questions about accessibility from users.

Your accessibility statement should be easy to find, written in plain language and updated regularly.

Here are some examples of accessibility statements to draw inspiration from:

2. Reporting accessibility issues to authorities

The same chapter also states:

Where the service is not compliant with applicable accessibility requirements, service providers shall immediately inform the competent national authorities of the Member States in which the service is provided, to that effect, giving details, in particular, of the non-compliance and of any corrective measures taken.

In other words, if you find an accessibility problem, you need to report it promptly. Some countries have already created online forms for this. For example:

Netherland’s reporting form (acm.nl)

Sweden’s reporting form (pts.se)

Finland’s reporting form (saavutettavuusvaatimukset.fi)

Expect more countries to follow with similar systems.

What if you don’t report?

Technically, you can skip it — but it’s risky.

Authorities are expected to issue fines if reporting obligations aren’t met, even if you haven’t had a chance to fix the issues yet.

Proper documentation is likely to be treated as a compliance requirement on its own.

If you operate in multiple countries?

You’ll need to report separately to each country where you offer services. There’s no unified system (yet), so your internal process needs to adapt to each country’s reporting requirements.

While the forms are similar, they’re not identical. For instance:

Finland asks for a date for corrective actions
The Netherlands asks for an estimated number of affected consumers

A good practice is to create a central reporting template that can easily be customized for each country.

How leading companies handle reporting

Companies that are ahead of the curve have built accessibility reporting into their normal workflows. Here’s how they typically do it:

Tag accessibility issues in their issue tracking system (for instance using “accessibility” as a tag in Jira).
Every ~14 days, an accessibility lead or consultant reviews new issues and adds them to a pre-prepared reporting template.
The template includes estimated timelines per priority level – for instance “High – 4 weeks”, “Medium – 8 weeks” and so on.
They submit the report to each relevant national authority.

This approach keeps reporting manageable and ensures nothing slips through the cracks.

Final thoughts

Yes — this reporting requirement may feel a bit annoying at first. But there’s a silver lining: it nudges companies to do the things they should already be doing to make accessibility part of everyday work.

It pushes teams to:

Build regular testing, issue tracking and reporting processes
Increase internal know-how about accessibility
And most importantly, take accessibility seriously rather than treating it as an afterthought

In the long run, these steps don’t just help you comply with the law — they help you deliver better, more inclusive products and services.

Want our help with EAA reporting or accessibility strategy?

Beyond convenience: how smart tech can enable disabled lives

Hampus Sethfors — Thu, 07 Aug 2025 07:02:53 +0000

Smart tech lets me be a writer, a cat owner, and a caffeine addict on my own terms. That’s not just convenience – that’s access.

A few weeks ago, I had an interesting conversation with a friend. We talked about whether or not we identify with our tech. I’m sure I speak for all of us when stating that we at least have to admit to some level of attachment; I mean how many of us leave home without our phone in our pocket.

But I also dare saying that this goes deeper for those of us who actually can’t imagine life without a technical aid. And I don’t mean that in the sense of not being able to check your Instagram feed for a few hours, but like in not being able to move. Literally. Or in some cases breathe.

For my friend and I, our devices are pretty much the very foundation of who we are, and the lives that we can imagine ourselves living. I’m next to nothing without my Permobil, or – of course – my phone, which involves so much more than an Instagram feed.

I will get back to my phone, and my friend, in just a bit, but first I would like to offer a brief introduction to something called independent living.

What is independent living?

Independent living is a theory/philosophy that states everyone’s right to live an independent life. Independent should not be understood as completely self-sufficient, but as no more dependent than anyone else. We are all codependent in a society – most of us use public transport, visit health facilities, have attended school or university, and so on.

For some of us, this codependency on a societal level also involves other services, such as for example the right to personal assistance, or – of course – the right to specific technical aids.

I’m obviously all about these rights, and a society without said services would not only go straight against basic human rights, but also be a society where – instead of living in a community as an equal citizen, I would probably end up in some sort of institutional facility, which would not only take away my complete freedom, but also, to be honest, most probably would shorten my lifespan quite drastically.

Assistive tech: sometimes life-saving, always life-shaping

I’m lucky enough (should be a basic right though…!) to have personal assistance, so smart home appliances may not be what keeps me out of institutional ”care”, but the fact is that many of my disabled friends are not so fortunate. For them, assistive technology which is possible to buy on an open market can really make all the difference. It may be the reason they are able to have a job, be a parent, a friend, a student, or a cat owner. But for me, it sure is handy too!

Let me give you a few examples:

During that discussion with my friend on whether we identify ourselves with the tech we use, we also started talking about neat functionalities that make things so much easier for us in our everyday lives. Stuff we either already have, or stuff we would like in the future.

Coffee is a non-negotiable ritual for both of us. I use an app-connected capsule machine to get the perfect cup, whereas he uses a smart thermos that notifies him when the brew hits exactly 65 degrees. Yes, it’s that serious.

Most of our homes are of course fueled by smart technology. We got all the obvious stuff, such as smart lights, robotic vacuum cleaners, humidifiers, and air cleaners. My friend is a big fan of his smart home hub, to which everything is connected, but I’ve yet to get one myself since my voice is rarely recognized by tech. (Maybe that’s something to keep in mind for those of you who develop these products: not all voices are loud and clear.)

Fridges and washing machines as tools for freedom

Some things on my list of to-buys for the future are a smart mattress, smart fridge, and smart washing machine. A smart mattress is pretty self-telling; we all wish for a good night’s sleep I guess. But a smart refrigerator and washing machine would for me not just be nice and fancy, it would also mean being in full control of my own home and house chores.

My personal assistants are great and handpicked by me very carefully. Many of them have turned into close friends over the years. But relying on six to seven individuals when it comes to your own stuff can sometimes be a bit tricky. Especially when it involves things such as finding groceries in the back of your fridge. Or making sure that fancy T-shirt is indeed put on the handwash-program, rather than the regular 40 degrees.

It would be great to have a fridge that can tell me when I’ve run out of milk, or beer for that matter. And to be in full command of my own laundry.

As you can see, smart home appliances are not just about convenience. It’s about who gets to have agency in a home, and who gets to be safe, spontaneous, and in control. Because that’s what smart technology can do – extend the possibilities for autonomy.

Design with, not just for

Before I wrap this up, I would like to offer one piece of advice:  design with disabled people in the room. Not just as test users, but as co-creators, designers, developers, and decision-makers.

Because what’s good for us tends to be good for others too. Voice control helps busy parents. Smart lighting supports elderly folks. Hands-free cooking solutions are great for multitasking busy people.  Inclusion isn’t a niche feature – it’s just good design.

So maybe it’s not about reinventing the wheel – or the washing machine – but about asking who it’s spinning for.

And if you’re thinking “huh, what if she’s right – maybe we should have more disabled people involved in our design process!?”, then great news for you! All you have to do is drop us an email at [email protected]! Axess Lab is full of brilliant, opinionated, disabled stars, and we’d love to work with you!

Because inclusion isn’t just a niche feature – it’s just good design.

Accessibility after 28 June 2025: what’s next?

Veronica Cofre — Sat, 28 Jun 2025 06:47:38 +0000

The EAA has come into effect and many businesses and organisations have worked to meet the accessibility requirements set by the EU Accessibility Directive. For public websites and private organisations providing public services, this deadline means that their digital services must be accessible to all users, including people with disabilities.

So what happens after this milestone?

Will accessibility be “done” once the legal deadline has passed? The answer is a clear no. Accessibility is not a one-time fix or a checklist to be ticked off. It is a long-term strategy that must be an integral part of digital development going forward.

What are the next steps after 28 June?

Starting 28 June 2025, it is important to recognise that accessibility is not a one-off achievement. Rather, it is an ongoing process that requires continuous attention, monitoring and improvement. Websites and digital services are “living, evolving platforms” that change over time. They need to be regularly reviewed and updated to ensure they remain accessible to all users, especially given technological advances and changes in user behaviour.

Accessibility as a long-term strategy

Meeting the legal requirements is just the first step, accessibility is about something bigger. It is about creating a digital service that is usable and inclusive for as many people as possible – which makes it even more important to work on accessibility as a long-term strategy. By making accessibility a key pillar in your digital development, you will create a more sustainable and user-friendly service for everyone, not just those with specific needs.

Why accessibility specialists are needed for the long term

To ensure that your website or app remains accessible and usable in the long term, it is crucial to have accessibility specialists on your team.

They can help to:

Adapting solutions to new technologies and user interfaces.
Ensuring that digital services comply with current accessibility standards
Conduct user testing with people with different disabilities.
Train internal teams and create a culture of long-term accessibility.

This is just the beginning

As 28 June 2025 passes, it is not the end of the accessibility journey, it is the start of an ongoing commitment to improvement. By making accessibility and inclusion a natural part of your digital work, and by collaborating with accessibility specialists, you will build digital services that are not only relevant today but sustainable and futureproof for everyone.

Glassmorphism Meets Accessibility: Can Glass Be Inclusive?

Nicko Syropoulos — Wed, 11 Jun 2025 00:10:27 +0000

Tech giants such as Microsoft and Apple are integrating glassmorphism into their design languages, aiming for a refined, unique, modern and engaging user interface (UI). However, the appealing nature of frosted-glass effects raises questions about accessibility, especially for consumers with cognitive and visual impairments.

What is glassmorphism?

Combining the words “glass” and “skeuomorphism”, the latter derived from the Greek words “skeuos,” (tool or vessel), and “morphe,” (shape). Stated otherwise, glassmorphism is a design technique inspired by glass as a physical material.

Glassmorphism design trend has become rather popular on contemporary user interfaces, including Windows 11 and macOS Big Sur. These days, the trend is followed by Microsoft’s Fluent Design System and Apple via Liquid Glass intended for OS releases in 2026. Its futuristic yet tactile sensation comes from its elegant, frosted-glass form.

Glassmorphism appeals clearly since it creates a visual richness, lightness, and elegance. It defines spatial connections among UI components rather successfully without depending much on shadows or borders. For many designers, it presents a convincing way to improve the polish and elegance of digital products.

But this visual appeal begs a serious concern: How accessible are glassmorphic user interfaces?

For consumers with visual, cognitive, or motion-related disabilities, this style offers great challenges even if it is aesthetically pleasing. Transparency may reduce text contrast; blur effects may cause sensory pain; layered depth may distort information hierarchy. These issues run the risk of excluding a sizable portion of the user population, especially those who use assistive technology or perceive visual information differently.

Here we will look at the potential accessibility risks that glassmorphism poses and how we can eliminate them. Whether creating a bespoke design system, native OS UI, or a web application, you will find strong practical ideas to make sure the frosted glass effect does not unintentionally exclude users.

What makes glassmorphism visually appealing?

The goal of glassmorphism is to make digital interfaces look like frosted or translucent glass. By using depth, blur, transparency, and delicate shadows, it creates a multi-layered, nearly real digital environment that is both immaculate and sophisticated.

Glassmorphism is defined by several key elements:

Translucent layers: Usually with a gentle blur, elements show a portion of what is behind them. This creates the illusion of transparency and depth, similar to looking through frosted glass.
Effects of blur: Background blur is essential because it highlights the “glass” effect while softening what is behind translucent elements, maintaining readability.
Soft borders and highlights: Panels often have a bevelled, floating appearance that adds dimension when delicate borders and inner shadows are used.
Bright backgrounds: Glassmorphism works best when it is applied on top of dynamic images or bright gradients that highlight the transparency.
Minimalism: The effect works well with simple, minimalist designs, where the glass layers’ visual impact is enhanced by their simplicity.

When used properly, glassmorphism can give interfaces a modern, flowing, and engaging feel. It exudes a feeling of high-end, superior visual quality that is captivating and dynamic. Additionally, it enables designers to create a visual hierarchy without the need for distinct divisions, resulting in interfaces that are more elegant and complex.

Despite its obvious aesthetic appeal, its reliance on visual effects creates a delicate balance that is prone to breaking if accessibility is not incorporated from the beginning.

Accessibility concerns

As visually striking as glassmorphism can be, its core features (transparency, blur and layering) can introduce serious accessibility pitfalls. These issues are not just theoretical; they directly impact users with visual and cognitive impairments.

Let’s break down the most common concerns:

Low contrast

One of the main concerns with glassmorphic design is low contrast.

When text and icons are placed on semi-transparent backgrounds, especially over colourful images, the contrast ratios often fall short of WCAG 2.2 requirements. While larger text and user interface elements require a 3:1 contrast ratio, body text requires a 4.5:1 contrast ratio. As a result, reading the content is difficult for people who have age-related vision problems, colour blindness, or visual impairments.

The truth is that many users find the text hard, if not impossible, to understand, despite the fact that designers may find the aesthetic balance appealing.

Background interference

Glassmorphic layers allow for the visibility of background elements such as colours, shapes, or motion even when blur effects are present. This may result in distracting visual clutter that obstructs the content.

Additionally, dynamic backgrounds like videos, animated gradients, or scrolling elements are making this problem more noticeable, which makes it especially difficult for people who struggle with cognitive impairments or information processing and focus.

Motion & blur sensitivity

Animated effects like parallax and layered transitions are commonly used in glassmorphism, and they can make people with vestibular conditions feel lightheaded or queasy. Furthermore, the blurring effect can strain the eyes, particularly when used excessively or for prolonged periods of time.

Furthermore, these effects demand significant system resources and Graphics Processing Unit (GPU) power, which may impair performance on devices with lower power. This situation disproportionately affects users who have financial or other constraints.

Disrupted focus & information hierarchy

The distinctive softness of glassmorphism adds a sense of elegance, but if it is not applied with discipline and with careful planning, it can also create ambiguity. Establishing distinct visual hierarchies is made difficult by elements’ tendency to blend into backgrounds.

As a result, design elements might not be clear and evidently interactive, which could lead to users—especially those who use screen magnifiers or quickly scan for interactive regions—missing crucial controls.

Incompatibility with assistive technologies

Visual effects and semi-transparent layers do not always work well in high-contrast modes or by using screen readers. These elements may become obstacles to the user experience in the absence of semantic structure, appropriate labelling, and fallback designs.

Designing accessible glassmorphism

Glassmorphic effects can improve usability and aesthetics when applied thoughtfully and with empathy. The secret is to avoid making accessibility an afterthought and to design with inclusion in mind from the start. The objective is to tame glassmorphism, not to give it up.

The following useful tips will assist you in maintaining the elegance of glassmorphism while making sure your user interfaces are accessible and usable by all:

Maintain strong contrast

The most important rule: never compromise on contrast.

Ensure all text and essential UI elements meet or exceed WCAG 2.2 contrast minimums (4.5:1 for body text, 3:1 for larger or bold UI components).
Use background overlays or semi-opaque fills behind text to separate it from underlying content.
Do not rely solely on blur. It softens the UI, but it does not guarantee sufficient separation or legibility.

Offer reduced transparency options

Respect user system preferences with the prefers-reduced-transparency media query or platform-specific accessibility APIs.

In most OS, users can reduce transparency in the platform. Your UI needs to comply to those user preferences.

Control motion & blur intensity

Use blur and animation sparingly and test across a range of user needs. It is suggested to:

Avoid excessive blur strength (especially backdrop-filter: blur(20px) and higher).
Reduce animation duration and complexity for interface transitions.
Respect the prefers-reduced-motion media query and provide fallbacks.

Reinforce information hierarchy

Do not let form override function. Use visual cues that reinforce content structure. It is suggested to:

Combine transparency with subtle borders or shadows to define layers.
Use clear spacing, padding, and alignment to indicate hierarchy.
Avoid placing critical information on heavily textured or animated backgrounds.

Test with real users and assistive technologies

What looks elegant in your designs might break down in practice. Ensure your designs are robust by testing them under real-world conditions:

Use screen readers like VoiceOver, TalkBack or NVDA to evaluate accessibility.
Test contrast and legibility across various levels of visual acuity and colour vision.
Simulate device performance on low-power or older hardware.
Consider scenarios like high-contrast mode, zoom/magnification, or dark mode

Conclusion

Once thought to be a passing trend, glassmorphism is now a fundamental component of modern UI design. Large tech companies use it because of its intricate and multilayered design. But this strategy requires careful thought. Visually appealing interfaces may unintentionally impact user experience and exclude users if motion, transparency, and blur effects are used without giving accessibility top priority.

Thankfully, inclusivity and artistic excellence can coexist. We can produce experiences that are both contemporary and accessible by putting careful design principles into practice, such as maintaining contrast, offering choices for less transparency, and taking user motion preferences into account.

As developers and designers, we have a duty that goes beyond aesthetics. In addition to being aesthetically pleasing, a truly excellent interface is also useful for all users.

The future of ICT

Viveka Sjölund — Thu, 15 May 2025 06:17:27 +0000

I see… ICT”, says Daniel while reading the tea leaves in his steaming cup. Let’s see what important message does the future bring?

The overlooked side of modern convenience

When we talk about accessibility in the future, we’re really talking about the everyday technology we already use: ATMs, ticket machines, self-checkouts. Things that work fine for many people – but can be barriers for others.

Have you thought about how often you use a touchscreen in daily life? When you pay in a store, leave a tip at a restaurant, take the elevator, or check in at the doctor’s office? Touchscreens are everywhere – but not everyone can use them.

Have you ever tried getting around a shop with a stroller? Then you might know how narrow some spaces can be. For someone in a wheelchair, that’s not just an occasional problem – it’s something they deal with every day.

The law helps – but it’s not enough

The new European Accessibility Act brings stricter rules to make products and services easier for more people to use. This includes things like self-service kiosks and payment machines – which often aren’t built for people with different needs.
But following the law isn’t enough on its own. Accessibility isn’t just about rules, it’s about understanding people, and designing things that work for everyone from the beginning.

Making accessibility real

We believe these challenges can be solved – and often it’s not that complicated. The key is to involve real users early in the process. When people with disabilities help test and give feedback, the final result works better – for everyone.

In the film, we see Nathalie shopping at a store that has added a second screen at a lower height. That small change makes it easy for her to pay from her wheelchair.

We also see Claudio picking up a parcel from a PostNord locker. Instead of having to use a touchscreen, he can open the box through an app that works with his screen reader.

These are examples of good solutions that makes a big difference when you think about inclusion from the start.

The future is accessible

We don’t need fancy new technology to make progress. We can start with what we already have. When we include people with different needs in the design and testing of services, we discover things we might not see otherwise.
Accessibility isn’t extra – it’s a basic part of a fair society. And it starts by asking the right questions and really listening to the answers.

Accessibility statement for the EAA

Erik Gustafsson Spagnoli — Fri, 28 Mar 2025 14:43:02 +0000

It’s been annoying me for a very long time that accessibility statements are so damn bureaucratic. People take the templates provided which are made for legal compliance – and they suck. Why not make the statements a place for people to receive help and get easy to understand information on the things that might not work so well for them?

TL; DR;

The accessibility statement template is based on the demands from the public sector EU Web Accessibility Directive (WAD) and the focus is on assisting the user, rather than merely outlining legal requirements and shortcomings or failures.

Even if you cannot do all the recommended things now – add it to your long term plan. Where do we want to be in 5 years?

Psst… we also created a template!

Why use an accessibility statement?

It is a central place for documentation. The European Accessibility Act (EAA) says you need to document how you meet the directive. European Web Accessibility Directive (WAD) goes with the accessibility statement and many other countries have the same format.

It’s not for everyone to read

Some of you might argue, well the statement is not for everyone. It is just for monitoring agencies, or as they in the EAA refer to market surveillance, and procurement processes.
Then why would it have a prominent position in the structure and include ways for the USER to report and receive help?
You most often find it in the footer and for the European Web Accessibility Directive (WAD) it has demands for the public to be able to report to your company and the market surveillance.

Transparency with public documentation

With transparency you meet the requirements that the public can access the information.

Why not also make it easy for your organisation? Everyone can reach a webpage that is open to the public and not everyone looking to buy something reaches out to you. Benefits of transparency:

No need for the management to have access to ticketing systems such as Jira.
No administrative costs for giving the public access.
Easy to access for everyone investigating your compliance before engaging.
A way to get feedback from the public if they see it is worth it.
Everyone in the organisation knows how accessible the product is.

It forces a way of working, you need to know and have processes to be able to know who is responsible. The ticketing system you use probably needs a special accessibility-statement flag. Customer services need to be properly trained on picking up errors from customers.

What does the law state?

Of course we need to do what the applicable law says as a starting point. But remember, the law is not the important part here. The intention of the law is to make products and services accessible. Laws and standards is just the bare minimum and you can do far better for the users.

European accessibility act (EAA)

CHAPTER IV Obligations of service providers Article 13 Obligations of service providers

2. Service providers shall prepare the necessary information in accordance with Annex V and shall explain how the services meet the applicable accessibility requirements.

The information shall be made available to the public in written and oral format, including in a manner which is accessible to persons with disabilities.

Service providers shall keep that information for as long as the service is in operation.

Finland’s market surveillance Saavutettavuusvaatimukset require accessibility statements.

European Web Accessibility Directive (WAD)

Preamble to the European Web accessibility directive, Recital 44

(44) An accessibility statement should be provided by public sector bodies on the compliance of their websites and mobile applications with the accessibility requirements laid down by this Directive. That accessibility statement should include, where appropriate, the accessible alternatives provided for.

Other laws and regulations

There’s local legislation such as:

Americans with Disabilities Act (ADA).
Section 508.
Accessibility for Ontarians with Disabilities Act (AODA).
National anti-discrimination laws.

If you work actively with the suggested format of this guide, you will most likely cover the requirements in each country.

You do need to check if there are formal parts that need to be added, such as the program manager for section 508.

Important parts to consider

There are some things you should address in the statement. Many of them are for the user.

Use HTML

Avoid complex documents whenever possible. They are harder to keep updated and there’s a bigger risk that different versions circulate – compared to using HTML-pages which are accessible by default.

Write in easy to read language

The language should be easy to read for everyone. I have yet to see people say “Oh this was easy to understand – this sucks!”. Even people at the government agencies would appreciate less legal jargon. The link in the footer should probably include the name of the company such as “Accessibility at Axess Lab” instead of “Accessibility statement”.

Make it easy for the user to give feedback

Giving the possibility to give feedback in different ways makes it easier for you to get valuable information about what does not work.

Think about anonymous feedback through forms, voice messages or calls, email and a chat service.
Make sure that your staff that handles complaints through the selected channel have knowledge.
Remember the pages you provide, the forms and third party providers of chat of course have to be accessible.

Show that you care and fix feedback

In general people just move on if something does not work for them. By being transparent with what you have fixed after the user has reported issues people are more likely to return and report more issues.

Archive regularly

To be able to keep the documentation relevant and fresh. Make sure you regularly save a copy – so that you can prove to the market surveillance, if needed, that you have done your homework.

Add all channels

Customers don’t care where they interact with your company and which are exempt from legal demands. For them, you’re a brand and they use whatever channel they come across. Treat your customers with equal respect wherever they choose to meet you at.

Add physical accessibility

Companies are more often both digital and physical. There are locations to visit such as stores and resorts. There’s the fusion of digital interfaces in physical self service terminals such as ticketing machines and payment terminals. Regardless of the legal requirements, people want to know if the services you offer are accessible for them.

You can also include cognitive aspects as the excellent Swedish accessibility guide from Stendahls bil has done. They offer a range of descriptions such as scents and sounds, how their dealership can be accessed with service animals and for people with varying neurodiversity.
“Good to know” things can be for example:

When is it noisy in the restaurant?
When is it quieter to check in?
Can I get around everywhere with a wheelchair?

Another good example from Swedish train operator SJ with information on travelling with a disability.

List of issues

Describe the issues and to make it easy, follow the format of the ticketing system you use. This part of the statement could be collapsed in an accordion. Since most users don’t really care about the individual issues. So why keep them on the page then, you might ask? Well, let’s circle back to having a central and transparent place to put all documentation – it makes sense.

Disproportionate burden

For the public sector the government agencies have been very strict in what they accept as disproportionate burden. In Sweden, Digg has stated that if a company risks bankruptcy by implementing accessibility fixes immediately, it is still required to make the fixes but may plan to do so over a longer period.
Criteria for assessment of disproportionate burden

The directive says that an assessment needs to be made and documented to be able to claim disproportionate burden.
Sometimes you do have a lot of things to fix at the same time or it could be that fixes lead to a totally different product.
Market surveillance in the country you’re active in decides if you can claim disproportionate burden or not.
If you do claim it for economic reasons, you still need a plan on how to fix the issues over time.
You need to make a documented economic assessment and send it to the market surveillance.
More information about disproportionate burden can be read in the EAA.

We have a template for the European Accessibility Act (EAA)

Together with the W3C Nordic accessibility community group we have created a simple and diverse template. And we’re giving it away for free.

Easy to use.
Made for people.
You can use the blocks you find fits your needs.
Enables help when something is broken.

Accessibility statement template on W3C Nordic accessibility community group Github.

Need more than a template? Enlisting the help of our awesome accessibility consultants gives you ongoing support with accessibility issues, user testing, and making sure your documentation reflects real progress.

Easily check for web accessibility problems in ten minutes or less

Thea Walther — Fri, 13 Dec 2024 08:09:43 +0000

Does making your website accessible feel a bit intimidating or overwhelming? Are you unsure where to begin? Don’t worry, here are a few quick steps to look for low-hanging fruit, with no technical expertise required!

Testing on a computer

Note: If you’re on a Mac, you may need to change some settings for the Tab key to work as described here. Adrian Roselli has helpfully compiled a few links to guides for this.

Use the Tab key to cycle through the page you want to look at.

Ask yourself these questions:

Is there a visible focus indicator at all? If there is, can you spot it easily or is it too subtle?
Does the focus move in the order you’d expect? This should typically be the same as the order you’d naturally read the page in, i.e. top down, left to right.
Can you actually reach every button, link and interactive element you see?
Can you activate the focused elements with the Enter or Space key?

Point at the various interactive elements with your mouse. Can you see any visual indication that they’re interactive when you do?

Zooming in

Try zooming in on the website by holding down Ctrl (Windows) or Command (Mac), then pressing the + key. Zoom until the indicator says you’re at 400%.

Can you still read and navigate on the website? Is it a reasonably pleasant experience?

Testing on a phone

Target size

Have a quick look at the interactive elements on the page, like buttons. Do they feel large enough to comfortably press with your fingers, even if you’re on a shaking bus or similar?

Pinch to zoom

Touch the screen with two fingers, then move them apart to zoom in. Does this work, or is nothing happening? If nothing happens, is there a good reason to prevent users from zooming in? Hint: There usually isn’t.

Landscape mode

First, make sure your phone’s “auto-rotate” setting is enabled. Then flip your phone sideways and look around the site in this mode. Does it automatically adjust to your phone’s orientation and otherwise work properly? Can you see every part of it, or are there things “hidden” outside the screen?

In the image above everything is visible and usable. That’s what we want! Sure, there is some wasted space and some may not like the look and feel of it in landscape mode – but that’s fine!

And… that’s it for now! By spending ten minutes or so going through these steps, you can catch a whole lot of accessibility issues. Of course, this won’t catch everything (or even most things), but it’s a great way to look for low-hanging fruit without much effort.

What’s next?

If going through these quick tests made you want to fix and improve things, here are a few great options for further steps!

Solving known issues

A natural next step after finding accessibility issues could be to fix them. Maybe you and/or the people you work with can do that, or maybe you could use some help. We’d be more than happy to help with this!

Conducting a full accessibility review

As you already know, these quick tests won’t find all the accessibility issues on a website. One of the services we provide is accessibility audits, where we’ll thoroughly review your website and compose a clear, helpful list of the problems we find along with detailed descriptions, suggested solutions, estimates of each problem’s impact and the effort needed to solve it, and references to established accessibility guidelines such as WCAG. You could even combine this with the previous point, letting us help fix the issues we detect during the audit!

Educating and up-skilling your staff

If you really want to get a handle on accessibility, it needs to become an integral part of your workflow. We offer workshops, seminars and courses that can help your staff improve their expertise in accessibility, enabling you to identify and address issues autonomously as well as reducing the amount of accessibility issues that make it onto your websites and other services to begin with.

If you’d like our help with any of this, have a look at our services!

European Accessibility Act (EAA) – What you need to know

Joel Holmberg — Mon, 01 Jul 2024 12:46:36 +0000

June 28, 2025. That’s the deadline for all banking services and e-commerce in the EU to be fully compliant with the European Accessibility Act (EAA). Here’s a straight-to-the-point summary of what you need to know!

Background

The EU combines two of their general goals in the European Accessibility Act. First, the EU wants people with disabilities to be included in, and get full access to society. Second, the EU want companies competing on the inner european market to have clear and fair rules, equal for all participants, no matter which European country you are based in. That’s the background for creating the new EAA regulation.

In a nutshell, the purpose of the EAA is for products and services to be accessible for consumers:

Without vision
With limited vision
Without perception of color
Without hearing
With limited hearing
Without vocal capability
With limited manipulation or strength
With limited reach
With risk of photosensitive seizures
With limited cognition

Who is affected?

Six types of consumer services are affected, as well as eight types of consumer products.

Any company selling or providing these are affected. For services, all ICT (information and communication technologies) used by consumers to access the services are covered – for example self-checkout kiosks used to pay for groceries in a physical store.

It’s important to note that it is the service or product that is targeted, not the company as a whole. That means, if an e-commerce website has a page for consumers, and another page for business-to-business then only the page for consumers needs to comply with the new regulation.

Affected consumer services

Electronic communication services like network subscriptions, phone calls, e-mail, SMS, chat, video conferences.
Media services like streaming services or program guides in TV-boxes.
Transport services like websites, apps or electronic ticket kiosks needed to access the transportation service.
Banking services, including websites, apps and queueing systems or kiosks in a physical bank office.
E-books
E-commerce including any website or app where a purchase can be made of a product or service.

Affected consumer products

Computers, including laptops, smartphones, tablets etc.
Payment terminals including payment card readers.
Kiosks for cash withdrawal
Self service terminals, if the terminal is used for ticket sales, check-in etcetera for services covered in “Affected consumer services”.
Interactive information terminals, but only if they are used for the services listed above, and are interactive. For example interactive screens used to present time tables at the train station are affected, but if the screen just presents the departure times (not interactive) then it’s not covered.
Products used to access communication services, like routers, modems and smartphones.
Products used to access media services, like digital TV boxes or smart-TVs.
Reading tablets used to read e-books.

What are the penalties?

The biggest risk is that you might no longer be allowed to sell your services in the EU. Loosing the EU as a market is likely the biggest consequence for most companies.

However, the more likely consequence for most is sanctions – the size depending on each contry. In many countries sanctions will be in the range $1000 – $1 000 000, and with multiple or recurring compliance issues there can be many sanctions.

In some countries law makers have added prison sentences of up to 18 months to the penalty scale. Others, like Latvia, have added “confiscation or destruction of property” as a potential consequence.

What do you need to do?

You need to conform with relevant standards and guidelines. There are also some documentation requirements. Exact requirements and interpretations can differ between each contry, but the EAA sets a very clear baseline for all countries in the EU. This regulation is intended to be be consistently implemented – so the variance will likely be very small.

Design for all

Accessibility is about making something that works for people with diverse abilities. So the standards to follow are all focused on making sure your users with or without disabilities can use your products and services. The best way to accomplish this is probably to work together with users with disabilities and making sure in usability tests that they can actually use your stuff! If actual people with disabilities have a good user experience – you will comply with most formal legislation on the fly.

However, the Directive that’s the foundation for the EAA, points towards standards that specify formal, testable criteria for compliance.

EN 301 549

The EU standard EN 301 549 covers the formal requirements for products and services. The section about requirements for web and apps is mainly a copy-paste of the Web Content Accessibility Guidelines.

There are a few WCAG criteria that don’t apply in EU – for instance you don’t have to caption live streamed videos even though it’s a WCAG requirement – and some that go beyond WCAG – like having to support dark mode. But apart from a few exceptions like those, it’s WCAG that applies.

WCAG – for web content

The Web Content Accessibility Guidelines list 50+ criteria for accessible web content. It’s divided into 3 levels; A, AA and AAA. The law requires conforming with level A and AA requirements only.

As an example, the first WCAG criteria 1.1.1 states that all non-text content, like images, must have a text-alternative for users who cannot see the image. If your website has only text content – you already pass this criteria. Congratulations!

WCAG is versioned, and as of writing this article, the latest version is 2.2. Some legal documents still point towards version 2.1, but you may as well start working with version 2.2, as conforming with version 2.2 also means you conform with version 2.1.

Apps

For iOS and Android apps, you need to conform with relevant parts of the WCAG. Out of the current 56 criteria in WCAG 2.2, only 44 apply to apps. There are a few more general requirements for ICT in the EN 301 549 that also apply to apps (read chapters 4 and 5). But as a rule of thumb – if you make sure you meet the success criteria in the WCAG (interpreted in an “app” way), you will come a long way!

The WCAG beginners’ guide on appt.org is a good place to start understanding how to conform with WCAG in iOS and Android apps.

Documents

Documents (commonly PDFs), that are a part of the product or services covered by the EAA, also have to be accessible if they are intended to be read by your users as a part of the service. This includes “terms and conditions” and similar documents, but also interactive form documents like loan application forms in PDF.

Any documentation of the product or service needs to be available in an accessible digital format like an accessible webpage (HTML), or an accessible PDF.

Hardware, payment terminals, kiosks and physical devices

The requirements for hardware differ depending on the type of service the hardware provides. On top of that – there are often other laws governing physical products that overlap the EAA or add to the complexity.

Check out our indepth article on that theme:

European accessibility act (EAA): kiosks, touch screens and physical devices

Summary

Making sure your software and hardware works well for users with disabilities is important, and now also legally required in the EU. You may want to get expert help evaluating if your current websites, apps and devices are compliant! Luckily there are companies like ours that can help you with that.

The standards are great tools, but remember – the purpose of these laws are to make sure your stuff works well for everyone. A fully compliant piece of ICT can still technically be completely useless, so try to involve users in your efforts to test your product or service – preferably users with disabilities!

Get some help along the way

If you need help sorting out what your organization should do, in what order, and how to do it – reach out to us here at Axess Lab. We are specialised in digital accessibility, and stand ready to help your team! Here are a few of the things we can help you with when you are ready to start the journey:

Accessibility review

Usability testing with people with disabilities

Accessibility statement – let us create it for you!

Accessibility training, workshops and talks

Or just drop us a message on [email protected] and we’ll take it from there.

European Accessibility Act (EAA) – Kiosks, touch screens and physical devices

Nathalie Pentler — Mon, 01 Jul 2024 12:34:47 +0000

In June 2025, the European Accessibility Act will be enforced. Most of the buzz is around websites and apps, but many physical devices will also be covered by the new legislation. Let’s look at that more closely and create some buzz around the accessibility of touch screens and other physical devices!

Issues Nathalie face as a wheelchair user

I’ll begin with some personal experiences. I use a wheelchair, and face issues with reaching devices all the time. Here are some photos I’ve taken when grocery shopping!

By the way, if you’re just looking for what the actual law says, skip ahead to What are the actual requirements?

This is a classic struggle: a touch screen for choosing what grocery I have on the scale.

Way too high, and even if it would have been lower, there’s a table blocking my wheelchair from getting close.

Another common issue: payment terminals on gas stations. Here is a newly built charging pole for an electric vehicle. It’s obvious that they haven’t considered accessibility here at all. Can you spot the issues?

Well, the raised ground and two metal poles prevent me and other wheelchair users from getting to the actual charging post at all. And even if we learned how to magically hover above the ground and get there, the interactive touch screen is way too high to reach.

This has been a problem for a long time with regular petrol pumps, but in those cases you often have the alternative to ask the people at the cashier to activate the pump and then pay inside the store. This is often not an option with electric car chargers, making it a more pressing problem.

Sidenote: many cars are adapted so that people without use of their legs, or with other motor impairments, can drive them independently. Check out this video where Kathryn Granger showcases how she drives and gets her wheelchair in the car.

Moving on: a lot of new “smart delivery boxes”, like the one below, cause problems for me. The first challenge is reaching the touch screen. Then the lottery starts. Is my package in one of the around 50% boxes I can reach? Or is it in one of the top boxes I can’t reach?

Self-service check-in terminals at airports are often also difficult for me. Feels like a lottery every time! Will I be able to use them or have to look around for help.

So a lot of the issues that me and other consumers with motor impairments face are about reaching stuff.

Another group that is heavily affected by inaccessible touch screens and other physical devices are blind folks.

Here, most major exclusion comes down to the fact that you’re required to use a touch screen that does not have screen reader support. For instance, you often need to input numbers on the smart post box touch screen display.

“Oh, but supporting screen readers must cost a ton of money to support”, you may think. Well, there are often creative solutions if you have accessibility in mind from the start of projects. Let’s look at a few..

Nice solutions are already out there

Here in Sweden, our state funded postal service “Postnord” also has smart post boxes. But opening those boxes is achieved by using an app on your own device instead of a touch screen.

The app supports the users own screen reader, and voilá: no problem opening the boxes!

There’s still the issue of reaching the box for me and others with motor impairments, and I heard from a blind colleague that he often struggles with finding which door has opened. He listens for the click of the door and starts waving his arms close to the device to find it. A bit of subtle sound design would do the trick!

The Postnord app shows that good solutions are already out there. Let’s look at a few more positive examples!

In Norway, they let you choose if you only can reach the middle boxes (“Luker på midten”), or all of them (“Alle luker”), when choosing delivery methods. Very nice!

When activating your tickets in public transportation in Stockholm, here a ferry, the devices are often available at different heights. Great for me! Great for kids who want to blip their parent’s ticket! Great for anyone!

Another example of terminals at different heights.

On a “Max Burgers” restaurant, I can press a button at the bottom corner of the touch screen to have the top part of the interface move down to a more reachable height. Creative thinking! Although I still found it hard to reach the top most buttons when the interface had been moved down, so they could probably do this a bit better.

Look closely at this ATM:

Notice the headphone jack? It makes it possible for the user to get spoken instructions, and not have sensitive bank details be shouted out through a speaker.

Finally, a few years back we made a short article including a video of an accessible queue system that has a built in screen reader.

So there are great solutions out there already, to get inspired by!

What does the EU law actually require?

I’ll now summarize some key points in the European Accessibility Act relating to the topic of kiosks, touchscreens and similar devices. This is mainly taken from the following sections of the actual Directive 2019/882:

Chapter 1, Article 2 for which products are covered
Annex 1 for the actual accessibility requirements
Annex 2 for examples and possible solutions to fulfill the requirements

Feel free to open the Directive and dig in yourself, but below are some highlights I’ve extracted. We’ve also got a general article on the European Accessibility Act that you can check out.

What products are covered

Some parts straight from the directive:

The following self-service terminals:

payment terminals

the following self-service terminals dedicated to the provision of services covered by this Directive:

automated teller machines (ATM:s)

ticketing machines

check-in machines

interactive self-service terminals providing information, excluding terminals installed as integrated parts of vehicles, aircrafts, ships or rolling stock

So in a nutshell: self-service payment terminals and basically any self-service terminal related to e-commerce or banking (services covered by the directive).

When do we need to comply?

The European Accessibility Act covers products that are “placed on the market after 28 June 2025”. So you will not have to trash all your current products! You’re allowed to keep them for another 20 years, or until they need to be replaced. So focus on the new products you’re shipping, not the ones already out there.

Here’s the exact phrasing in the Directive:

Given the cost and long life-cycle of self-service terminals, it is appropriate to provide that, when such terminals are used in the provision of services, they may continue to be used until the end of their economic life, as long as they are not replaced during that period, but not for longer than 20 years.

What are the actual requirements?

In a nutshell, the devices covered needs to be accessible by for consumers:

Without vision
With limited vision
Without perception of color
Without hearing
With limited hearing
Without vocal capability
With limited manipulation or strength
With limited reach
With risk of photosensitive seizures
With limited cognition

The specific requirements are laid out in Annex 1 of the Directive. Here are some highlights I’ve extracted.

the product shall avoid modes of operation requiring extensive reach and great strength

What’s extensive reach and great strength? Well that’s detailed in the EN 301 549 standard, chapter 8 “Hardware”, which includes requirements like having interactive elements at a height between 38-122 cm:

when the product uses visual elements it shall provide for flexible magnification, brightness and contrast

So you should aim to have zooming features and similar controls in the interfaces. If you don’t, you have to instead meet quite rigid requirement of text sizes. For instance, if the normal viewing distance is 50 cm from the screen, the minimum allowed character height is 6.1 mm. Check out the specifics of text sizes in chapter 5.1.4 “Functionality closed to text enlargement”.

when the product provides for communication, including interpersonal communication, operation, information, control and orientation, it shall do so via more than one sensory channel.

Fancy language..! But in plain words: you can’t only show something visually on the screen, there needs to be another “sensory channel”, for instance sound, to give that information. Basically: support a screen reader or similar.

when the product uses colour to convey information, indicate an action, require a response or identify elements, it shall provide an alternative to colour

So users with color vision deficiencies also can understand the information you’re providing.

Here are some requirements that are specific to self-service terminals:

shall give the possibility to extend the time given

shall allow for the use of personal headsets

when the product uses audio or audible signals, it shall be compatible with assistive devices and technologies available at Union level, including hearing technologies such as hearing aids, telecoils, cochlear implants and assistive listening devices

So those were some of the general requirements laid out in the Directive, with a bit of details from the EN 301 549 standard. There are many more, and a fair bit to wrap your head around. Most touch screens, kiosks and other physical devices are far from compliant, so there’s likely a big effort needed to make this sector more accessible in the years ahead.

How do we prove compliance?

As long as your products fulfill the requirements in the EN 301 549 you don’t have to do anything!

However, if you do not fulfill all the above requirements in your product then you have to inform the appropriate market surveillance authorities in the EU country where the product is sold or distributed.

When?

As soon as possible, some countries mention within 14 days of identifying the issue.

How?

This differs between countries, and at the time of writing this, no list is available of the process for each EU country.

In Sweden, an online form will be made available by the Post and telecommunication board (PTS). As soon as we have a list of each country’s process, we will link to it here!

What to report?

This may differ between countries, but be prepared to report things like:

Product name and type/model, brand, and ID number (e.g., GTIN/EAN code, article number, or other identifier).
Type of issue: Brief description of what doesn’t meet requirements (e.g., requires too much reach/strength, or lacks alternatives to biometric identification).
When the issue was discovered: Date or time period when the issue was first noticed.
Who is affected: If possible, specify if a particular group is impacted (e.g., certain user segment or users with certain disabilities).
Actions taken or planned: What has been done so far to address the issue, and what is planned.
Contact person: Name, email, and/or phone number of someone the authority can contact if needed.

Want a helping hand?

We can help you audit and user test your payment terminals, self-service terminals and other machines. You will get a detailed report document which will check the requirements against the standards in EAA. Regardless of if the machine is covered by the law we can help you make it better for all users.

Also: if you want help from accessibility experts like me to analyze and recommend solutions for your specific product or service – you’ll find the contact details in the footer below.

Thanks for putting in the effort to make these devices more accessible for me and many others with disabilities!

Accessible QR Codes – The Ultimate Guide

Daniel Göransson — Thu, 16 May 2024 06:14:02 +0000

You may think QR codes are great for securing your login, or letting users read more online about a product marketed in a newspaper ad. But there’s a high risk of creating barriers for people with disabilities unless you use QR codes correctly. This article is your ultimate guide to accessible QR codes!

What is a QR code?

“QR” stands for “Quick Response”, and you’ve probably seen the square pattern being used in “read more” parts of paper ads like this:

Or in online bank login screens like this:

And there are many other uses for them:

Scanning a QR code on a new dishwasher to open up an installation guide video.
QR codes in books to help people with dyslexia access audio/video versions of the text, like in this “Blipsay” example by Susanna Cederquist. (PDF)
Restaurants linking to a digital menu or the restaurant’s app from a physical menu.
Physical mail containing links where a QR code saves you from manually typing the URL into a browser.
Smart TV interactions like login and payments using QR codes on screen.

Advantages of QR codes

A QR code can bridge the gap between the physical world and the digital world, and it can save a lot of time and hassle for many users.

Most modern phones have QR code scanning functionality built into their camera apps, so users don’t even need to download an app.

General problems with QR codes

Instructions and help

QR codes are still fairly new, and far from everyone knows what they are and how to use them!

And even if users know how to scan a QR code with their camera app, that doesn’t always work! For example, two-factor authentication QR codes look exactly like other QR codes but shouldn’t be scanned using the normal scanning app or the built in camera scanner – users might need to use a specific identification app to scan these codes. It’s not alway obvious to users when to use which app or why there’s a difference at all, so instructions are vital!

The solution is to write instructions of the steps that the user needs to complete in order to login with a QR code.

Here’s a good example of instructions for a two-factor identification app in Sweden:

Open the BankID app on your phone or tablet.
Press “scan QR code” in the app.
Point your phone or tablet at the QR code on the screen.
Follow instructions in the app.

You can also give some extra instructions for screen reader and other assistive technologies users, which we’ll go through later.

When you use QR codes in printed media or in other devices such as TV-apps or gaming consoles, it helps to put the link (URL) which the QR code represents in plain text alongside with the code itself. Not only does this enable the user to manually type it if needed, it also hints at what the QR code will do – take them to another page.

Time limit

QR codes used in login scenarios often have time limits for security reasons, but short time limits mean that some users won’t have time to read the instructions or start the app and scan the QR code before timing out. These time limits are often set based on the assumption that the user is a strong reader with perfect eyesight, but following written instructions when using assistive technologies like a screen reader can require a lot more time than other users would need. The same goes for many users with cognitive disabilities like dyslexia or ADHD.

According to the WCAG (Web Content Accessibility Guidelines), users need to be able to extend any time limits in digital interfaces at least 10 times. Users also needs to be notified at least 20 seconds before the time limit ends. So if you, like many others, use a 30 second time limit you need to notify the user after 10 seconds that they’re running out of time. That is, if you want to conform to the WCAG, which may be required by law.

If getting interrupted once every 10 seconds with a warning prompt sounds annoying, you should try to increase the default time limit to be as long as possible.

We recommend having at least 3-5 minutes as a time limit. You still need to give users the ability to extend the timer, and we recommend notifying the user when there are 30 seconds left. Give the users an easy way of extending the session, such as pressing a button or just pressing space on the keyboard. When you notify the user it’s important to use simple language and short copy, such as a message like “30 seconds left for login” along with a button labeled “Extend”.

If you have limited motor skills or have a mobile device mounted on a wheelchair, it could be hard or even impossible to pick up the phone and use the camera to scan the QR code.

We made this video with Jessica, who highlights how QR codes can be problematic for users with motor impairments and shows her “techy workaround”. It’s in Swedish but with English subtitles.

To manage these issues you should offer alternative ways to sign in, for instance using username and password with two-factor authentication. There are such solutions that don’t require scanning a QR code. Here in Sweden we have software called “BankID on file” for this purpose.

As a person with a severe visual impairment, I often use a screen reader to convey text and other information on my screen. With QR codes being very much a visual thing, many accessibility issues arise from assuming that users are able to see what’s on the screen.

Position of QR codes

Not all users will know where on the screen the QR code is located.

You can help us by making the QR code centered on screen, as that’s where most users will likely attempt to find it first.

Obscured or cut-off QR codes

Not all users will know if the full QR code is visible in their browser window or not. Here we see a QR code getting cut off when I’d accidentally made my browser window smaller. Tiny browser windows are quite common among our friends who use screen readers, because most of them don’t need it to be a specific size to access the content of the page.

Cut off QR codes can also be caused by being zoomed in using browser zoom settings, but more on that under “Problems for magnification”.

A common (but bad) solution to this is adding help text with shortcut commands to increase window size. One big drawback when implementing this solution is that you need to have system specific shortcut commands for all operating systems and browsers. There are also usability and accessibility problems with this approach:

Long instructions of this type add additional cognitive load in an already stressful scenario, especially if time limits are in place.
Users who need to increase the window size might not be able to use a keyboard as instructed due to motor impairments (try pressing “ctrl” and “+” at the same time with only one arm).

This can be better solved by letting users activate the QR code by clicking or pressing it as well as activating it using the space or enter keys, and letting that trigger fullscreen mode using the Fullscreen API in the browser. Check out my CodePen demo or the demo with code to see how. That way the whole QR code will be visible, no matter which window size the browser was opened in.

QR code outside of view

Imagine this: the user has scrolled down on the page and the QR code is no longer in view, but they’re unaware of this issue due to visual impairments.

This actually happens a lot while reading list instructions or navigating on the QR code page, the screen reader might scroll down and the QR code is then outside of view or cut off.

How to solve it? Make the QR code sticky so it can’t get out of view! It’s OK that some content gets hidden behind the QR code when scrolling, if the QR code is the main actionable content on the page as in my examples. However, if possible, you should make the instructions at least partially visible when scrolling. Again, you can test my CodePen demo and try to zoom in and scroll.

There’s no need to make the QR code huge, so set a maximum width and height if it helps ensure that instructions remain visible. Zoom in on my CodePen demo to see how it can stay small even if you use ctrl or cmd + to zoom in the page.

Instructions and help

This is one of those situations where it makes sense to give additional instructions for how to scan the QR code to users who use a screen reader. But they can be visually hidden since non-screenreader users don’t need these.

Scan with your camera about 30 centimeters, or an arm’s length distance from the screen.
Make sure your screen shade or screen curtain is off
- JAWS: JAWS-KEY + SPACEBAR + F11
- NVDA: NVDA + CONTROL + ESCAPE
- VoiceOver: VO + SHIFT + F11
Ensure your browser window is large enough or maximized. Press the QR code button or maximize here (button to activate).
Ensure your screen/monitor is turned on.

This conveys in simple language how to manage the phone and the screen while scanning a QR code. It gives a guide for turning off the screen curtain (dark screen) on different variants of screen readers. It also hints at maximizing the browser window and preferably gives a quick button that does it for them. And it states, perhaps obvious but easy to forget, to turn the screen on. Remember that many screen reader users do not need the screen to be on for them to browse the internet.

It helps screen reader users if you put these specific instructions under their own heading. This makes it easier to find and navigate to the instructions.

Problems for magnification

Cut-off QR codes

Users with reduced vision sometimes browse websites using browsers’ built in zoom of 200% or more. QR codes easily get cut off when zoomed in, as shown in this image where 250% zoom is used:

The solution again is to make the QR code sticky or clickable – or both. Here’s a 43 second demo of that in action on a Swedish insurance and banking site:

This also works great in my CodePen QR code demo.

Mouse pointer obstructing QR code

Users might have a larger mouse pointer or be unaware of its position. This can result in the obstructed QR code losing its functionality.

You can solve this by hiding the pointer after three seconds if it’s on top of the QR code, like the YouTube player does when watching a video. Just set the ‘cursor’ css to ‘none’ after 3 seconds, and make sure to change it back when moving the mouse again. Did I mention that I have a CodePen demo? Well I do, and you can try hovering over the QR code and holding still to see what I mean.

Great resources

Länsförsäkringar bank have implemented a lot of the feedback and ideas from my talk. You can test it by selecting the option “Mobilt BankID”.
WCAG 2.2.1 Timing adjustable – Success Criterion
CodePen demo by Daniel Göransson
Recording of my Swedish talk about QR codes from 2022 at T12t Meetup. English subtitles are available. I’ve embedded the talk here below.

In summary

Craft great instructions on how to use QR codes
Make the QR codes centered
Make the QR codes sticky
Allow users to open the QR code in full screen
Write extra instructions for screen reader users
Hide the mouse cursor after 3 seconds
Allow for longer timout limits (3-5 minutes)

Thanks for making the web better!

I’m happy you read this far! It means you care about making the web a better place for all users. Spread the knowledge and keep being awesome!

Want to learn more? We run accessibility workshops that help teams design and test digital flows against WCAG, including timing, keyboard, and screen-reader requirements.

Apple Vision Pro – with 1% vision

Daniel Göransson — Thu, 29 Feb 2024 11:13:13 +0000

I got a chance to try out the Apple Vision Pro for an hour. Having a vision impairment myself, I obviously dove straight into the accessibility settings to find out if this new, hyped technology would work for me. Let’s go through how it went.

I was worried

I usually trust Apple devices will work great for me. For instance, when the Apple Watch first came out, I preordered it without hesitating at all. And sure enough, it came loaded with VoiceOver, zoom and other features, so it worked great for me.

But with the Apple Vision Pro, I worried. Not that it wouldn’t include the accessibility features I’m used to, but because of the foundation of the technology: it records eye-movements and makes the image clear where you’re looking.

For me, that could be a problem. I have peripheral vision. So I don’t see at all in the middle of my field of vision. Here’s a simulation of that:

So I “aim my eyes” to the side of what I want to see, to see it as clearly as possible. If the Apple Vision Pro makes the peripheral stuff too fuzzy, then I’d probably not be able to use it efficiently at all.

Onboarding – great first impression

You can trust Apple to include accessibility right out of the box. No surprises there. On the first screen you get to, there’s a prompt to tripple click the digital crown to activate accessibility features. I immediately got a short tutorial to the main VoiceOver gestures:

Pinch left thumb and index finger to click
Right thumb and index finger to step forward
Right thumb and middle finger to move back

With this, I could independently read the first few screens with instructions. I was most interested in activating zoom, but figured that I’d do that once I got into the main interface.

The eye setup – unsuccessful but not a blocker

The main step of the set up process consisted of having me look at a dot moving around clockwise in front of me. Since I had VoiceOver turned on, the experience was a bit different than the “regular” one.

In the regular onboarding, it shows six dots at once and asks the user look and tap for each dot.

It does this in three rounds, with lighter and lighter conditions.

For me, with VoiceOver turned on, it only showed one dot at a time and asked me to just look at it, not tap it. After a second or so it moved to the next position.

Here’s a low-quality video of me doing the eye setup, with my colleague holding up an iPhone so you might be able to see what’s going on. Also, kids running around in the background, a great illustration of situational cognitive load..!

Round 1 was on a dark background, but then it got brighter and brighter. It felt like I could do the first round quite well, but the third, brightest round was almost impossible for me. I also didn’t get any audio feedback when the dot moved, which would have helped. Something like: “Dot position at 12 o’clock. Dot moved to position at 2 o’clock.”

And sure enough, I got an error message “Eye setup unsuccessful”. Tried it again, where my colleague tried to help by telling me when and where the dots moved to, but with the same result.

Luckily, there was a “Skip eye setup”, so I pressed that. And found that it worked fairly well for me without the calibration.

It made me a bit disappointed though, and I felt unsure how much this would affect me moving forward.

Accessibility settings to the rescue

Getting into the main screen felt nice. I had gotten the hang of the basic VoiceOver gestures and could quite easily navigate to Settings and Accessibility. This experience was very consistent to iOS and MacOS.

I found settings for Zoom, activated full screen zooming instead of window zooming, which is how I have it set up on my other devices.

To activate and adjust zooming, I press the physical button on the top left of the device and rotated the digital crown.

I found that the maximum default zoom level was too zoomed out. So I needed to activate VoiceOver and try to increase the zoom level. Which was a slider, and I didn’t instinctively understand how to increase that slider. So had to go online on a smartphone and read up on that. Finally I figured out some way to do it. It wasn’t intuitive to me, though.

So with the maximum zoom set to 10x instead of 5x, I could much more easily use the interface.

But it was still difficult to read a lot of the text in the settings screen. So I increased the text sizes (dynamic type). Then I found the increase contrast feature which was a game changer for me. Making things more “dark mode” helped a lot.

With these settings I could start the dinousaur experience that you probably heard of, use zoom in that to get a great experience!

Overall

My feelings after having used the Apple Vision Pro for about an hour were optimistic.

Even though the eye setup failed, it didn’t seem to affect my experience much.

I think after getting used to the gestures and interface it would become quite a nice tool for me. Especially once I get the hang of scaling “screens” in the interface larger or smaller, to immerse myself in them, that could work really well for me.

Like for anyone, it’s going to require getting used to the new gestures and functionality. Doing this with accessibility features turned on adds an extra layer to this learning process.

It all reminded me of when I first got my iPhone 3GS, the first iPhone with VoiceOver on it. There were a lot of gestures and fundamentals to learn and it took some time. But we all know how that turned out, I use my phone everyday with gestures that now feels like second nature. I’m optimistic that I one day will feel the same about Apple Vision Pro!

Inaccessible Marketing Emails Suck!

Erik Gustafsson Spagnoli — Thu, 22 Feb 2024 14:45:12 +0000

I hate to see how many marketing emails that go to waste and frankly, suck! It really has irritated me throughout the years – so much it became my contribution to Axe-con 2024 and this article.

Summary

This is a rant about poor email communication that relies too much on embedded images being shown (they rarely are). Bad examples of newsletters and other types of email are shown (some are truly horrible) along with good examples to learn from. This is not an in-depth how to guide on coding accessible email but I will share resources to get you started.

Introduction to my rant

So across my many email accounts I get roughly 300 emails every week. Important stuff such as invoices and meeting plans, updates from the kids’ school and doctor appointments. Also, I get calendar reminders, updates regarding services, and countless marketing newsletters.

Too many marketing emails rely on using images. But guess what, I never load images in my Gmail accounts! Images are deactivated by default and other email services and it takes a manual click to load them. When I travel abroad I have limited data plan I need to be mindful of the mobile data usage, even though I have unlimited data plan in Sweden.

So, with a well structured email, a great subject and well described content you have perhaps half a second to get my interest so that I will open your email. Given these challenges and the resources required to communicate or sell through email, I just really hate to see companies mess up by relying too much on using images in their emails. You have customers who actually want to read your content – make sure they can by making it accessible for all of them.

Do you have the time to listen to me whine? Let’s go

Transparency

I myself or colleagues at Axess Lab has worked or are actively working with with several of the clients listed. Often we work with departments that do not directly work with marketing and they often do not see improving newsletters as a priority. I hope this is a wake-up call for our clients and everyone else reading the article – that you need to get your stuff together! We or other professionals are out there to help.

Reason to not load images

There are many reasons to not load images, these are some of my reasons.

Bandwidth restrictions

You might have a slow internet connection, it might be to low speed in your home or while travelling on a train. Going hiking often poses threats to your ability to load before the request times out.

Limited data plan

There are many reasons not to have unlimited data plans. They might not even be available in your country or as I often find myself while travelling abroad they are capped to a certain gigabyte. It might be very expensive and even paying by megabyte (MB) usage. So really it could be for some to choose between food or buying mobile data.

Privacy

When you load external images, you give away data about reading the email. Putting that in correlation with clicks on links and previous data shared it adds into the vast knowledge bank put in the hands of multinational companies working for profit.

Examples of emails

Emails that suck

My main interest with this newsletter is to know how many bonus points I have from the grocery stores ICA. Or more specifically how much I get back in money which I can deduct when shopping.

Almost everything in the image above is text, except for how much bonus I get… Aaahhh!

They also have some inspirational content to help you with shopping and what to eat. ALT-text is showing same text as heading.

Let’s head to the loaded images!

And here comes the loaded image, visually showing bonus amount of 50kr.

The duplicated text is visually showing image about the shopping app. The text in the image is also different, so I suspect they did have a plan here…

Quite good layout with different backgrounds, headings and non-image call to action buttons.

ALT-text says 115×115, probably perfect for the one editor. Not very helpful for the thousands of recipients.

The footer of the email has contrast issues and cryptic ALT-texts.

115×115 ALT-text shows an illustration of a foot.

Also, missing information about the sender. The two logos that had no ALT-texts was beneath social icons.

ALT-texts are different from the headings, I think… But they are cut-off, only showing half.

Zoomed in on ALT-text example only showing half.

In darkmode the light green button background make the changed white text unreadable.

Two ALT-texts provided:

Aktiviteter ombord
FriendSHIP

Images displayed are not matching ALT-text description.

Really poor contrast values on text and all images says “image” in their ALT-texts. Contrast of 3:2:1 on very light grey text on white background.

Zoomed in on alt text saying “image”.

Loaded images, showing lineup poster with a lot of band names.

ALT-text “image” on loaded image is a concert poster.

ALT-text on image in email from music store says “Friday releases”.

On mobile the email is zoomed out to desktop version. Unreadable.

First part of Friday releases visual image loaded. Consisting of a lot of band names and albums.

Last part of Friday releases with a lot of band names and editorial pitches.

Example of desktop email with no huge issues.

Example of same email in mobile, unreadable zoomed out desktop version.

Broken attributes “jobname” and image code that should have been something else.

Coop membership survey

In mobile the button line-breaks and overlaps.

Thanks to Amin Amini for finding this example!

Using CSS to make extra link large and covering surrounding text.

Even the text next to link looks depressed as a sad smiley.

A lot of ALT-texts written which is on a positive note, but there’s no space in between and strange fonts makes it very hard to read.

Horror section

Kronans apotek

Welcome as member at Kronans Apotek!

So I became a member when I tested the site and made a purchase. Nice with a hello and welcome… But… It was very empty, which I thought was a huge waste of opportunity to make me buy more stuff.

It was suspiciously empty with unloaded images. I needed to ease my suspicious mind…

And behold, there was a lot of information about their offering, services, apps and much more. Everything is image-based with image-map links. It almost made me cry!

Campaign newsletter missing ALT-text for main image.

Main image with a lot of offers.

Main image zoomed out with about 20 call to actions in the image.

MyFujifilm

Empty email with only a footer.

Let’s look at it with loaded images, surprisingly it has a lot of call to actions.

Check out the big news from Ubisoft Forward! Unreadable alt-texts and no headings. 2:8:1 Contrast ratio on blue ALT-text on dark background.

ALT-text has really generic naming that probably makes sense to the editor.

Unsubscribe link. Link not underlined, it looks like text. Grinch not happy!

Zoomed in on one of many ALT-texts having a generic name saying 212TTC_Right_Image. There’s probably some content behind the puzzle of ALT-texts?

Images loaded showing text in images with key information about the offer.

More text in images showcasing different games.

SF Anytime latest movie releases

This is from a Swedish online movie streaming provider.

The ALT-texts are really hard to read, dark blue on black background.

ALT texts beneath heading “Finally you can rent:”.

ALT-texts:

Barbie.
Book.
Art.
Advertisement.
Face.
Firearm.

Movie posters not conveyed in text.

Random words for ALT-texts were different movie posters. Example “Face” was for the movie Darkland 2.

Kila möbler Christmas offerings

Empty email from Kila möbler. Zoomed out full empty email with only a footer. My ALT-senses are tingling again!

About 60 CTA’s in the email, not displayed for potential customers.

Stadium Outlet

Email with product categories and text that says the terms of the offering and a “Shop”. The title is the best, “You haven’t missed…” Well in fact… I have missed all of it…

Yet another text in image marketing letter.

Debaser concert news

Concert information heading “Dont miss this” followed by two empty images.

Don’t miss this, images loaded shows date, location and band names.

To be fair they have improved their email marketing letters since.

Eventim newsletter in Swedish with event suggestions.

Eventim suggestions zoomed in, generic ALT-texts are written in German. “Unsere Empfehlung 1” “Unsere Empfehlung 2” and so on.

Eventim suggestions loaded images, showing poster, location, date, band name, and call to action to buy a ticket.

Christmas email sent out. Two column layout. Black text on dark blue to black background with stars, and a moon overlayed by reindeers flying a sleigh. Unreadable.

Thanks to Homer Gaines for sharing this horrific example

Better examples

There’s a soothing light in the tunnel and it is not just a freight train coming your way. There are better examples out there. And by better, I do not mean perfect. There are parts in the same email that are good and some not so good. The examples I will describe are simply just better in providing content that does depend on images.

Impecta fröhandel

Newsletter with ALT-texts, normal text and CSS call to action buttons.

Loaded images, looks a lot prettier but it is mostly added visual goodies.

Ebay newsletter showing good structure with headings and text.

Ebay could improve adding product suggestion image ALT-texts.

Runkeeper yearly update

RunKeeper has ALT-texts and text content. Text content instructs to click on 2023 image to load the data, which has corresponding ALT.

RunKeeper images loaded, visuals could be added as text instead of text in image.

Better example from Eventim where image content is conveyed in text.

Eventim email with loaded images.

Email from Jula, a Swedish retailer.

Using Headings and text and layout with spacing.

Easy to see titles and pricing without images.

Email from Jula with loaded images. The image content is conveyed in text.

Product brand name is missing, could be added.

Concert news from Live Nation

Concert update from Live Nation missing ALT-texts but the headings are sufficient.

Unsubscribe links

In all my newsletters I’ve seen a pattern. Make it as damn hard as possible, or even impossible to unsubscribe. Do you know what happens to these emails? They get marked as SPAM and that surely decreases your visibility even more. Getting flagged as SPAM, unwanted or fraudulent email is not good… Sad but true!

Bingolotto

Horrible example and this is not by changing colors due to dark mode. This is just one of the worst examples I could find, it has 1:2:1 contrast ratio.

Foursquare

Just linking the word “Click here” and with a really really poor 2:5:1 contrast ratio Foursquare deserves the SPAM folder. It is extra evil making the font very very small.

FKP Scorpio

If the contrast was good enough the content would actually be good. Headings and paragraph text. 3:2:1 contrast ratio on text

Unsubscribe link, good clear wording but bad contrast. 2:4:1 contrast ratio on orange link. Just fix the contrasts, pretty please…

Bahnhof

Unsubscribe link in a different language and only the word “here” is linked.

Demando

Unsubscribe link in a different language. Most people in Sweden speak English, but this is also a strange context switch.

Nintendo

Unsubscribe link with the word “Click here”. So you need to read the full paragraph to know what they refer to.

Readly

Unsubscribe link in text content only shown as bolded text with the word decline.

Thanks to Martin Falk Johansson for this example

Ebay

eBay example with underlined, good contrast unsubscribe link

Amazon

Amazon email example on desktop, yellow button background with black text. Good contrast.

Amazon email example on mobile dark mode, yellow button background with white text. Unreadable.

Resources

If you want to know more about how to make email more accessible and consistent across platforms, then these resources will help you along!

A good resource from Harvard University about who to compose your emails Creating Accessible Emails.

In 2019 i went to SmashingConf in Freiburg. I met Rémi Parmentier and listened to his interesting talk Think Like An Email Geek about how to combat a well designed email in different email systems, such as Outlook or Gmail. When I was looking for the link to this talk I also saw that he returned to Freiburg in 2022 expanding the subject with issues in Dark mode in the talk Shining the Light on HTML Email Dark Modes. Really interesting and he finished off with announcing the great resource Can I email which is based on the well known Can I use. There’s also an in-depth article Essential Tips and Tricks for Coding HTML Emails. Hats off for Rémi for sharing!

You can always register and watch my talk at Axe-con 2024 on demand.

Conclusion

Just by testing your shit in at least a few email clients regularly you can avoid loosing potential customers not buying your products or services.

There are really small fixes in which you can be visible to all your subscribers and…

…tadaaa! You also make it more accessible for people who can’t see loaded images.

Avoid the SPAM folder and make an A11y Grinch happy!

Top seven free color contrast checkers & analyzers

Hampus Sethfors — Thu, 18 Jan 2024 09:05:40 +0000

Here are seven great free tools that help you measure color contrasts and create beautiful, accessible color schemes that fulfill the contrast requirements in the Web Content Accessibility Guidelines (WCAG).

1. Colour Contrast Analyser – by The Paciello Group

Colour Contrast Analyser

Perfect if you’re measuring contrasts a lot.

Desktop application for Mac and PC
Analyze any colors appearing anywhere on your screen with the “Colour Picker”
Shows how contrast varies with different types of color blindness

Screenshot of Colour Contrast Analyser

2. Coolors – online checker

Color contrast checker (coolors.co)

Perfect if you just want a quick and easy contrast measurement without having to download anything.

Measure contrast quickly in this web app
Very intuitive to use
“Click to fix” feature suggesting new accessible colors

Screenshot of Coolors

3. Tanaguru Contrast Finder

Tanaguru Contrast Finder

Perfect if you want to find a new accessible color combination if your combination fails.

Web app that measures contrasts
Suggests alternative colors if your combination fails
Open source if you want to contribute

Screenshot of Tanaguru Contrast Finder

4. Contraste for Mac

Contraste (contasteapp.com)

Perfect, simple tool if you’re a Mac fan!

Simple and lightweight
The most aesthetic tool in this line-up, if you ask me
Multiple ways to pick colors, including a handy pipette tool

Screenshot of Contraste for Mac

5. Color Contrast – iOS app by UserLight

Color Contrast at App Store

Perfect if you prefer working on iOS devices.

App for iOS devices
Test colors of apps, websites or screenshots
Available in iOS Control Center (swipe up from bottom of screen) for quick live testing

Screenshot of Color Contrast iOS app

6. Android Accessibility Scanner – Android app by Google

Android Accessibility Scanner at Google Play

Great if you work with Android apps.

Scan apps with your Android device
Points out other accessibility issues as well as contrasts
Created and curated by Google.

Screenshot of Android Accessibility Scanner

7. Leonardocolor.io

Leonardocolor.io

A powerful online-tool that let’s you create color systems for interfaces and data visualisation.

Need certainty you meet WCAG? Our experts do a full review with assistive tech videos and prioritized fixes.

Toggles suck!

Joel Holmberg — Fri, 28 Jul 2023 17:21:52 +0000

You’ve all seen them, tiny switches that let you toggle a setting. And maybe, just like me, you sometimes pause, thinking “…Is it on or off?” That’s because toggles suck!

It all started when I wanted to find the best price for a new headset that I needed to perform my online courses for our clients. I went to www.pricerunner.com but I got interrupted by a cookie popup. Knowing that free websites use a lot of dark patterns and tricks to make us users accept trackers against our will, I wanted to make sure I did not accept any cookies. This is what I saw:

“Are they on” I thought? And does “on” mean I accept or decline the cookies? What’s going on here? This interface forced me to think!

Now, I’m no coward! My usual strategy online is to try pressing buttons to see what they do! Problem is – nothing seems to happen when pressing these buttons, so that doesn’t work! All I can assume is that pressing these gray things will change the setting. But change to what?! It took me far longer than should be necessary to figure it out. My confusion had time to turn into frustration and by the time I figured it out that frustration had lit a tiny fire of anger in my chest! I realized this was not my first time raging against unclear toggles, but I couldn’t exactly explain why I hated them so much?

So I decided to do some research and collect my thoughts and now I’m writing this article about Why Toggles Suck!

Short version

This is an in-depth article, so here are the main takeaways for readers in a hurry. Toggles fail to convey their current status without making users think! They also have very poor accessibility for users with disabilities. They are used inconsistently across the web, and they don’t have native HTML support. Use checkboxes or radio groups instead, or some of the other options described below!

What’s a toggle?

Digital toggles have existed since the early versions of smartphones. Especially common under different “settings” views on touch devices, they are used for things like turning WiFi on/off. They are called “toggles” or “toggle switches” since they switch something on or off, or “toggle” its status back and forth when activated.

To truly understand why they suck, it helps to compare them to two other controls that accomplish the same thing, but that actually work well. Physical toggles and digital checkboxes. Let’s first list some reasons why they work well, and then later investigate if digital toggles fulfill those same requirements or not!

Physical toggles

We are used to light switches turning the light on/off in a room.

And many electrical devices use toggles the same way

Toggles work well for lights and electrical outlets for many reasons, some more obvious than others:

They enforce a mutually exclusive state, on or off.
They let users press the state they want.
Pressing “on” many times in a row is not a problem.
Labels are a bonus but not really needed since:
Context makes the current state obvious.

The last one is important. The results are obvious when turning on a light switch – the room gets lit! The results are also obvious when turning on the electrical junction box above because stuff connected to it starts working. The toggle also has a LED indicator lighting up when it has electricity so it’s obviously on because a LED cannot light up without electricity in the box. So you don’t really need to label these toggles. The junction box toggle above still has “O/I” labels though, for when it is not connected to a wall outlet, or if the LED in the button is broken.

But the light switch has no label, since context is enough… most of the time! But if that switch were to be placed – oh I don’t know – outside of my bathroom instead of inside . Then the status of the switch is no longer obvious! Like when my fiancé is using the bathroom and I’m outside the door. In that situation, how can I know what its current state is? I can’t! So really – she has no right to be mad at me for making her poop-in-the-dark, when I’m just trying to help light up the room!

With a label like the one on the junction box you can put your finger on the choice you want and press it in. If you press “I” you can be sure it’s turned ON. If you want to be very sure, you can press “I” very hard or several times. It will still be ON. Assuming of course that you know that “O” means “off” and “I” means “on”. I still mix them up regularly; “O mean ON, and I means IN? No… what was it again?”. But I digress!

Same with the light switch outside my bathroom. If it had “on” written above the button, and “off” written under it like this:

Then I would know the state from the control itself because of a principle called the “proximity principle” in visual design.

I would press closest to the “on” label. In both cases, you simply press the thing you want!

Pressing what you want is a natural human instinct and universal. There are no cultures in the world where the learned pattern is to “press what you don’t want”. Imagine a child standing by an ice cream stand pointing to all the flavors they don’t want. Doesn’t make sense, does it? Because we humans point with one finger, in order to single out one thing while excluding everything else! We point to the thing we want!

But then – how come we understand checkboxes?

Digital checkboxes

You see a checkmark and you want the thing to be checked – so according to “press the thing you want” I should press the checkmark to get it?

No! So how come we understand checkboxes?

A checkbox has two modes, “checked” or “not checked” and is normally part of a form.

The checkbox as a form component comes from the physical paper form where it has been used for ages, long before computers were a thing.

You would get an empty form

and be asked to post or hand over a filled in one.

It’s obvious that things are empty before I have started filling in the form. Text inputs are empty rectangles, checkboxes are empty squares. I use my pen to actively add things into the emptiness.

It would be absurd (but not impossible) to have it the other way around – imagine a form coming filled with stuff, and then having to erase stuff using white-out (like tipex) or an eraser to complete the form. That’s just not how we do things anywhere in the world!

So this has taught us a basic instinct over hundreds of years: empty shapes are not filled in, passive, untouched. Filled shapes are filled in, active, touched, and ready to be submitted.

And that’s why checkboxes work, cognitively! Same goes for radio buttons where the filled in shape is the active one.

It even works for text input boxes! In our user tests, a majority of users will assume an empty text field is actually mandatory and expect an input to be made.

So much so that we even recommend you to not use asterisks * to indicate mandatory fields, and instead mark optional fields as “optional”.

The “filled in = active / touched / done” pattern is so well recognized that if a text input field is not empty, many users will believe it’s done and requires no more work. That’s why you should try to avoid placeholder text…

… and labels that are positioned inside the input field like the commonly used Material UI component, even if it “moves away” on focus:

Users often assume “it’s filled in, so it’s completed” and skip to the next one looking for something empty.

Enter digital toggles

Now that we have established a few fundamentals that make physical toggles and digital checkboxes work – let’s see if digital toggles fulfill these criteria!

Press what you want

Nope! If a toggle says “On” then it’s actually an Off-button!

Allows multiple presses on the thing you want

Nope! Toggles change what they do each time you click them. This is also true for a checkbox (but they work for other reasons) – while a radio group fulfills this criteria!

Context makes labels unnecessary

Nope! Well, at least not usually. Toggles tend to be used for settings that are invisible or only visible later or in some other place.

That means there is no context to help you. Active cookies are about as noticeable as my bathroom lights when the door is shut. In that they are not! In these situations – labels on the control are very much needed and important! So you’d hope they follow the “Proximity principle” – right?

Proximity principle

Nope! Labels are often put far away from the control, and you often have to move the toggle “knob” away from the label representing what you activate. Not closer to it!

Perhaps I can make my point clearer with this image:

In the top toggle, users can understand that right means “no cookies” since it’s the rightmost label. While in the bottom toggle that looks like most toggles online with only one label on the left side, right means “cookies” all of a sudden. Proximity principle, schmoximity principle!

Of course this can be changed by having the toggle first, followed by the label.

But is that how people commonly use toggles? No!

Empty = passive, Filled in = active

Nope! A toggle has no “empty” state. Only left/right. There is no obvious “default” state when untouched, and there is no universal agreement of which side a “knob” should be on to be passive or active, on or off.

Most western designers seem to assume that “right = active”. But that’s my point! “Most” designers, but not all! It’s completely up to the designer to do what they want with toggles on the web because a toggle is not even a thing in HTML (more about that later). So there is no established “out of the box” behavior, at least not for the web! Oh, and only western designers – in arabic speaking countries the designers often make “left = active”.

Perhaps it becomes even more clear that direction is not a universally understood pattern for active vs. passive in this image:

I held my phone on the side when taking this photo. But I decided to not rotate it. No matter how I hold my phone I can understand which checkbox is active in the first frame. But which of the toggles are activated in frame 2-5? I have no idea! You cannot rely only on direction for conveying status!

Conclusion #1

The most common toggle on the web fulfills NONE of the criteria that make physical toggles and checkboxes understandable!

So am I done now? Nooooo! I’m just getting warmed up! Let’s look at 3 more things that are awful about toggles!

Toggles don’t exist!

“By hey – if they are so terrible, why is the toggle even in the HTML language?” – you may ask.

It isn’t! It’s been made up by designers! HTML is the language of the web, where programmers add elements like

If native HTML elements are good enough for Amazon, why are they not good enough for you?!

You can even use other HTML elements to toggle settings. A normal

If native HTML elements are good enough for Slack, why are they not good enough for you?!

Text labels on normal buttons indicate the action of the button, especially when using active language like “Turn on” instead of “On”.

Now, I know toggles “exist” in iOS and Android SDKs, so this last argument is not as valid for native apps. But the cognitive issues remain for toggles used in native apps, so they still suck! They just suck a tiny bit less in native settings…

So toggles are not real, at least not on the web, but some designers want that fresh look and feel of the toggle! What’s the actual problem with not using built in HTML elements?

Accessibility is the problem!

Accessibility problems

HTML elements come with a lot of “hidden features” that help users with disabilities and their assistive technologies, like screen readers. HTML elements have invisible roles, states, and labels only read aloud by screen readers and other assistive tech. This is what makes users with disabilities able to interpret and interact with websites, even if they don’t see the screen, or can’t use a mouse, or if they use eye tracking, or voice control, etc.

If you just style a “box” (an HTML

element is commonly used) to look like a toggle, and add some “onClick” logic in JavaScript, then it will be unusable by people with assistive technologies. Making such a toggle fully accessible is not impossible – but it’s really hard!

Haydon Pickering has a very good article about it here: https://inclusive-components.design/toggle-button/.

There are some more good ideas in this one by Sara Soueidan: https://www.sarasoueidan.com/blog/toggle-switch-design/ with both “proximity principle” and “press what you want” support.

And Adrian Roselli has a nice article here: https://adrianroselli.com/2019/03/under-engineered-toggles.html.

So it is possible to make accessible toggles. The problem is – most web developers and designers don’t know enough about accessibility. So they copy some toggle code from the internet, and then that’s what their users get. And that’s often completely inaccessible to screen readers and other assistive technologies! The effect being that the toggle is unreachable for them, or not possible to activate even if they reach it.

Unhelpful colors

Because the toggle is known to be confusing, designers add colors to help clarify! That’s generally a good thing. But it’s not enough! 8% of male users have red/green color vision deficiency. That means it’s not much help for them using green as “on” and red as “off”.

And, again because a toggle is not really a thing in HTML, designers can decide to use any look-and-feel, since they’ve made this component up and there is no “built in browser version” of it! Can you guess what the status is of this little gem I found?

Well, when you have red as your company’s profile color – red means “ON”.

Obvious – right? Making it easy for internet users to learn how to use this fancy toggle thing – right? …*sigh*

Some designers make it darker on activation, some make it lighter! Some use gray as “off” – but also as “on but disabled”.

Even the digitization agency in Sweden, who are supposed to make sure others follow the accessibility guidelines, have this terrible color scheme on their cookie toggle with hardly any perceivable difference in color:

And even when colors are perceived and understood (“green = on”), there is still cognitive confusion; is this green color a status or an action? Is this an on-button or an on-status? It cannot be both!

We can get guidance from WCAG point 1.4.1 – “don’t rely on only color to convey meaning”.

And you know who doesn’t rely at all on color to convey meaning? Checkboxes don’t. Radio buttons don’t. Just say’n.

Are there any situations where toggles are OK?

Yes! The main problem is understanding the current state – so if the state is obvious to the user for other reasons – a toggle can be cognitively OK. As long as you make sure it’s accessible!

Here is a toggle for filtering on Airbnb where a toggle button limits the amount of available houses. Users can understand by the reduced amount of houses that the filter is active, even if they don’t understand the toggle control. The number in the button is physically close to the toggle control, and many users will notice the change as it happens and draw the correct conclusion from context.

Users using zoom tools or screen readers may still miss it though, so make sure to test for that!

For multiple possible values that are mutually exclusive, a “toggle button group” can be effective. Especially if the state can be understood also from context! A good example is the “justify text” options in Google Docs:

Having multiple mutually exclusive options means the active option is obvious, since it’s the only one with a different look from the others. It would not be as obvious if there were only two options:

Which one is active?

The user can also instantly see how the text moves around to become centered or left adjusted, so context allows users to understand the state even if they would not understand the icons in the control:

Just don’t use it for 2-option settings:

Personally, I think the “Ja” (yes) looks pressed “into the website”, so it should be active, just like the buttons on an old radio:

Of course – again – I was wrong…

The “toggles have instant effects” fallacy

So you’ve heard about this huh? I understand, I mean it’s in the top results when you search “when to use toggles”, and even promoted by my heroes at Nielsen Norman Group https://www.nngroup.com/articles/toggle-switch-guidelines/. The claim is that “Toggles inform users that settings have immediate effect while radio/checkbox inputs will be followed by a submit button”.

Let’s first assume this statement is correct (it isn’t). Let’s say 100% of users believe that toggles have immediate effect, that checkboxes and radio buttons cannot have immediate effect, and that 100% of websites use them that way (they don’t). Then by adding a toggle you will effectively have users who know something happened instantly when they pressed the toggle. But many of them still have no clue what happened. Congratulations!

Now let’s prove it’s not even true!

You’ve already seen how Amazon and Slack use buttons and radio buttons with immediate effect. There are countless examples of websites doing the same. Even the big ones! Here is a settings page in Windows 10 where all settings have immediate effect. Both the toggle and the checkboxes. No “submit” button anywhere.

So how can you claim that every user knows that checkboxes and radio buttons are always followed by a submit button, when even Microsoft’s Windows teaches them otherwise?

Next, almost every cookie manager uses toggles followed by a submit button like “Save & exit” or “Submit my preferences”.

And another one:

So how can you believe that all users will know that toggles have an instant effect, when every cookie manager in the world teaches them otherwise?

This idea is simply not true!

And there is nothing code-wise that would motivate this belief! Remember, toggles are not a thing in HTML, so they are often coded as a checkbox, button, or radio button under the surface. So whatever you can do with a toggle, you can also do with those HTML elements!

Recommendation

Just use a checkbox or radio group! It’s quick to implement, accessible from the start, and doesn’t make the user think.

If you want to save the setting instantly – then do so! And inform the user either by making the effect obvious from context, like changing colors of the interface immediately when the user checks “high contrast mode”. If no visual or obvious effects exist, then inform the user with a toast or status update message like “setting updated!” or a loading indicator with the text “saving…” like Google does:

If users complain about the design (unlikely) or your design lead or boss demands a toggle at any cost (more likely) then follow this advice:

Don’t do it!

But if they insist…

Prepare to spend (waste) a LOT more time than you think to get this right
Make the current state obvious from context
Place the toggle close to what it affects
Don’t add a state label into the clickable button itself, as it may be interpreted as an “on-button” instead of a “button that is on”.
Don’t rely on color
Don’t assume everyone thinks “right = active”
Test the accessibility, preferably together with users with disabilities
Read up on accessibility and follow the linked articles

Summary

This table sums up the topics in this article:

I’ll leave you with this “great” example from an anonymous Swedish ferry company, where I still to this day have no idea what I have selected.

Toggles suck!

Feel free to tweet us at @AxessLab and share your own examples of confusing toggles! Or let us know why we’re wrong!

Screen reader quick guide

Joel Holmberg — Wed, 01 Feb 2023 13:57:22 +0000

Looking for a free quick guide, a “cheat sheet” or a “one pager” for screen reader testing? You’ve come to the right place!

There it is! Or an image of it at least, the actual document is linked further down.

So why did we create this?

We meet teams every day who are new to digital accessibility. Teams who need to start small and learn how to test their software using some basic assistive technology. Most guides are in depth and it’s hard to know what parts to focus on if you are a beginner.

This document attempts to solve that! It describes the simple commands that let you find the absolute majority of accessibility issues, without having to know much about the ins and outs of screen reader usage!

The one we show here is for Windows Narrator, but of course we have one for JAWS, NVDA, VoiceOver and Talkback too. Let us know and we can send one over, or get them all in our bundle of checklists!

This checklist and others like it are part of our checklist-bundles that we offer any organization who just started their accessibility efforts, and who need a quick and simple kickstart! They include to-the-point, one page checklists like:

Screen reader cheat sheet
Browser settings cheat sheet
A11y checklist – front end developers
A11y checklist – UX-designers
A11y checklist – text & language
A11y checklist – content and media
A11y checklist – legal (EU)
A11y checklist – legal (US)

All designed to be a first simple step and get your team going!

We know checklists are not a final solution to true inclusion in software development or long term digital accessibility work! Testing with real users is probably the most important thing to make sure everything works, which you can read about in our article User testing with people with disabilities.

You can also contact us to get help with accessibility audits, accessibility training and more.

With that said, we believe there is a time and place for checklists like these too! Enjoy

Quick guide for Windows Narrator

Quick guide for VoiceOver on macOS

Text transcript of the checklist

Windows Narrator

Start / quit
- Ctrl + Windows + Enter
Next / previous item
- Caps lock + arrow key right / left
Next / previous clickable item
- Tab / Shift + Tab
“Click”
- Enter / spacebar
Scan mode on/off
- Caps lock + spacebar
Next / previous landmark
- Scan mode → “D” / Shift + “D”
Next / previous header
- Scan mode → “H” / Shift + “H”
How do I test?
- Close your eyes or turn off your monitor!
- Do you find your way around the UI, or do you get lost?
- Are there landmarks and headers where you expect them?
- Can you complete normal use cases without looking?
- NOTE! Scan mode sometimes activates automatically so if the commands above don’t work, inactivate scan mode!
Psst!
- Ctrl = Stop talking

143.75% font size sucks

Hampus Sethfors — Wed, 16 Mar 2022 11:48:40 +0000

Interacting with our fan base is a fulfilling part of my job. Yesterday I got a request to write an article on why the font size on this site sucks. So let’s not waste any time and get straight to it!

The humble request

Nice font size 143.75% on that page. Maybe next they’ll have an article about why that sucks.

This graciously worded request was actually not sent directly to me, but to a fellow accessibility guru Nicolas Steenhout, who forwarded it to me in this tweet.

TFW a client asks about disabled inputs, and as part of the conversation, you send a link to "Disabled Buttons Suck" by @hampelusken (https://t.co/u8vAmxxbZN) and the response is… #a11y pic.twitter.com/PRnxtnjxlQ

— Nicolas Steenhout (@vavroom) March 15, 2022

So sadly I don’t know who this mystery fan is, but I’ll write this article, and like a message in a bottle I hope it finds its way to you somehow!

Why our 143.75% font size sucks

1. Your eyes don’t get the training they need

Having a font size that’s too easy to read is like lifting 100 gram weights at the gym. Your eyesight, like your muscles, need to be challenged to become stronger. A large font size isn’t challenging to anyone, not even people with low vision. So nobody is getting the training they need, not even people with disabilities. #abelism

2. Large is not as aesthetic as small

Look at this tiny painting:

Super impressive right? So much better than if that same painting had been on a regular sized canvas. This obviously also applies to letters on a webpage. Smaller letters are more impressive than larger ones. Simple logic. And we all know that users mainly visit webpages and read articles to experience beauty. Ergo large fonts suck.

I suggest pausing this article to browse the Pinterest page All things miniature for about 30 minutes, and then returning.

Welcome back!

3. Font size isn’t a requirement in WCAG

The Web Content Accessibility Guidelines (WCAG) is the holy grail of accessibility. And surprise, surprise, WCAG doesn’t include a single success criteria on font sizes!

That means that font sizes don’t matter to anyone because WCAG contains every single important consideration when it comes to accessibility. You can make font sizes 1 px. As long as they have good contrasts, anyone will be able to read them.

It’s just like people running around thinking that making interfaces intuitive and testing them with real users would somehow be important for accessibility reasons. It’s not in the WCAG so it’s not important. Glad we got that sorted out once and for all.

4. 143.75 is a stupid number

Who specifies font size with two decimal places? That’s just dumb. Also, it’s hard to remember such a long number for the programmer who writes the CSS code. This discriminates against programmers with memory impairments. #abelism

5. Other crappy sites use large fonts

CSS-tricks, IFTT and A list apart use font sizes that are in the same ballpark as the ones on this site. They, like us, know nothing about usability or web design and are shooting themselves in the foot with this poor choice of font size.

6. Relative font sizes let users control too much

Having your font sizes in relative units like %, EM or REM, instead of absolute units like pixels, makes it possible for users to adapt the font sizes as they wish. This jeopordizes the whole look-and-feel of the site. Users don’t know what makes a site look aesthetic, and shouldn’t be given the chance to mess it up.

It’s like giving everyone who visits the Picasso Museum a paint brush, and encouraging them to adapt the paintings if they don’t like them. Picasso is the expert in paintings, not the museum visitors. Programmers are experts in web design, not the site visitors.

I could go on forever…

But I think you get the point! So thanks for the great article suggestion and hope this was what you were looking for.

And just for legal reasons, this is a joke. We think larger than normal fonts are quite great!

If you liked this article…

Testing is a scary word

Hampus Sethfors — Mon, 24 Jan 2022 13:03:40 +0000

Can you keep a secret? Here’s why you should keep testing your product with users, but not say that’s what you’re doing. Basically – how to test with users without anyone knowing!

There has been some discussion in the UX community the last few years on what to call the activity that’s arguably the most important one in the UX-toolkit.

Ten years ago basically everyone said “user testing”. Then someone thought:

Hey! We have a problem with users feeling uncomfortable being tested. Calling it user testing makes this worse!

A great observation indeed.

But the solution – in my opoinion – not as brilliant:

Let’s switch from user testing to usability testing.

The idea is to point out that we’re not testing the user, we’re testing the usability of the product. But the problem is that the word “test” is still there…

Ponder a while on the word “test”

What comes to mind? Maybe you work in the tech sector, and you think of all your awesome colleagues in the testing department.

But if you consider what other people might connect to the word “test”, or think back to when you were in school, you probably realise that test usually is a scary word.

Tests in education can involve grades, disappointment and mental blackouts
Tests in sports can involve a lot of sweating or running until you puke
Tests in recruitment processes can involve tough questions and a fair bit of anxiety
Tests in healthcare can involve long needles – or worse!

All-in-all, the word test is probably negatively loaded for most people.

Now let’s take an accessibility perspective

At Axess Lab, we constantly urge people to involve people with disabilities in the design of products. It’s awesome for a bunch of reasons that we’ve listed in the article: Skip the WCAG! User test with people with disabilities instead.

But if you’re asking users with disabilities to join a “user/usability test session”, you’ll probably invoke even stronger negative feelings than with others. Why? Well, society is still really inaccessible and discriminatory. Many people with disabilities:

have a lower success rate in tests in sports and education, due to the tests being inaccessible, the training poor, the opportunities fewer and so on.
have a lower success rate in recruitment tests, due to recruiters being abelist, recruitment processes inaccessible and so on.
dislike healthcare tests…

I could go on for ages in that last healthcare bullet…but let’s just agree on that – at least historically – people with disabilities have been treated terribly when it comes to tests disguised as healthcare.

So if you’re aiming to get input from a diverse audience, the word test is probably not the best one to use.

What to say instead

So whether you call it user test or usability test, the people you’re trying to recruit probably hear the word “test”.

Let’s consider some options that are less likely to invoke stress and anxiety for the users you’re trying to recruit:

“We’re looking for feedback on our product…”
“We’d like your opinion on our design…”

Then you can go on to explain what the session is about. Like:

“We’re looking for feedback on our product. Would you be willing to meet with us – either in person or on a video call – where we show you a work-in-progress, ask you to walk through it and tell us what you think? It’ll take around 45 minutes and you’ll get $60 as thanks for your time.”

It’s so much more likely that people will find this description more enticing and less scary than if they’re asked to be part of a test.

But it’s not correct!

If you’re in the UX field, you might think that calling usability tests something like feedback session is incorrect. “There’s after all a big difference between asking for users’ opinions/feedback and a qualitative usability test!”

And you’re completely correct. I’m not saying we must change the term when we speak amongst each other in the field. All I’m saying is that we shouldn’t use the same language when we recruit or talk to the users.

When I’m at the dentist, there are usually two dentists in the room, and when they speak to each other I barely understand a word. It’s like: “11-3 bilateral dust CDS”. Then one of them turns to me and says: “Everything looks fine, we’re just going to make your teeth a bit whiter with this brushy thing.”

And I’m completely fine with that. The dentists use their own terms and jargon when speaking to each other, then translate that to non-dentist language when communicating with me.

So keep saying usability test, user test or whatever when talking to others within the tech field, but as soon as you’re inviting others to join these sessions, keep the word test a secret!

If you liked this article…

…you might also enjoy these:

What’s new in the European EN-standard update from 2.1.2 to 3.2.1?

Hampus Sethfors — Tue, 21 Dec 2021 15:40:23 +0000

In the EU, the laws on digital accessibility for the public sector all point to a standard called EN 301 549. It’s been updated, and here in Europe a lot of people who work with web sites and apps are asking what this means for them.

Most news are probably not relevant to you

If you work with web or apps – which most people who read this article probably do – I’d say about 95% of the update is completely irrelevant to you. Instead it affects other types of ICT (information and communication technologies), like:

Two-way voice communication, like intercoms
Software, like if you build Microsoft Word
Tactile buttons on physical devices, like ATM:s and ticketing machines

People generally forget that the EN-standard aims to cover all types of digital products, so just a part of it is relevant for web and apps.

If you work with the web

I’m not going to walk through all the changes that relate to things other than web or apps. You can read about those yourself in the documents linked in the end of this article.

So lo and behold! Here are the relevant news regarding the web!

PDF:s and other documents that users download are now covered

If you publish a pdf-file or other document as a downloadable file on your site, those now also need to be accessible according to the law.

“Is this really news?” you might ask yourself.

Yes, there seems to have been a loophole in the law, where the only types of documents covered were “documents that are web pages” and “documents that are embedded in web pages”.

Now they’ve added “documents, including forms, that are downloadable from web pages but are neither embedded nor rendered together with the web page from which they are provided”.

So basically, everyone – including me – probably already thought the downloadable documents were covered. They were not. But now they are. Nothing really changed in practice, but a loophole was covered.

Come to think of it, it’s actually nice to have a clarification that documents include forms! So if you build forms in Word or pdf:s the law affects you too.

Subtitles need to be “styleable” and “speakable”, but not really..!

Two new requirements affect subtitles/captions. They are:

7.1.4 Captions characteristics: “Where ICT displays captions, it shall provide a way for the user to adapt the displayed characteristics of captions to their individual requirements, except where the captions are displayed as unmodifiable characters. Defining the background and foreground colour of subtitles, font type, size opacity of the background box of subtitles, and the contour or border of the fonts can contribute to meeting this requirement.”
7.1.5 Spoken subtitles: “Where ICT displays video with synchronized audio, it shall have a mode of operation to provide a spoken output of the available captions, except where the content of the displayed captions is not programmatically determinable.”

My first thought was: “Great! This means subtitles burned into the video are not allowed, because only subtitles created with the standard formats can be spoken and adapted.” But then I read the “except”-part a bit more closely. And the exceptions basically seem to say that if subtitles are burned in, these requirements don’t apply.

So to my understanding, nothing has changed for video creators. But if you build video players, or are deciding which video player to use on your site, you need to take this into account.

Very nitty-gritty-specific-cases

There are a lot of small additions to very specific cases relating to websites.

Let me take two examples:

If your site has a way to activate specific accessibility features – which usually is a bad idea in the first place – you need to have a method of activating this feature “without relying on a method that does not support that need.” So my interpretation is that if you have a high contrast mode, that activation button needs to be high contrast. Or if you have a screen reader friendly mode, you need some kind of shortcut that’s announced to screen readers to activate it.
If your site has two-way voice communication features – like support call embedded in the website – there are a bunch o requirements about having real-time texting, speaker identification and so on.

There are a few more like these.

If you’re interested in all these specific “edge-cases”, go to the heading “Requirments in EN 301 549 and relevant to the WAD, but not in WCAG 2.1” in this article:

Latest changes to accessibility standard (europa.eu)

Check out the documents

If you want to check out the updates for yourself, here are the two versions of the standard:

New version: EN 301 549 v3.2.1 (pdf on etsi.org)

Old version: EN 301 549 v2.1.2 (pdf on etsi.org)

Also, the article on europa.eu that I linked to earlier is a more formal summary than this article. Here it is again if you want to dive deeper:

Latest changes to accessibility standard (europa.eu)

I may have missed stuff

Here are some necessary disclaimers! I’ve done my best to compare the two versions, but I may have missed stuff. The document is around 200 pages long, and I’m not a lawyer. So don’t use this article in court. See it as a regular accessibility guy telling the world, in plain language, what he understands the updates to be.

If you find something I should add or change, get in touch and I’ll update the article: [email protected] or @hampelusken on Twitter.

Thanks EU

Even though this update wasn’t a game changer, we in the a11y (short for accessibility) community are thankful for all the great work the EU does to lift this important topic!

If you liked this article…

you should check out these ones as well:

The foot-in-door-somersault-strategy. Making accessibility laws your superpower

Hampus Sethfors — Mon, 04 Oct 2021 07:57:20 +0000

Accessibility is exciting, user-centered and should make you jump out of bed each workday morning with a proud grin on your face. Accessibility legislation is boring, text-centered and makes you snooze your alarm at least four times before getting up. But let’s see how to use the boring laws to get to do exciting, high impact work!

The cool kids on the block

You know all those movies where the main character first is a nerdy nobody and transforms into someone amazing or popular?

Sandy in Grease. Peter Parker in Spider Man. Harry Potter. You get the point!

That’s kind of how we feel like at the moment in the accessibility (a11y) community. A few years ago, only dorky public sector organisations wanted to hang out with us.

Suddenly, now we’re at the cool table with people from industries like gaming, e-commerce, fashion and entertainment!

And. It. Feels. Great!

We actually owe a lot of this new found coolness to something quite uncool: accessibility legislation.

Here in Europe at least, we’ve had some awesome new legislation the past few years, and more is on the way in the years to come.

This has really put accessibility on the radar. Suddenly we – the a11y nerds – are invited to red carpet events and everyone wants to talk to us. Thanks politicians!

However, when we start talking, most of the cool kids want to talk about how not to get in trouble, while we have much more interesting things to discuss!

The regular starting-in-the-wrong-end-strategy

Most organisations approach accessibility from a legal standpoint and begin asking things like:

How do we avoid getting sued?
What’s in the Web Content Accessibility Guidelines (WCAG) and what’s the lowest acceptable level we need to reach?
Can we get a list of issues so we quickly can fix them and get our “accessibility approved” stamp?
Is there a plugin we can buy that makes our site compliant with the law without us having to do anything?
How do we get a top score from automatic testing tools that we can brag about to top management?

This is a poor, counterproductive way to approach accessibility and inclusion.

Having people who are new to accessibility learn about it from the WCAG is like me teaching my baby to walk using my university physics book. All the theory is in there, but it’s a bit too much to digest at the moment.

We should aim to find another way to approach accessibility, and a great source of inspiration is looking at the methods of the user experience (UX) field. Both UX and a11y are about understanding the interaction between humans and technology. But even though there are some checklists and heuristics in the UX field, if you ever worked seriously with it, you know there’s a much bigger focus on methods instead of checklists. Methods to do user research, methods to test prototypes with users and so on.

So how do we get the accessibility field to shift focus from checklists to methods? Especially now when the laws point to standards – which are essentially fancy checklists with a bunch of different criteria.

The new foot-in-door-somersault-strategy

The key is actually to use the boring accessibility laws and regulations! They are a great way to get your foot in the door to the board room and management meetings. Where the allocation of resources like time and money are decided. Epic super crucial step!

However, once you’ve used legislation to get in there, it’s time for the foot-in-door-somersault-strategy!

Let’s walk you through a hypothetical scenario:

“Alright, you’ve convinced me” the CTO tells you. “We need to do this accessibility thing. How do we go about it?”

Your instinct might be to say: “Well, there’s an accessibility standard called the WCA…” But let’s stop you right there! It’s time to turn this conversation on its head. Take a deep breath, and get ready to somersault. Instead of talking about the exact requirements of the law, say something along the lines of:

“I’ll tell you exactly how!”

Pause for tension to build up.

“We just need to make some small adaptions to our current processes, making sure accessibility is baked into them.”

“That sounds both easier and cheaper than making a big, separate accessibility project!” the CTO exclaims. “Which processes and how?”

“Well, maybe most of them in the long term, but a good starting point is to include users with disabilities in our user tests. We’ll start with screen reader users, since a lot of legislation covers that target audience. We can also add accessibility training as part of our onboarding program, and workshop with some of our teams on how we can sprinkle some accessibility into our current working processes!”

“Hey, you really do seem to have this thing covered! But just to make sure, is this really what the law tells us we need to do?”

“By approaching accessibility this way, we’ll create a way of working where we comply with the law in a sustainable way. We’ll take small inclusive steps, everywhere, all the time. Continually improving instead of making this a one-time project. That also happens to be human-centered, more impactful, less expensive and really fun for our teams!”

Bam! Instead of going back to your computer and setting up a spreadsheet with each WCAG criteria, you’re set up to recruit people with disabilities to user testing, adapting training courses and booking workshops with your colleagues.

Somersault done and you’ve just changed the ball game completely!

Recap! The strategy in three simple steps

Use laws to get your foot in the door of important meetings
Somersault and talk about methods when you get asked how to comply with the laws
Smile as you work with accessibility in an exciting, high impact and user centered way!

Good luck, have fun!

Parent accessibility

Hampus Sethfors — Wed, 11 Nov 2020 14:55:09 +0000

I’m a dad since a few weeks back. This means I spend my days trying to keep a tiny, helpless lump of life alive. Scary stuff! I’ve also realised that this dad-thing comes with a ton of accessibility needs.

First a short future message to my kid…

Hi kiddo! If you find this post in ten years time or so, I’m sorry for the negative tone. I love you very much! But I’m tired and want to make a point about inclusion. Hope you understand!

Look! No hands!

The image above shows how my newborn master wants to be carried a large portion of the day.

Apart from losing access to one or both of my hands, this type of carrying around is very boring. The thing is – my newborn is very irrational. When carried, he rarely allows me to bend my legs 90 degrees and sit down. He wants me to continually walk around. So watching Netflix from my sofa is out of the question.

But my entertainment-craving brain has figured it out! I still have access to my voice. So I’ve activated the accessibility feature Voice Control on my iPhone. When my headphones are connected I can open my audio book or podcast app and press play, just using my voice. Even though I’m an atheist, I find myself praising the Lord for this accessibility feature primarily meant for people with permanent motor impairments.

Here’s a demo of this in action. First in an accessible app BookBeat, where buttons are properly named and I can start the book by saying “Tap listen”. Then in an inaccessible app, where buttons have strange names, and I need to say “Tap Mini Media Bar Play” to start the book.

Another handy voice interface is my home assistant, that I can ask to dim the lights and play lullabies on Spotify, to increase the chance of the baby finally falling asleep.

I also have this amazing thermos that can be operated one-handed, which gives me the superpower of filling up the kid’s bottle while holding him at the same time. Here’s a clip of me opening and closing it just using my left hand.

The lack of motor abilities for parents is a classic example of a situational disability, included in most introductions to accessibility, like Microsoft’s inclusive design toolkit:

But I’ve realised that becoming a parent means more impairments than just the access to my arms…

Other parent disabilities

1. Sleep deprivation

I was expecting to lower the number of hours of sleep each night. But I was not prepared for all the times I have to wake up during that period. Having a shorter, more fragmented sleep has lead to my brain feeling like an old, uncharged Nokia 3310 phone. Slower, lacking memory, low on energy and just simply unable to do a lot of the stuff most modern brains can.

That’s why parent brains need intuitive, lightweight interfaces with good error handling!

2. Swollen, numb hands

This one only affects me indirectly, but it’s very frustrating. My wife got this thing called Carpal Tunnel Syndrome – a super annoying, and common, condition that affects a lot of mothers during and after pregnancy.

She explains it like the numbness you get after sitting on your hand for a long period of time. Except she gets it after any use of her hands for a few seconds. So cooking, eating, changing diapers, typing, scrolling on a smartphone – all activities that lead to numb, swollen, pulsating and hurting hands. It’s been going on for over 10 months now, and my wife actually needs surgery to (hopefully) fix the issue.

Again, many accessibility features that support people with permanent motor impairments – like voice control, auto completing forms and similar – have been really helpful.

3. A ticking baby bomb

I didn’t know this, but babies can apparently switch from a state of deep, relaxed sleep to screaming like it’s the end of the world in less than a picosecond. That means, as a parent, I never know how much time I’ve got before I have to drop everything I’m doing and, instead, do everything in my might to comfort the kid.

So if I’m in the middle of something, like filling in some important form online, it’s super annoying if there’s a time limit that kicks me out if I’m idle for a few minutes. Which happens to be something that’s covered by the WCAG (Web content accessibility guidelines), because time limits don’t just hurt parents, but loads of people with permanent disabilities too.

4. Baby attention deficit

Harp seals take care of their offspring for 12 days, then they’re fully able to care for themselves. Sadly, human babies are not as low-maintenance. Human babies are completely helpless for what, 12 years or so? Maybe a bit less, but still far longer than 12 days. I’m so jealous!

This huge responsibility of keeping a helpless human alive and well leads to a big portion of my brain – that earlier could be used to solving all sorts of interesting, important problems – being blocked up with questions like:

Is the baby breathing?
When was the last time he pooped?
Why the h*ll can’t I find any of his 242 pacifiers?
Do I really need to shower again after him vomiting all over me or can I just pretend it didn’t happen?

So I spend my days with a large attention deficit and cognitive impairments, which is amplified in combination with point 1 and 3 above.

5. Hearing loss at night

I got a ton of advice before becoming a parent. The best and most genuine one was from a father of four:

Never wake a child that’s sleeping

So when the baby is sound asleep, and all I’ve got energy for is to crash in the sofa in front of Netflix, I’m super thankful for the closed captions that makes it possible to watch with little or no sound. Minimising – although by no way eliminating – the risk of point 3 going off.

Parent friendly design

To sum up: accessible design is parent friendly design.

So the next time you manage to make an accessibility improvement to your product, pause for a moment, stay completely silent and listen very carefully. You should hear millions of parents thanking you for your efforts.

If you liked this post, you might also enjoy these

I used switch control for a day

Hand tremors and the giant-button-problem

What is a screen reader?

Takeaway apps: Do they deliver accessibility?

Josefin Wessman — Thu, 23 Apr 2020 11:30:40 +0000

The world has changed due to Covid-19. A lot of people are in quarantine, voluntary or involuntary. Shops and restaurants are closed or have new rules to restrict crowding. One way to support local restaurants is to buy prepared meals in takeaway apps. But, how are these takeaway apps in terms of accessibility?

Our 5 top tips for more accessible takeaway apps!

The overall idea of a digital service to deliver food to your house is very inclusive, and at Axess Lab we love it! But for the idea to work it also has to be implemented in an accessible way. So we decided to pick three of the larger takeaway apps in Sweden: UberEats, Foodora and Karma and test them out.

From that experience, we give our tips to these types of app services to help them become more accessible:

Tip 1 of 5: Make sure color contrast are good

A common issue in these apps is that text and background colors are too similar in contrast. According to the Web Content Accessibility Guidelines the ratio between these color contrasts must be above 4.5:1. Which they often are not in these apps.

Poor color contrasts are an issue for users with low vision and users that look at the screen in harsh lighting conditions. This is often the case when you use mobile devices, especially outdoors.

Here are some examples of text with too low contrasts that we found in the apps:

Make sure to check all your contrast values and aim to be well over the limit of 4.5:1. Especially since these are apps that are being viewed on small screens. If you need testing tools, check out these Top seven free color contrast checkers & analyzers.

Tip 2 of 5: Combine icons with descriptions

The screen space is smaller in apps than on desktop. Therefore some functionality is only presented with an icon.Icons are great in combination with text descriptions but on their own they can be confusing and users often find it difficult to understand their meaning.

For instance in the header of one app we tested we found these icons that represent two buttons. But, what do the two icons mean?

The user has to explore in order to understand the meaning of them. Keep in mind that some users are careful in their approach to technology and don’t want to click on things to find out what they do. The icon to the right in the image above is the checkout where there currently are two meals. The icon to the left looks like a user profile but opened some kind of menu with random actions like “settings”, “contact us” and “invite your friends”.

Don’t make the users guess what different objects are for, explain it in short descriptions. If functionality is difficult to describe, it might be a sign that you should organize the content in a more logical way.

If you want to learn more about icons and proper descriptions to them, check out our post: How icons are ruining interfaces.

Tip 3 of 5: Make sure your buttons and links work with screen readers

The apps we tested generally did not work well with screen readers. A screen reader is an assistive technology, primarily used by people with vision impairments. It converts text, buttons, images and other screen elements into speech or braille.

In these apps, buttons and links often lack descriptions in the code for the screen readers. In the example below, the screen reader was unable to find the register button. So the user we tested this with couldn’t even enter the app and as a consequence couldn’t order any food.

In other cases, the buttons leading to the checkout are impossible to understand. In the example below, the button leading to the order checkout had “view your cart” as a visual label but was read by the screen reader as the less helpful: “button”.

In some cases there where descriptions read by screen readers, but they were not very understandable. Such as this icon where the screen reader said “Tablist over icons”:

Or this icon that had the description ”Navdown”:

This video clip shows a page with several buttons and objects that are not properly described, in Swedish:

So, make sure to test the app with a screen reader during development. Today, screen readers are built into smartphones so everyone can test it. If you’d like training from our colleague who’s a screen reader user himself, just let us know at [email protected].

Besides testing it yourself, make sure to test the app with real screen reader users to know what to prioritize. The real user’s opinion of the overall experience is what you should to focus on, after all.

As a good example, one of the apps had implemented helpful descriptions to screen readers on objects that visually was just an icon. For example the dollar sign in the following image was described by “Price: average or below”.

This video clip shows how it is read by a screen reader, in Swedish:

Tip 4 of 5: Reduce content

For many users, large amounts of information, both in terms of text and non-text content, can be a deal-breaker. So it is always a good idea to minimize content and focus on what is most valuable. Clean interfaces are especially important for users with cognitive disabilities.

In some of these apps we found that there was too much content. That makes it difficult to distinguish what information is primary. Especially for users that have difficulties with maintaining focus or who finds it energy-draining to read.

Here is one example of a checkout that was cluttered with information:

It has small text and lack clear headings and spacing in the presentation. Some information could benefit to be placed in later stages so the user can complete the checkout step by step. The payment method for example is not really relevant until the user decides to order.

Tip 5 of 5: Test with users!

In order to achieve an inclusive design it is fundamental to test with real users. Real users have a wide range of abilities. Focus on users that have the most difficulty in certain areas to find improvements that are beneficial to all users. For example, tests with users with cognitive disabilities to understand UX issues in terms of cognitive load.

Test the technical aspect with users that use different interaction methods, such as screen reader or voice input.

When testing with users the goal should be to find out if they can complete the process. Not just certain steps or objects. The user must be able to complete the whole process to be able to place an order.

Need help with user testing? Let us know, we do a lot of user testing! Also available as a remote service, during corona-times.

You can do it!

In conclusion, take small steps in several areas towards the goal of including more users. You can accomplish a lot by taking an interest in the users’ needs and by learning what accessibility really is. Let us know if we can help you in your mission!

Thank you for reading this blog post, take care, especially these days.

Neumorphism – the accessible and inclusive way

Hampus Sethfors — Thu, 09 Apr 2020 08:38:51 +0000

There’s a new kid in design town: neumorphism. It’s predicted to become a big design trend ahead. Let’s look at what neumorphism is, the potential accessibility pitfalls and how to use it responsibly.

Neu…what now?

Neumorphism is a fancy word for a user interface design trend. It derives its name from skeumorphism – a way of integrating real-world objects into user interface design. The classic example is the trash can. Neumorphism is basically “New Skeumorphism”, so skeumorphism with a modern twist. It’s got a bit of a “soft” look and feel that reminds a bit of flat design. For a good in-depth article on neumorphism, check out: Neumorphism in user interfaces (uxdesign.cc)

Anyway, it’s causing quite a hype in the design community at the moment, which was sparked by a design created by Alexander Plyuto, posted on November 5th, 2019 on the design community Dribbble:

This design went viral, with over 220 000 views and 4000 likes. It also set off a whole bunch of designers who had a shot at the new design technique. Here are some of the most popular designs to date on Dribbble:

You can find a lot of more designs on Dribbble with the tag Neumorphism.

Many people are pretty excited, predicting neumorphism to be a big trend ahead.

https://twitter.com/LudusEstArs/status/1215243113247232001?s=20

https://twitter.com/webwide_io/status/1208763520424304643?s=20

Gary Simon, who has half a million subscribers to his Youtube channel DesignCourse, made a tutorial video named Could this be the BIGGEST UI Design Trend of 2020? #Neumorphism.

Could this be the BIGGEST UI Design Trend of 2020? #Neumorphism – https://t.co/FvYFwMTodA pic.twitter.com/tZMTzloEnO

— Gary Simon (@designcoursecom) December 23, 2019

The great thing about Gary Simon is that, even though he’s not an accessibility expert, he always has accessibility in mind and regularly talks about the importance of inclusive design. Like in the video above, where he mentions the importance of color contrasts. Which leads us perfectly to…

The potential problems with neumorphism

The main problem with this trend are the poor contrasts in almost every design out there. As you probably noted when scrolling through the neumorphism designs above, most of their color schemes are very light grey on white. Many of the interface elements are barely possible to see, even if you have perfect vision. Now imagine what this does for someone using their device in sunlight or users with vision impairments.

Let’s use the disability simulator Funkify – a browser extension that we are proud to have been a part of creating – to view the original design through a low vision filter:

Even though you can still glance much of the text and icons, it’s still quite frustrating to barely be able to identify any of the interface elements, like buttons, cards and charts.

Neumorphism is often referred to as “soft UI (user interface)”. Looking through the designs on Dribbble, it would almost be better to call it “ghost UI”.

Apart from the contrasts, two other accessibility issues are:

Lack of labels.
Many of the designers seem to remove labels for icons when having a go at neumorphism. Maybe because they’re doing all they can to create a soft, stripped off interface. Icons without labels is something that hurts both the accessibility and usability of interfaces, which we’ve written about earlier in How icons are ruining interfaces.
Understanding what’s clickable.
Users should not need to guess what is clickable and what is not. This is extra important for many elderly users, who will often avoid clicking things that they are not totally sure are clickable. This is the same problem flat-design battles a lot.

Get out of your bubble

Yesterday, an 80-year-old man told me he was stressed. He’d been trying to understand how to pay for parking his car on the street outside here in Stockholm, Sweden. He tried really hard but could not read the text on the parking machine interface, not even with his reading glasses on. He ended up getting a 750 kr (80 dollars) fine.

I believe I’m speaking for most people in this world when I say: we don’t need less legible interfaces. We should go in the other direction.

Judging by the designs on Dribbble, the world’s top designers don’t agree with me. So it’s time to get out of the designer bubble and realize a few important facts.

Most people in this world are not young, tech-savvy with perfect vision. Most people don’t experience your interface on 32-inch ultra HD monitors. And you might want to sit down for this last one: most people don’t even care much about how your app looks.

They just want to get something done. And to do that, they need to see what’s on the screen. Even if they’re out in the sun. Or use a small, old phone. Or have low vision.

Is accessible Neumorphism possible?

Definitely! There’s nothing in neumorphism that forces designers to use light grey on white all over their designs. Or that prohibits text labels by icons.

In fact, many of the dark mode designs on Dribble are much better (although not perfect), like the dark version in this one.

Here’s another dark design where contrasts are better.

And I even found a bright with okay contrasts – although the borders around the buttons could be made clearer.

So if you’d like to design accessible neumorphism, make sure to comply with the Web Content Accessibility Guidelines (WCAG 2.1) criteria on contrasts. Specifically this one: 1.4.11 Non-text contrast. It basically requires icons, borders and other interface elements to have contrasts of at least 3:0:1. It’s a bit lower than the requirement for text content, which needs a contrast ratio of at least 4.5:1.

Here are some great free tools you can use to measure contrasts: Top seven free color contrast checkers.

In addition to sufficient contrasts, make sure that your design makes it clear what’s clickable and that you label your icons. Then you’re all set!

Wrapping up

The overall goal of creating a soft and clean interface is super positive from an accessibility point of view. Especially when you consider all the users with cognitive impairments who are extra sensitive to cluttered designs. This could be users who are stressed, tired, are on the autism spectrum and so on.

To go all the way, and make neumorphism really inclusive, make sure that:

Contrasts of text is at least 4.5:1
Contrasts of button borders, icons and other interface elements is at least 3.0:1
It’s easy to understand what’s clickable
Icons have text labels.

Then you’ll have done your part to steer this design trend in the right direction!

If you liked this article…

Becoming a climate positive company

Joel Holmberg — Thu, 16 Jan 2020 16:21:19 +0000

At Axess Lab we strive to make the world more accessible for people with disabilities. But what’s the point of an accessible world if we can’t survive in it?

2019 was the year where 16 year old Greta Thunberg helped make the environment the number one issue on peoples mind. The media primarily focused on countries and their politicians. Conscious individuals tried to do their part in reducing emissions by flying less, eating less meat etc. Here in Sweden “flight shame” and “shop shame” become new words. But the largest environment impact come from companies, and as a company we have an important part to play in creating a sustainable world!

Company footprint

All businesses have an impact on our environment. It’s easy to see that if a company produces and sells goods they use raw materials and they use energy to transform them into products. You may even see the emissions with your own eyes coming from industrial chimneys and factories. But for companies selling services, or software companies like ourselves it can be more difficult to see where the environmental impact comes from.

We decided to learn what it would take for us to become a climate positive software/consultancy company, and we want to share it in this short article!

To become climate positive we needed to answer a few questions:

1. What is our organization’s yearly emissions – our ecological footprint?
2. What actions can we take to reduce this footprint?
3. How can we compensate for the remaining emissions?

As a small company with 10 employees we cannot spend a lot of time and money figuring this out though, so here is how we did it the “quick-and-dirty…hrm…quick-and-clean” way.

Calculating ecological footprints

Luckily there are simple calculators online that can give you a rough estimate of the yearly emissions of your organization. We used one from “Zeromission”:

Zeromission footprint calculator

They have average values for companies that you may use if you don’t know your exact numbers, and you get your emissions broken down into it’s major components:

Taking actions

Looking at our breakdown we see that “Mobility” is by far our largest culprit, but it may be different for you. Here are steps we have already taken that may affect our results:

We only serve vegetarian food at all our events.
We all happen to use public transportation to get to work.
We do most of our meetings digitally and rarely travel to see clients abroad.

These steps may or may not be possible for you. Even considering these steps, “Mobility” is still a large part of our emissions. We sat down and discussed the numbers, and here are steps we consider taking to reduce them even further:

Use long distance train instead of flying when possible.
Give employees subsidized public transport cards to avoid traveling by car.
Invest in better software and hardware for digital meetings

Compensating for damage done

Now that we knew what our footprint was we wanted to find the most effective way to contribute financially to compensate for this. Luckily there is a movement called “Effective Altruism” and a book called “Doing good better” that explains it well.

We found an organization called “Cool Earth” that works to prevent deforestation of different rain forests, and it is described in this article about Cool Earth on givingwhatwecan.org

Cool Earth is the most cost-effective charity we have identified to date which works on mitigating climate change through direct action…We estimate that Cool Earth is able to reduce emissions by 1 tonne of CO2-equivalent for every $1.34 donated, for directly protected forest specifically (although this figure may be as low as $0.65). If indirectly shielded forest is also included, this drops to $0.38 per tonne of CO2-equivalent. This is 25 times less expensive than most carbon offset providers, which typically reduce emissions by 1 tonne for roughly every $10 spent.

We also found the Rainforest Coalition, a non profit organization that works on a political level. They were deemed very “high impact per dollar” according to this article on “Founders pledge” about climate change.

According to our cost-effectiveness model, a donation to CfRN will avert a tonne of CO2e for $0.12, with a plausible range of $0.02 – $0.72. Equivalently, a $100 donation to CfRN would avert ~857 tonnes of CO2e with a range of ~138 tonnes to ~4,600 tonnes. These estimates are highly uncertain. For context, the average person in the UK causes the emission of around 10 tonnes of CO2 per year, and it is generally considered to be difficult to avert a tonne of CO2e for less than $2.

We now calculated what we needed to donate using the “worst estimates” of impact per dollar to be on the sure side to compensate for our emissions. The number was still relatively low, maybe because we are digital accessibility consultants and as such we don’t have factories or production lines.

One part of working at Axess Lab is that all employees get to decide on how to use any profits each year. This year, based on the discussions above, we decided to use a part of the profits to donate equal amounts to the above mentioned organizations. Enough to put us on the “climate positive” side.

This is in no way a guarantee that we now have a positive impact on the environment. Estimates may be wrong, and most clever people recommend reducing our impact before compensating for it. But with the limited time and resources a small company has, this is something we can actually do right now!

The challenge

How much would it cost your company to become climate positive? What does your company already do to reduce your ecological footprint? What steps are you taking this year?

We hereby challenge other companies to calculate their footprint and let the world know what they are doing to reduce their impact, sharing it using the hashtag #climatepositive

#climatepositive

Thanks for reading, even if this article has little to do with digital accessibility! If you’re looking for a tech job in Stockholm, and you agree with our goal of holistic impact, please get in touch at [email protected].

If you liked this article…

…We don’t have any other similar articles :O Here are some about digital accessibility instead:

What is a screen reader?

Daniel Göransson — Fri, 15 Nov 2019 15:27:56 +0000

A screen reader is an assistive technology, primarily used by people with vision impairments. It converts text, buttons, images and other screen elements into speech or braille. Let’s go through what a screen reader is, how it works and see blind people in action!

I use a screen reader on my mobile device every day, so it’s a technology I’m very familiar with. But I know it’s new and strange to most people. So let’s go through the basics!

Screen readers are mainly used by people with no or limited vision to get information in a way accessible to them: braille, speech or both.

The best way to understand is to watch it in action. So here’s Marc Sutton showing a desktop screen reader.

At the end of this article, we’ve added a few more videos with screen reader users, showcasing different screen readers on different devices. So scroll down and check them out if you’d like!

Fasten your seatbelt – they are quick!

The first thing most people comment on when meeting a screen reader user is the speed at which the synthetic voice speaks. The Finnish developer Tuukka Ojala has his set at 450 words per minute. Here’s a 5 second audio clip of what that sounds like:

https://axesslab.com/wp-content/uploads/2019/11/450-wpm-online-audio-converter.com_.mp3

Pretty awesome huh! For reference, most sighted people read at about 150 words per minute, so he’s able to read at 3 times that speed. You should check out Tuukkas own article on this topic, where you’ll also find a longer audio clip of the screen reader speaking at lightning speed:

Software development at 450 words per minute

How are screen readers used?

One thing that most people I meet haven’t thought about is that many screen reader users, like myself, have some remaining vision. So we often use a screen reader in combination with sight. For instance, I’ll sometimes rely on my sight for general navigation using a screen magnifier. Then I’ll turn on the screen reader when reading longer texts. On smaller devices I’ll rely more on the screen reader and on larger devices more on screen magnification.

A great resource to understand screen reader users better is the Screen Reader User Survey by WebAIM, which over a thousand people respond to about once every other year. The survey goes through things like:

Screen readers most commonly used
Web browsers
Operating systems
Reasons for inaccessibility

And much more! So head on over to that site and learn all you need to know. But below is a summary of how desktop and mobile screen readers are used.

Desktop screen readers

On a desktop, users will usually navigate using their keyboard. Either stepping from object to object or by jumping between different types of components, like headings, forms, links or landmarks.

Thanks to the awesome Screen Reader User Survey mentioned above, we know that most desktop screen reader users navigate between headings when they arrive at a new page. For instance by pressing the h-key in JAWS – one of the most used desktop screen readers.

There are many keyboard shortcuts for screen readers that lets you do everything from searching content to identifying the font of the text you currently are reading. Here is a list of around 100 shortcuts for the JAWS screen reader.

Mobile screen readers

Even though it’s possible, most screen reader users don’t connect a keyboard to their mobile devices. Instead, we navigate by moving our finger on the screen in one of two ways:

Touch navigation: dragging our finger across the screen, and getting what’s under our finger read to us.
Swipe navigation: Swiping left and right to move to the next or previous item. Kind of like using the tab-key on a computer keyboard.

It’s very common for people to switch between these modes of navigation. I myself prefer using the touch method most of the time, but then I’ll switch to swipe navigation if I suspect I’m missing something on the screen. Swiping is a more thorough way of navigating, since it sets the focus on every item, even on the smallest of click targets. But it usually takes a bit more time than the touch method.

A super handy feature for people who know braille is the braille keyboard in iOS devices. Here’s a video showing how that can be used.

Try it yourself

A great way to learn about screen readers is to try one yourself! It takes a bit of training though. Rob Dodson has made a few great 7-12 minute tutorials for Mac, Windows, iPhone and Android!

Let’s start with the iPhone!

Moving on to Talkback for Android.

VoiceOver on MacBooks.

Finally NVDA for Windows!

Creating screen reader accessible interfaces is a lot about coding correctly. However, you also need to think about making it intuitive, usable and easy to navigate. These ”softer” factors is something many people forget about. But only focusing on the technical aspects will not by default make your interface accessible to screen reader users.

So let’s start with some usability tips!

Make touch targets large

Large touch targets are crucial for people who navigate on mobile devices using the touch method that we explained about earlier. If touch targets are too small, there is a big risk of the user missing them.

A lot of screen reader users get stuck trying to get through what feels like a million links before the main content of a page. These links are usually in menus, headers and social media share functions. Keep these to as few as possible to enhance the user experience of a screen reader user – and everyone else!

Include skip links

Even if you limit the number of links in the site banner, it can be nice to provide a skip link. A skip link is a way for all keyboard users – including screen reader users – to jump straight to important parts of a web page.

Skip links should be the first focusable elements on a page, and can be visually hidden but shown on focus; in other words: show when the user tabs to them. Here’s an article we wrote all about skip links and what could go wrong with them.

Keep paragraphs short

Short paragraphs make it easier for a screen reader user to go back and read something on a page again. The most common way to read with a screen reader is one paragraph at a time. So huge paragraphs at a time will be harder to skim through.

Use a lot of headings and subheadings

While on the topic of skim reading, it’s important to divide content into many headings and subheadings. Screen reader users will often jump from heading to heading. In fact, the majority of the respondents to WEB Aim’s Screen Reader User Survey say that jumping between headings is their primary way to navigate when they encounter lengthy web pages. If there are too few headings this method will not be effective.

Short paragraphs and a good use of headings and subheadings will also help many people with reading impairments like dyslexia.

Of course, there are more things to think about when it comes to screen readers and usability, but this is enough for this introductory article. Let’s move on to the more technical arts!

Code headings correctly

For screen reader users to be able to jump between headings, the headings must be coded as h-elements according to the HTML-specifications. That is:

,

and so on.

If you’re an editor, the thing to remember is to choose headings from the dropdown in your content editor. Do not create headings by styling normal text, like increasing the font size and making it bold.

Also, make sure the heading structure is correct. We see mistakes with this all the time.

A screen reader will tell the user what level the heading is at. So don’t follow a heading on level 1 (h1) with a heading on level 3 (h3). It can confuse the users: “Did I miss a heading on level 2?”. And don’t make all your headings on the same level.

Think of it as an essay you’re writing in Microsoft Word. If you’d make a table of contents, you need to make sure the heading structure is correct. The same goes for webpages.

Give images alt-texts

When coming across an image, the screen reader will read the alt-text of that image. This is supposed to be a description of the image that editors or developers have added. Sadly, many don’t write alt-texts or add keywords to the alt-texts hoping to increase their search engine optimization, which becomes an accessibility problem.

We’ve got an article all about alt-texts you should check out if you’re interested in this topic:

Alt-texts: The ultimate guide

Careful with modals

It’s almost frightening how many times I’ve seen modal windows exclude screen reader users from interfaces. What usually happens is that a modal window opens up but doesn’t receive focus, so the screen reader user is trapped behind it and can’t find it. These modal windows are often crucial confirmation dialogues, asking things like “Are you sure you want to go through with this purchase?”. So not being able to access those components can completely shut users out.

Luckily, there are great resources out there to help you build accessible modals. Here are two:

Accessible Modal Dialogs – A11ycast (YouTube)

Creating an accessible modal dialog (bitsofcode.de)

CAPTCHA’s

Don’t use them. Just don’t.

Why? We have dedicated a whole article to that topic: Captchas suck.

Follow coding standards

A really great way to make your interface accessible is to use standard components and follow coding standards. For instance, if you make a checkbox, use the input element with type checkbox, just like the HTML-standard says you should.

It seems really straight forward, but people create custom components like checkboxes all the time. If you create a custom component – for instance by styling a div and adding an onClick-listener with javascript – you don’t get accessibility built-in. You can add it yourself, but it’s often tedious and you need to know what you’re doing. So just use standard components as much as possible.

As a developer, it would be unthinkable to release a website without first looking at it in a browser. Take this notion and apply it to screen readers as well. Learn the basics of screen reader usage, for example by following the video tutorials earlier in this article. And make a habit of always testing your product with a screen reader before releasing it.

Last but not least, the best way to learn is from screen reader users themselves. So here we have collected a few great videos for you to enjoy.

Gayle Yarnall showing how braille displays work.

Saqib Shaikh shows us how he codes using Visual Studio and a screen reader.

Molly Burke showing all her Apple products with the screen reader VoiceOver:

For a concrete example of how we help children with visual impairments learn the keyboard, see the project Typing in the dark.

Thanks for reading, and if you need any support on this topic, we do training, workshops and other accessibility services that can help you take an inclusive leap forward! Get in touch at [email protected].

If you liked this article…

Videos of people with disabilities using tech

Hampus Sethfors — Fri, 08 Nov 2019 15:51:16 +0000

There is no better way to understand the importance of accessibility and inclusive design than learning from actual users with disabilities. Here’s a collection of our favorite YouTube videos where people showcase how they use assistive technologies like screen readers, eye tracking, zoom and switches.

We’ll start off with former BMX star Stephen Murray showing how he controls the computer to run his business just by using his eyes.

Brad from All Access Life also uses an eye tracker. Here he is playing World of Warcraft.

One of the most expensive things you can do in marketing is run a commercial during the Super Bowl. Big thumbs up for Microsoft on their 2019 commercial, showing kids with motor impairments using the adaptive controller for Xbox.

On the topic of the adaptive controller, here’s comedian Zach Anner using it to totally humiliate his buddy while gaming.

One last gaming video! Here’s Sven who plays Street Fighter at professional level without sight. Cred to the audio designers behind the game who have made this possible in the Street Fighter series since the early 1990’s.

Molly Burke, who at the moment has almost 2 million subscribers on YouTube, made a few great videos on using technology with her screen reader.

Here’s Molly showing a frustrating shopping experience trying to purchase a pair of Converse shoes online.

Here’s James Rath explaining how he uses a computer with zoom in combination with synthetic speech.

Tommy Edison shows an app that helps him and other people with visual impairments identify objects like currency, sock colors and tin cans.

One last video on visual impairments. This is Saqib Shaikh, a blind developer showing how he uses a screen reader to code.

This is a longer lecture, where Emily Shea explains how she codes Perl using only her voice due to her Repetitive Strain Injury. You should definitely watch the first part and where she starts coding.

Apple has a nice video series of short clips with assistive technology users. Here’s one video in that series on motor impairments.

Want to see more similar videos, here’s a playlist with all the videos in the Apple Designed for Everyone series.

Todd from the previous clip was invited to an Apple event to demonstrate in more detail how he navigates using switches with his tongue.

Last but not least, here’s another switch control user, Chrisopher Hills, has some great videos where he demonstrates how he uses it in his work as a video editor.

We made a playlist

You can find all the videos in this post in a single YouTube playlist. How convenient!

YouTube playlist: People with disabilities using technology

Do you know something we don’t?

We’d love to hear from you if you know of other videos with assistive tech users showcasing how they use their technology. Send them our way on Twitter @AxessLab or to [email protected] and we might add them to this article and the playlist!

If you want this kind of perspective on your product, hire a digital accessibility expert experienced with assistive tech.

If you liked this article…

I used switch control for a day

Hampus Sethfors — Fri, 01 Nov 2019 09:43:14 +0000

Stephen Hawking used something called a switch to communicate, author books and surf the web. Just like Stephen, millions of people around the world with motor impairments use switches to access technology. Sadly, the awareness and knowledge about this assistive technology is generally low. So it’s time to switch the spotlight on switch users!

Short note before we start: This article was first written for the great initiative 24 Accessibility – an accessibility article each day in December before Christmas.

Switches can look very different, but in the image above I’m holding a classic one – basically, a big button that you press to navigate your computer, smartphone or tablet.

I’m an accessibility nerd. I organize accessibility meetups, run a company focused on accessibility (Axess Lab), can recite the accessibility guidelines in my sleep and own 6 different accessibility T-shirts. But even though I live and breathe accessibility, I realize I have a very limited knowledge about switches.

I know way more about screen readers than I do about switches. When you think about it, that’s really strange. Looking at pure numbers, there are far more people around the world who have motor impairments like Cerebral Palsy, ALS and Parkinson’s disease than who are blind.

So why do we hear and read so little about switch accessibility? I don’t know! But whatever the reason, I feel it’s time to switch it up! Time to learn more about this assistive technology and what we as developers and designers can do to make our technology switch accessible.

So I used a switch control for a day and I’d like to share the insights it gave me with you!

My setup

I used a classic type of switch, basically a big colored button. It’s the one I’m looking suspiciously at in the first image of this article. This type of switch can be placed in the users’ hands, by their head, elbows, feet or wherever they feel most comfortable with it. I held my switch in my hands.

I should mention that there are many other types of switches:

Sip-and-puff switches. They are “clicked” by sipping and puffing into a straw-like-component.
Sensory switches. Stephen Hawking had a sensor attached to his cheek that he activated by a small movement with his cheek up or down.
Camera switches. On iOS products, you can activate a switch by tilting your head to the side.

There are many other variations of switches, but they all work similarly to the original button-switch, so I used a button.

It should also be mentioned that I used a single switch. You can set up multiple switches for different actions – for instance, you could assign one to take you to the home screen, one to move the cursor forward (like pressing the tab-key on a keyboard) and one to click.

However, it is possible to use a single switch to fully interact with technology. Which I think is pretty cool so I wanted to try that! Also, I know of people who use a single-switch-setup, for instance, the YouTuber Christopher Hills, whose channel I strongly recommend you check out.

I used the built-in setting Switch Control in iOS products — on an iPhone 7, MacBook and Apple TV. It is, of course, possible to use switches on a PC or Android device, but I felt it would be enough of a challenge for me to try it out on one operating system this time.

Insights

Let me share the insights I got from my day of switch usage with you.

Technology is awesome

Even though I experienced a few obstacles along the way which I’ll go through below, the main thing that stuck with me is how awesome this technology is. All you need is control of a tiny part of your body so you can activate a switch, and suddenly the whole world opens up through technology. You can surf online, pay bills, order pizza, communicate with friends and unlock doors, all through a single switch.

Imagine the difference in independence and quality of life this means for people with severe motor impairments living today compared to — say — 40 years ago.

Even though the technology is awesome, there are still things that could improve a lot to give a more equal access and experience of technology out there.

Typing is slow

Typing with switch control is much, much slower than I’m used to. Here’s a video where I type “Hello World.” If you don’t want to watch the video I describe what happens in it in the text below the video player.

https://axesslab.com/wp-content/uploads/2019/02/hello-world-typing.mp4

Video description: A focus indicator jumps across the keyboard and you need to wait until it’s at the letter you want to type. It takes me over a minute to write “Hello World.”

After having practiced a fair bit with typing, I measured how quickly I could type a happy birthday text to my mom. As a comparison, I first typed it with my fingers like I normally do, then a second time with switch control activated. The message was 18 words long. Here’s the result:

Without switch control: 43 seconds
With switch control: 8 mins 52 seconds (or 532 seconds)

So it took me over 12 times as long to type with switch control activated, even though I made very few mistakes and used word suggestions as often as possible.

Calculating my typing speed, I was able to type just over 2 words per minute. 2.2 to be exact. As a reference, this article is around 2700 words long, so at 2.2 words per minute, it would take me 20 hours 27 minutes to write it.

I asked a colleague of mine to try out typing as well. She had not had the same amount of practice and was able to type at about half my speed, around 1 word per minute.

These speeds are in line with sources on Stephen Hawking’s typing speed, which state Hawking could type around 1 word per minute before adding word predictions which doubled his speed.

The slow typing speed came with a couple of insights for me:

Word predictions when typing is super useful. But word prediction could improve a lot. For instance, I wrote “switch control” twice in one sentence, but my onscreen keyboard didn’t suggest it to me any quicker the second time around.
Autocomplete in search fields is very helpful.
Time limits – getting kicked out of a form if you don’t complete it in a set amount of time – is a severe accessibility barrier.
Forms that prefill automatically save tons of time and energy.
Dictation — speaking your message — would make typing much quicker. However, many people with motor impairments also have a speech impairment that makes dictation impossible. So I decided not to use dictation in my one-day-experiment.

Scrolling is sometimes painfully slow

I think everyone would agree that scrolling is something you do quite often, especially on smaller devices like smartphones.

So it surprised me that it was painfully slow to scroll on an iPhone. Let me break down what switch users have to do to scroll:

2 quick clicks to bring up an interaction menu
1 click to select the row with scroll button
1 click to select the scroll button
1 click to select the row with scroll down button
1 click to select the scroll down button
1 click to go back to the main menu
1 click to close the interaction menu

So in total 8 clicks to scroll down. Here’s a short video that shows the interaction described above when I scroll on Twitter.

https://axesslab.com/wp-content/uploads/2019/02/scroll-twitter.mp4

Video description: Scrolling one screen on Twitter with switch control. 20 seconds was needed to bring up, navigate and close the interaction menu.

On Android, the scroll gesture seems to be much more effective, as illustrated in this YouTube clip: A11ycast with Rob Dodson – Switch Device (Youtube). Here it just takes two clicks to scroll: one when the whole page is selected, another one when the scroll down button is selected.

What about on Mac? Well, it was much quicker to select the scroll gesture than on an iPhone, but the page scrolled so little with each click that it felt like a joke. Here’s a video that shows this in action. Each click of the scroll gesture scrolls the page approximately 5% down.

https://axesslab.com/wp-content/uploads/2019/02/scroll-mac.mp4

Video description: Using switch control to scroll a webpage on a Mac. A focus indicator automatically travels quickly across an interactive menu at the bottom of the screen, 7 steps before it reaches the scroll button. After pressing it, the page just scrolls down slightly, and the cursor starts from the beginning of the interactive menu again.

I later realized that I could tap multiple times on the scroll gesture, which helped speed things up a lot. But it would be much smoother if one click on the gesture started scrolling the page down and the next click stopped it.

On Apple TV scrolling was much easier. Here’s a video of that in action.

https://axesslab.com/wp-content/uploads/2019/02/scroll-apple-tv.mp4

Video description: A scroll bar shows up on the side of the page in the YouTube app on a TV. I just select that to scroll down and the focus stays in the scrollbar until I decide to leave it. Then I enter a horizontal scroll instead, which works in the same way. Finally, I activate the video I want to view.

All in all, I think that teams designing switch interfaces for operating systems should focus a lot on improving scrolling. There’s a lot of room for improvement of the user experience in this aspect.

For everyone who builds websites and apps: what we can do is make sure important interactive elements and information are at the top of the page. The classic principle of “above the fold” (viewable on the screen without scrolling) is very relevant for switch control users. Scrolling requires more time and energy for switch users. In the words of usability gurus Jakob Nielsen and Don Norman: the interaction cost of scrolling is high for switch users.

Mistakes increase

I found myself making mistakes a lot. It was mostly due to me pressing the switch too late, resulting in me activating something I didn’t want to click. The number of misclicks would probably decrease with practice. However, with more practice, I’m pretty sure I would increase the speed of the cursor that moves across the screen, and higher speed would mean a bigger risk of mistakes. So a well-designed error handling is really important.

Twitter had a feature I really appreciated. I was replying to a tweet when I accidentally pressed the back button. I had spent a good five minutes writing the reply so I got quite frustrated. But luckily, Twitter had saved my work-in-progress so when I clicked the reply button again I could continue from where I was when the mistake happened. Great stuff!

Notifications steal focus, literally

Whenever I received a notification on my phone, focus switched from where I was to the notification. That might sound like a good feature, making it easy to quickly open the notification.

However, I found it quite frustrating, especially when I was typing something. It takes a while to get the cursor to select the correct key on the onscreen keyboard, and if I received a notification while typing I had to start all over again.

Here’s a video showing this in action:

https://axesslab.com/wp-content/uploads/2019/02/annoying-notification-.mp4

Video description: I’m writing a Tweet on my phone and have waited 7 seconds for the cursor to get to the “m” when I receive a notification. Focus jumps away from the keyboard, up to the notification at the top of the page and I have to start over typing.

I – like most people – get quite a lot of notifications from email, Slack, Facebook, news apps and more, so this disruption while typing happened frequently.

Here are two different ways I think Apple could go about to improve the user experience of notifications when switch control is activated:

Solution 1: If the user has focus on the keyboard, don’t switch focus to notifications when they appear. Instead, let the user finish typing and go to the notification center when they’re done.

Or even better:

Solution 2: Delay showing notifications until the user is done typing. Then they get the chance of both finishing what they’re writing and click the notification. Of course, there would have to be some time limit in place, so notifications show if the user has a keyboard open for long periods of time.

Item mode versus point mode

There are two main modes in switch control on iOS devices, and I’m pretty sure it’s something equivalent on Android:

Item mode – the cursor jumps from object to object on the screen. Kind of like pressing the tab-key over and over again on your keyboard. Although it’s a bit smarter than the tab key since it groups elements together to allow users to be more efficient.
Point mode – like a virtual mouse pointer. First, a vertical line swipes from left to right on the screen, you activate your switch to stop the line. Then a horizontal line swipes from top to bottom and you activate your switch to stop that one too. Where the two lines intersect, a click is triggered.

Here’s a video that first shows me using item mode to navigate BBC’s website. I then switch over to point mode, so you can see the difference.

https://axesslab.com/wp-content/uploads/2019/02/object-vs-point-mode.mp4

Video description: First a focus indicator jumps across different objects on the website. Since there are quite a lot of links and buttons, it takes a long time to get through everything. I then bring up a menu and switch to point mode. I first stop a vertical line, then a horizontal line, where I want to click. This is much faster than the first item mode.

I found item mode to be easier and more efficient when navigating apps and my phone interface – like the home screen, settings and so on. However, on websites, it was hard knowing which order things would receive focus in, and strange grouping of objects often confused me. So I found that changing to point mode when surfing the web made things much easier.

Surfing the web in point mode is something that YouTuber Christopher Hills explains that he also does, for the same reasons.

Websites could make item mode navigation simpler by having cleaner interfaces with less clickable things on each view and by making sure the order that objects receive focus is logical. Then switch users might not have to change to point mode, which would be nice since it takes some time to switch between the modes.

I struggled with connection issues

Finally, I want to say something about connection issues. For some reason, I had a hard time connecting the switch to my devices. Quite a few times, it appeared in the Bluetooth menu but wouldn’t connect. I’ve had this issue earlier too, and sometimes it has been because I’ve forgotten to unpair it from another device, but this time I swear it was just messing with me for the fun of it!

I had to wait for the switch to drain its battery and restart since there’s no way to restart it manually. Then the switch worked fine again. But it took over a day to get this fixed.

I talked to a friend who has a sister who uses switches, and she experiences the same issue with another Bluetooth switch she’s using. It keeps unpairing for some reason.

I see a pattern emerge if you consider other assistive technologies as well. The last few months I’ve met three different blind screen reader users who have had to restart their devices when they froze in the middle of usage.

So it seems to me like assistive technology bug far more often than mainstream technology. Which is a huge problem considering that many assistive technology users rely heavily on their tech working.

Try it yourself

There are a few ways to try switch control yourself:

The easiest way to try this out if you don’t own a switch is probably to use an Android phone. Find the phone’s accessibility/ease-of-use settings and go into Switch Access. The reason Android is great is that you can assign the up and down volume keys as switches and get going really quickly, without having to buy a switch.
If you own a Mac you can assign any key on your keyboard as a switch, which is great. So go into Settings and Accessibility to try this out.
On iOS products you can set the phone’s screen to be a switch. This is scary since when you’ve activated this, any tap on the screen is like clicking a switch, instead of what usually happens when you tap the screen. You can also use the camera as a switch, so when you tilt your head left or right it activates the switch. But this wasn’t very stable when I tested it.
If you want to try a real Switch you can get one for around €100. Just Google “buy switch assistive technology” and you’ll get loads of hits.

My key takeaways

To summarize, this experience left me with three main takeaways:

Switch technology is awesome. Even though most things take longer time, I could still do everything I otherwise do – just using a single switch. What a great leap towards an independent life this must be for people with limited motor abilities!
There’s a lot that switch interface producers like Apple could do to improve the user experience for switch users. For instance more efficient scrolling, less annoying notifications and improved word predictions.
Designers and developers of apps and websites should mainly keep their interfaces clean, avoid time limits and have good error handling. So basically work on creating a good user experience for all users.

Those are the main things that stuck with me, but…

…don’t rely on my experience!

My experience of using a switch for a day is by no means comparable to someone using it every day of their life. So I want to end this article by pointing you to resources where you can learn about switch control from actual switch users:

Christopher Hill’s YouTube channel
Apple’s 2 minute videos Ian M and Todd S
Different switch users, YouTube playlist
@AbleGamers on Twitter
@OneSwitch on Twitter
Switch gaming blog

Last impressions first – a flipped approach to web design

Hampus Sethfors — Thu, 17 Oct 2019 10:07:41 +0000

Web teams usually spend a tremendous amount of time, money and energy on designing lovely, beautiful start pages. Let’s apply the psychological concept known as the peak-end rule to question that and introduce a flipped approach to web design.

Why we care so much about start pages

If your parents are like most parents, you’ve probably been raised to care a lot about first impressions. How to introduce yourself, shake hands in the right way, dress properly and so on. I remember my parents repeating “first impressions last” and “you never get a second chance at a first impression” to me as a kid.

Then time ticks on and kids with this mindset grow up. Some of us go into the web world and become designers, developers, content creators, scrum masters and so on. It’s natural for us to apply this first-impressions-matter-mindset to the projects we work on. So we focus on the start page and make sure our users get the ultimate first impression when using the interfaces we create.

The start page is also probably the thing that is displayed in marketing materials, on important board meetings and what you show friends or family members who ask what you actually do during the days.

But I believe it’s time to start questioning the importance of first impressions in digital products. Let’s use Nobel Prize-winning psychology to argue that we’re overrating the impact of start and landing pages, whilst at the same time underrating other aspects of the user experience. It’s time to shift focus if we really care about how our users experience, feel about and remember the sites and apps we build.

The peak-end rule

I don’t know Daniel Kahneman, but I feel quite confident saying he’s a smart guy. Kahneman is a psychologist who won the Nobel Prize in 2002 and has written the masterpiece Thinking Fast and Slow. He is an expert in the way we think, make decisions and experience the world. He and his colleagues have shown that two things matter a bit more than everything else when people judge an experience:

How they felt at the peak of the experience (best or worst)
How they felt at the end

For instance, let’s say you go through a medical procedure. Every minute you’re asked to rate how painful it is from a scale from 1-10. In the beginning, you don’t feel much pain at all, so you rate it a 2. But at its height there was a very painful moment that you rated a 10. And at the end of the procedure you rate your pain as a 6.

When you’re asked about the experience a few days later you’re likely to rate it at an 8. In other words, the average between the peak 10 and end 6. It doesn’t matter that your first experience was a 2. When thinking back on an experience, most people will only consider the peak and end. Here’s a more in-depth article about the peak-end rule (medium.com).

Applying the peak-end rule to web design

If you want positively affect the user experience your site or app, don’t focus a lot of time and energy on designing the first experience your users encounter. Instead, consider how you can make sure that the peak and last experience of using your site is awesome.

So let’s go through:

How to create an awesome peak experience
How to create an awesome last experience

Of these two, creating an awesome last experience is most important. I’ll get to why soon. But let’s go through them in order.

How to create an awesome peak experience

A great way to create awesome peak experiences is to think seriously about how you can make your users smile. I’ve written a whole article on charming interfaces, but in essence, it’s about working with microcopy (tiny words with a huge UX impact) – and illustrations to create pleasant experiences.

Let’s look at my favorite example of how microcopy can be used to create a peak positive user experience. It’s from Prezi’s sign up form, which makes it even more impressive since forms are usually really dull.

The form complements the user with brilliant microcopy after entering the details they ask for. Genious!

If you want to become a wizard in microcopy, I’d recommend:

Apart from microcopy, working with illustrations and animations is a good way of creating positive peak experiences. Here’s a very cute login form from readme.io, where an illustrated owl peeks when you’re typing your email but covers its eyes when you type your password.

An important detail in the peak-end rule is that the peak experience, good or bad, is what will define a users overall feelings of the experience. So for all of us who design digital products – or any product or service for that matter – it’s very important that our users’ most positive experiences create a more intense reaction than their most negative experiences.

If a user finds most of your site pleasant, but their peak experience is frustration of filling out a CAPTCHA three times – well, sadly, the pleasant experiences won’t matter much at all.

As you probably experienced yourself multiple times: confusing or frustrating experiences easily create strong reactions. On top of that, these types of negative experiences are very common in digital products. So you need to work hard on minimizing the risk of strong negative experiences. On that topic, I have two tips:

User test regularly. Nothing beats watching people use your site and seeing where they react strongly, get confused or get stuck. And while on that subject, consider testing with users with disabilities.
Work on your error messages. It’s the one place where users are most likely to experience strong, negative feelings.

When it comes to error messages, the most important thing is to make sure users understand what’s gone wrong and how to fix it. This article on best practices for error messages is a nice read. But on top of that, error messages are often a good place to use some charm and humor to minimize the negative emotions they cause.

So before moving on to the last experience, let’s summarise how to create an awesome peak experience:

Make your users smile. For instance by working with microcopy and animations.
Avoid negative peak experiences. For instance by user testing and focusing on error handling.

How to create an awesome last experience

So let’s now shift our focus to the last experiences. This is a hugely overlooked opportunity to positively affect how your users remember your site. One of the best UX-hacks I know is to do everything you can to create an awesome last experience, thereby merging the last experience with the peak experience.

It would look something like this when applying Kahneman’s peak-end model:

So if the user’s memory of an experience is based on the average between the peak and end experience, and you make sure that the last experience is a 10, then most users will remember the whole experience as a 10.

I suggest moving a lot of that time and energy that you now spend on start pages to creating a fantastic last experience. That will most likely have a huge impact on the user experience and what people tell their friends about your service.

To do this, start by identifying where your users are when they stop interacting with you. It’s often at one of these places:

Confirmation messages or order summaries – after having bought something or completed a form
Offboarding processes
Footers – after having read through your content

Then make sure these places are awesome! Let’s look at some examples.

Spotify does this really well by providing an offboarding process with great microcopy and a charming playlist called “Can we still be friends?”:

Disney also gave some love to their offboarding:

Gov.uk focused on A/B testing the last experience of one of their thank-you-pages. They made it so good that each year, an estimated 100 000 more people sign up as organ donors each year through one link on that page. Nice!

It’s not only the digital world that can work on last experiences. When leaving the dentist as a kid, I remember always getting a sticker and some cheerful words. Some hospitals have taken this a step further, with an end of treatment bell:

Finally, back to the digital space! More sites could put some effort into their footers. It’s difficult to find many good examples of this, but some have at least added illustrations to their footers which I think is a step in the right direction:

A flipped approach to web design

So to sum up, if you’re serious about your user experience you should stop worrying about the pixels on your start page and begin focusing on the last experience.

“First experiences last” is an overrated saying.

“Last experiences first” is the new black.

If you liked this article

Apple’s new feature a step towards digital apartheid

Hampus Sethfors — Thu, 28 Mar 2019 18:24:11 +0000

To be honest, I don’t really have time to write this article. I’ve got loads of other things I should be doing. But it needs to be written. Now. So I’ve popped up my laptop on the bus and am angrily typing away.

Sounds so serious…what’s going on?

So Apple just released a new accessibility “feature” called accessibility events. Here’s how they explain the feature:

Accessibility events allow websites to customize their behaviour for assistive technologies, like VoiceOver. Enabling Accessibility Events may reveal whether an assistive technology is active on your iPhone.

Here it is in action on an iPhone:

So this feature lets web developers recognise when an assistive technology is active on the user’s device. Sounds great, right? Gives developers a chance to improve the user experience for people with disabilities.

But think a step further and you’ll realise that it’s actually a terrible idea.

Why?

Well, accessibility guru and screen reader user Marco Zehe explains it well in his article Why screen reader detection on the web is a bad thing. Here is the most important part in my opinion:

Letting a website know you’re using a screen reader means running around the web waving a red flag that shouts “here, I’m visually impaired or blind!” at anyone who is willing to look. It would take away the one place where we as blind people can be relatively undetected without our white cane or guide dog screaming at everybody around us that we’re blind or visually impaired, and therefore giving others a chance to treat us like true equals.

– Marco Zehe

Another accessibility guru Léonie Watson also wrote a great piece on this topic: Thoughts on screen reader detection. In it she argues that screen reader detection could lead to her and others being directed to text-only versions of sites:

I don’t want to be relegated to a ghetto. We’ve spent years encouraging people to move away from text-only websites, and with good reason. If there is one thing that history should have taught us by now, it’s that social segregation is a bad idea.

– Léonie Watson

From my own experience, one of the most common questions I get as an accessibility consultant is “Can’t we just create a special site for people with screen readers?” I say that you can’t, and even if you could it would be a really bad idea. Inclusive design is about inclusion, not separation. The problem is that with this new tool from Apple, well-meaning people with this common, but terrible idea of separate “disability-sites” now can implement it, whereas in the past they couldn’t.

The accessibility community is not pleased

Other accessibility folks are not impressed either:

This new Accessibility Events feature for VoiceOver in iOS 12.2 might possibly be the worst idea ever (especially as it is enabled by default).

Sure, let’s give devs ways to identify blind users & serve alternate versions of content. That worked really well in the past. pic.twitter.com/gDTSvQqNKp

— Denis Boudreau (@dboudreau) March 27, 2019

It's been possible in native apps for a while, but now @Apple has enabled disability fingerprinting in Safari on iOS. https://t.co/b7ahixqbke #privacy #fail

— Léonie (@LeonieWatson) March 27, 2019

https://twitter.com/aaronkhowell/status/1110650865180790784

Yikes.. sounds like the perfect excuse to build "accessibility" in exactly the wrong way

— Facundo Corradini (@fcorradini) March 26, 2019

I also discussed this accessibility events feature with my friend who is a screen reader user herself. She said it feels like it’s a first step towards a well-meant digital apartheid. To give you a magnitude of the impact this type of detection might have.

As if things weren’t bad enough…it’s on by default

First I thought users needed to opt-in on the setting. It would still be bad but tolerable. But alas! It’s activated by default! So users who just turn the screen reader on have it enabled. Yes, they can turn it off:

How to disable "Accessibility Events" the VoiceOver and other AT tracking feature on iOS update 12.2 pic.twitter.com/RC5W8a0e1t

— Ross Mullen (@MrRossMullen) March 27, 2019

But everyone knows most users will be completely unaware of this feature.

There’s barely any information

This feature dropped like a bomb on the accessibility community and there’s basically no information out there on it. Nothing in the release notes, nothing on Apple’s site. It just appeared in the accessibility settings, and someone noticed and wrote a short article about it on Apple Vis.

My good friend Kolombiken (who writes the best accessibility newsletter out there, you should check it out) went searching for answers in a huge Slack group for accessibility nerds and found nothing:

I’m soo confused over this new “accessibility events”-thing in iOS. I came here to look for answers but seeing that people here are equally confused. But there must be some documentation somewhere? No?

Apple, you can’t just roll out a feature like this with no information! Come on, this is not like you!

Hopefully this is just a hiccup

I think it’s safe to say that Apple has some serious explanation to do here. Both around the feature and the non-existent documentation around it. Hopefully it’s just a mistake, wasn’t supposed to be rolled out or something similar.

Until that is confirmed though, I think it’s time for the accessibility community to protest rather loudly.

Update

Yay! Apple has now removed the accessibility event feature, about a month after it was released. All is well and I’m not angry any more!

Accessibility T-shirts! Look like the a11y nerd you are

Hampus Sethfors — Sat, 23 Feb 2019 22:09:10 +0000

It’s well known in the accessibility community that the road to an inclusive digital world is through awareness. And what better way to raise awareness than wearing an awesome, head-turning accessibility t-shirt?

Before we begin, you might be wondering how much we get paid to write this post. It’s zero. Zip. Nada. Just hopefully the admiration from other fellow accessibility nerds! So let’s dive in!

Flaunt your love for accessibility, cats and puns (alley cats..get it?!). Put this on your Tinder profile and you’re good to go!

Get A11y cats t-shirt on Bonfire

The future is accessible t-shirt

Thinking about the future is can be scary these days. Finally, you have the chance to spread some positivity!

Get this future t-shirt on Redbubble

You can get a more sparkling version of the same statement.

Get the sparkling future t-shirt on etsy

Moose in wheelchair t-shirt

We might be a bit partial since we’re based in Sweden, but moose are just irresistible! Almost as irresistible as everyone who’s working with accessibility. Perfect match!

Get your moose t-shirt on Teepublic (there are also versions on the site with other animals like giraffes and even dinosaurs!)

WCAG t-shirt

Perfect for walking around the office quizzing colleagues. Do they know where the words come from? If not, send them off to accessibility training!

Get your WCAG t-shirt at Redbubble

Inclusive coder t-shirt

Display your passion for accessibility alongside html, css and javascript.

Get your inclusive coder t-shirt from Scott Vinkle

Accessibility matters t-shirt

It’s not easy to find t-shirts raising awareness of hidden impairments like autism. But luckily we found this one! A great reason to go get it is that “50% or more of the proceeds from this design are donated directly to disabled individuals who are fundraising for a mobility aid or other accessibility device.”

Get the accessibility matters t-shirt at Bonfire

Closed captions t-shirt

Videos lacking closed captions is one of the major accessibility issues on the web. This cc t-shirt gives you a great chance to talk about closed captions with everyone who asks what the “cc” means!

Get your cc t-shirt at Redbubble

Sign language be kind t-shirt

While on the topic of hard-of-hearing-awareness, check out this great message in American sign language (ASL).

Get your sign language t-shirt at Amazon

Wheelchair trick t-shirt

Finally, let’s challenge the classic sitting-still-in-a-wheelchair-disability-icon with this great print!

Get your wheelchair trick t-shirt on Teepublic

Whether or not you decide to buy this t-shirt: take a minute of your life to check out the guy who probably inspired it: Aaron “Wheelz” Fotheringham.

Keep spreading awareness!

Hope you found something to upgrade your wardrobe with, at the same time spreading some accessibility awareness. If you know of any other prints that you think we should add to the article, please tweet us and we’ll add them!

Meanwhile, if you’d like to dig deeper into digital accessibility, check out our other articles. We guess that if you’ve made your way down here you’d appreciate some of our more nerdy posts. So here are a few of those:

Axess Lab just got a 5-Star rating on Clutch

Joel Holmberg — Thu, 21 Feb 2019 15:23:59 +0000

Axess Lab is a team of IT professionals who want to make life easier for everybody. And it seems to be working!

As you may know, we do everything from development projects for everyone to specific digital efforts to help people with a variety of mental and physical disabilities, and we strive to show the world that accessible development only helps, never hurts.

In an effort to further the cause of accessible development, we can now be found on the B2B ratings and reviews platform, Clutch.

Clutch uses in depth market research and verified client reviews to identify top service provider across a number of industries. We are featured on several directories on Clutch, including alongside some of the top software application testing companies in the world. We hope that our increased visibility by joining the platform will help firms find us and consider making their software and services more accessible for everybody.

In addition to expanding our visibility, our presence on Clutch helps us gauge how we are performing for our clients. Although our profile has been active for only a short period of time, we already have our first review! When asked what they found impressive about our work on their project, a job matching platform for people with disabilities, our client remarked,

Their skills and accessibility are impressive. They’re interested in people, and they take time for everyone involved in the project. There’s always good communication, and they’re nice people.

We care about every project and every person we work with, and we are glad that our clients have taken notice. It is a wonderful feeling to be praised by our clients, but we are even more excited to receive their honest feedback. We may only have one review, but we look forward to using future feedback to help us improve our services.

Clutch’s sister-site, The Manifest, has also featured us as a top firm. The Manifest is a business resource that helps teams identify and address their business challenges, providing how-to guides and industry insights. We were included on their list of the top web developers in Sweden, cementing our reputation as a reliable partner, and a skilled team of developers. In spite of the praise that we have received, we believe in letting our work speak for itself. We will be posting some of our best projects in a portfolio on Visual Objects, a space for user experience designers and other firms to share their work with potential clients.

It is always exciting to be recognized as a success in your industry, and we are thrilled to be celebrating the recognition we have received from one of our clients. And speaking of our clients, thank you to everyone who has supported us on our journey. We have always wanted to help people, and we cannot express enough gratitude for the help we have received ourselves.

Have you worked with us in a development project, or received accessibility reviews or user test analysis? Please give us a review on the Clutch site, and let us know how we’re doing!

Real Facts about the Elderly and the World Wide Web

Joel Holmberg — Wed, 23 Jan 2019 05:22:24 +0000

There are lots of stereotypes about the elderly and tech or the world wide web. Many portray the over-sixty crowd as being unable to cope with modern tech.

But is this stereotype correct? That’s what Dr. Nikola Djordjevic, from the site medalerthelp.org set out to learn. His team compiled all of the information into a comprehensive infographic and the results may surprise you.

We got their help to break it down into smaller, more manageable pieces and transcribe the contents for our non-visual readers. Let’s go through the stats one by one.

Usage

Those of the baby boomer generation spend around 27 hours weekly online.
Of the group aged over 65, seven out of ten will go online daily.
82% of those in both groups run searches online related to what they’re interested in.

So, in terms of usage, seniors are a lot more active online than you may have suspected.

Why do they use it?

78% of seniors say that they like going online because it enables them to find the information that they need easily.
60% of them believe that you can stay up to date when it comes to policy and political issues by surfing the web.
For around about a third of seniors, the internet is considered a trustworthy source of information and news.

So, the internet is viewed by many of the elderly as a valuable resource.

The types of information they access

Two-thirds of seniors use the web to access weather and the news.
57% shop online.
44% want information about food and cooking.
43% use it to play games. And, boy, is that breaking a long-held stereotype! Just keep in mind that people who pioneered computers and the internet are now in their sixties, so the generation that started it all is actually quite active.
Almost half go online to check for coupons, daily deals, and discounts.

What can the internet be used for?

20% of seniors communicate with their friends via email.
75% of the elderly go online to communicate with their family and friends.
More than half of those who are classified as seniors follow an organization on social media.
40% of seniors who watch videos online do so in order to keep up to date with breaking news.
53% of the elderly research medical or healthcare issues online.
54% of seniors watch videos online for purely entertainment purposes.
Half of the seniors say that it’s very important to play games in order to remain sharp. A further 26% state that playing games is extremely important for this reason.

Internet usage by category

Two-thirds of queries that seniors make online are related to medical or health info.
Coming a close second is visits to federal, state, or local sites.
A small percentage of seniors do take classes online, but that’s only about 18%.

A lot has been said online about Facebook being more popular among older users. As one commentator put it, “Facebook is for the parents, Instagram is for the kids.” The stats seem to bear this out here as well.
61% of those aged 50–59, prefer Facebook. For the over-sixty category, Facebook still comes out on top with 36% of users using it.
Compared to Facebook, the other main social media sites don’t fair very well with seniors.
Of the group aged 60 or over, 5% use Instagram, 6% use Twitter, and only 1% use Snapchat.

Some general statistics

For the age group 65 and over, 66% of seniors in the United States go online, and only 10% have smartphones. That’s compared to 87% for those in the 50–64 age group, where around 16% of people have a smartphone.
The results also highlighted an interesting phenomenon – both seniors with and without disabilities used the internet. You would expect the seniors with disabilities to use it more. You’d be wrong.
Seniors in the age bracket of 80 years old or more tend to use the internet and smart-tech the least.
The activity that comes out on top on a daily basis for 91% of seniors is to send or read email. 70% of seniors will also run searches at least once a day online.
Across all of the older age groups, cell phones are put to good use. Even in the over eighty category, around about 58% of seniors have cell phones. Smartphone adoption, however, decreases with age.
In terms of smartphone usage across various categories, seniors do account for the smallest numbers, which indicates that they are not as comfortable with smartphones as they are with regular mobile phones.
If you’re aiming to sell to this target group, the conversion rate is highest on the desktop platform at 72%. In this area, seniors come out trumps. Tablets and phones don’t, however, fair nearly as well in terms of conversion rates.
Watching TV online is popular with the 50–59 age group. Furthermore, around about 63% in this age group access streaming services online.
22% of disabled adults in the UK have never used the internet.

Who doesn’t use the internet?

That’s not to say that all seniors do use the internet. 34% of those who are over 65 don’t go online at all. This is a massive difference when you consider that that figure drops to just 3% for those aged 30–39.

Why don’t some seniors use the internet?

One of the challenges is poor health or a physical condition that doesn’t allow them to easily access the internet. This affects about two out of five seniors. Almost a quarter of the older generation does not believe in looking online for news, etc. They don’t feel as though they are missing out at all.

But, the most prevalent reason by far, in fact in 77% of cases, is simply the lack of knowledge. They need someone to show them exactly what to do and help them until they get the hang of it. In about another quarter of cases, online harassment is cited as the reason to stay offline. About 22% of those in the United States who are fifty or older have been harassed online before.

So, there you have it – have you changed your thinking as far as the elderly and the internet is concerned?

URL: https://medalerthelp.org/elderly-the-world-wide-web-infographic/

Instagram – You’ve been Axessified!

Daniel Göransson — Thu, 03 Jan 2019 14:57:58 +0000

Hi Instagram! We’re thrilled to see you’re improving your accessibility by making it possible to write alt-texts for images. As a token of appreciation, we’ve made you part of our Axessified-series! This means you get some top-notch, tailored inclusive design tips to help you take the next step on your accessibility journey!

First off – we really like you!

There’s rightfully been a lot of praise from the accessibility community about Instagram’s new alt-text features. Now, an Artificial Intelligence (AI) engine gives each image an automatic alt-text, and also makes it possible for user’s to improve that image description by writing custom alt-texts.

This is simply awesome, making one of the most popular social media platforms so much more inclusive to people with visual impairments. We see this as a sign that you’re interested in making Instagram more inclusive for users with visual impairments.

So Instagram: don’t stop now, keep moving forward! Here are three tips on what we think should be your next accessibility improvements for users with visual impairments..

Tip 1 of 3: The more-button

In the feed, sometimes you show a more-button when a description is too long to be displayed.

This button is completely inaccessible for screen reader users like myself (if you aren’t familiar with screen readers, here’s a great 7 minute introductory video on YouTube: Assistive tech: VoiceOver on iOS).

The more-button is actually read by screen readers – a great start! But the problem is that there is no way to activate it. When you try to click it, you’re redirected to the user’s profile page. Not at all what you’d expect! Here’s a video when I show this in action:

First off, a short sidetrack. Did you notice the great start of the video: “Image may contain text that says Accessibility is for everyone.” This is the new AI-engine in action, making image of text accessible to screen readers. Whoopee!

But later in the video the screen reader reads half a sentence and then the word “More”, like this: “I think that’s a…More”. When I click I land on the profile page’s back button, instead of having the description show.

To solve this conundrum, you can do one of two things:

You probably already figured this first one out:
Make the more-button clickable.
Get inspired by your best buddy: Facebook. There, the whole description is read by the screen reader even if it’s collapsed visually. Meaning screen reader users don’t need to click the more-button to hear the full text. Super convenient!

Of these two solutions, we’d recommend you to go for number 2!

Tip 2 of 3: Stories

When viewing Instagram stories, basically nothing works for me and other screen reader users. To navigate Stories you tell us to press and hold to pause, tap to continue to the next story and so on.

But you see, with a screen reader activated, none of those gestures work in Stories. Everywhere I try to click on the screen I just hear a sound telling me that there’s nothing there to click. Here’s a video of me trying my best to click anything at all on the screen, and failing. All I can focus on are a few icons on the screen, but no content.

So I don’t get any content read to me. But the worst thing is that I can’t pause the slideshow. If you have a vision impairment like me, you need to be able to pause the stories to have time to look closely at the screen (yes, most people with visual impairments still see a little bit), zoom in, read alt-texts and so on. Now each story just swishes by too quickly.

To make things even worse, I often use an iOS built-in zooming feature where you tap with three fingers to zoom in to images, which works poorly in Instagram Stories. So what I’ll do is turn off the screen reader when entering Stories, and instead rely on zooming and my limited vision. But the problem is that tapping with three fingers in Stories is often registered by the app as a single tap, which switches to the next story. Really frustrating!

So to conclude, right now Instagram Stories is a bit of a mess for a lot of users with vision impairments. A simple fix would be to include a setting or a pause button that disables the autoplay feature and instead gives users control of when to switch to the next story.

Tip 3 of 3: Naming of your icons

This last one is not a “show-stopper” for screen reader users like the two earlier sections. However, it is an easy fix that would improve the overall user experience and make it more pleasant to spend time in your app. You can compare this issue to having visually ugly icons. You could still use the interface, but it would feel unprofessional.

So the problem is that many of your icons are read as something like:

“Ig icon direct outline 24 direct message”

“Ig icon more horizontal outline”

“Ig icon x outline 24”

That’s probably the file name of the icons, which is not something your users should be exposed to.

Here’s a video of that experience with my screen reader.

So even though each icon’s description contains the meaning of the icon, it’s hidden between a bunch of nonsense. It’s like being forced to play a game of Where’s Waldo…

Luckily, this is something that should take you a matter of minutes to fix. So a really low hanging fruit! Yay!

That’s enough for now!

We have a lot of other input and ideas, but let’s start with these issues. Remember to give yourself a pat on the back when your done! Then take the next step. Accessibility is not something you do once and then are done with. Just like you’re never done with usability or performance improvements. Always strive to take small steps forward. Everywhere. All the time.

But do contact us if you want us to elaborate on this post and help out. There are a lot of tools you can use to catch these errors before they are in production.

Who’s next?

This was the first post in our Axessified-series where we give accessibility tips to teams behind important digital products that affect the life of many.

Accessibility tips for specific products is something we usually charge for, and it’s a big part of how we make our living as a company. But the sites and apps we look at in this series have such a big impact on so many users that we want to share these tips free of charge in hope that they reach the product teams, and inspires them to make their products more inclusive. Hopefully it also gives some nice insight to all readers on how to succeed with accessibility.

Which service do you think we should check out next? Tweet us or send an email to [email protected].

Slides from Accessibility Scotland

Hampus Sethfors — Thu, 08 Nov 2018 11:03:16 +0000

Hey Accessibility Scotland! I like you guys even though you invented golf…

Here are the slides from my talk:
Have you tried to dab some coconut oil on your spine (PowerPoint on Dropbox)

Enjoy!

And while you’re here, you might as well check out our other articles on accessibility.

Accessible Comics

Hampus Sethfors — Tue, 07 Aug 2018 08:47:48 +0000

A lot of the accessibility initiatives today are focused on web sites and apps. But there’s of course more to the digital world than that. In this article we’ll look at a case where a team has done great work to make their digital comic accessible to people with visual impairments.

Let’s start with a small experiment!

Imagine a blind person.

What image pops up in your head?

Is it a young person? Is the person at their work? Doing sports? At the cinema? Buying an Apple Watch? Reading a comic? Probably not.

There are many preconceived ideas out there about what people with disabilities do, or rather don’t do. If you don’t have a visual impairment yourself or some blind friends, you probably don’t think of blind people in the above situations. Most people tend to think of an old person with a cane, not doing much. Which of course is a problem that for instance affects how people are treated, job recruitment and which products are made accessible.

So we need to get more people to see people with disabilities as a diverse group with all sorts of jobs, interests and hobbies. And we need to get more people to understand that their users have disabilities, which is what the article “Our users have no disabilities” is all about.

Making a comic accessible

With this in mind, I was pleasantly surprised when the team behind a comic contacted us, asking for advice on the style of alt-texts for their comic: 100 Demon Dialogues.

Sidenote: this might seem like a sponsored article, but it’s not. We’re just thrilled to see the great job this team has done and want to share it with you!

Most people would never think about making a comic accessible for people with visual impairments. After all, comics are very visual.

But the author Lucy Bellwood – in the image above – is more inclusive than most people. She wanted to make her comic accessible to comic lovers with visual impairments as well, and brought a team together to get it done. So they asked us to review a couple of alt-texts they had written. It turned out that they’d already grasped the concept very well so our advice was basically: “Great job, keep doing what you’re doing. And can we write about this when it’s out?”

And now the comic is out. We tested it with a screen reader – an assistive technology that speaks alt-texts to the user – and the experience is awesome.

So below are two short, short videos.

An inaccessible experience of a regular comic where the screen reader just says “Background” when it tries to read the content.
The accessible 100 Demon Diaries comic that reads the well crafted alt-texts, which both explain what’s happening visually in the comic and what’s written in text.

Direct link to inaccessible version demo (Youtube)

Direct link to accessible version demo (Youtube)

It’s so great seeing people making their products accessible, especially when barely anyone else in their field are doing it. Hopefully it motivates more people to do the same thing and opens more people’s minds as to the diverse interests of people with disabilities!

If you’re as happy with this initiative as we are please spread the word about this and give the author Lucy Bellwood (@LuBellWoo) and her team with Kate Brednow, Andy McMillan (@andymcmillan) and Jason Alderman (@justsomeguy) a shoutout on Twitter.

I also strongly recommend the Tumblr A11y Wins – a site that’s dedicated to showcasing positive accessibility examples.

If you want to check out the comic, you can find it in the following places:

Search for “100 demon dialogues” in iBooks.
Amazon
Gumroad

LGBTQ-inclusive web design

Hampus Sethfors — Thu, 02 Aug 2018 14:29:27 +0000

It’s pride week here in Stockholm, Sweden! So we thought we’d celebrate by sharing a few tips on how to create a LGBTQ-inclusive digital environment.

Here at Axess Lab we specialise in accessibility and inclusive design – which is about making sure as many people as possible feel great about using your products and services. Accessibility and inclusive design is often focused on people with disabilities, but let’s look at two concrete things you can do to make your digital products awesome from a pride perspective!

1. The gender question

Many forms include a question about the user’s gender.

Do you really need to know this information? If the answer isn’t a clear “yes”, then the best idea is probably to just remove it. A lot of services ask for users’ gender without really needing it. Simply not asking for gender is great because of a few reasons:

You reduce the length of your form by one field. And it’s a fact that reducing the number of form fields increases conversion rates (searchenginepeople.com)
Your users don’t start questioning your intents. A lot of companies ask for gender information to be able to send you specific marketing. Many users know this and get suspicious.
You don’t risk excluding users who has another gender identity than the ones you specify.

If, however, you really need gender information you can ask for the information in an inclusive way.

The examples below are from the article Designing forms for gender diversity and inclusion by Sabrina Fonseca and the talk All inclusive design – excluding no gender by Sara Lerén (@HeedTheNeed).

The first step that many have already adapted is to add an alternative for “Other”. This is better – or should I say “less bad” – than the binary “Male/female”. But people who identify as male or female get their own categories while everyone else are mashed together to “other”. We can do better!

Sometimes the simplest solutions are the best: a custom input field where the user can type whatever they want. Also note how you can explain why you need the gender information below the field.

You could include a custom input field after a male and female radio buttons, like this:

Including a “Rather not say”, like in the example below, is great as well. It gives people the chance to skip the field, and many who identify as something other than male or female are extra cautious about sharing that information online. Seeing the huge problems with for example transphobia around the world, everyone will not want their gender identity registered in some online database. Combine the “Rather not say” alternative with a custom input field, and you’ve come a long way with little effort!

If you want to go all-in, check out Facebook. They’ve done a lot of work with their gender questions. There’s a huge list of gender identity “tags” to choose from, and if you don’t find the correct one you can add to the list yourself. Also, they ask for your preferred pronoun, making it possible to prefer a gender neutral pronoun with examples on how it will be used: “Wish them a happy birthday”.

2. Choose inclusive images and illustrations

Our second tip to becoming more LGBTQ-friendly is to work with your images and illustrations.

A lot of people can rarely or never identify with the people that are represented in images or illustrations on websites, social media and the like. What you choose to display there says a lot about who your target audience is, so make sure it’s as diverse as possible to feel relevant to all your potential users.

Break as many norms as possible in your imagery. Show women playing sport, men taking care of kids, a person in a wheelchair coding, a family with two dads and so on. And make sure not everyone in your images are white.

Below are some great examples of inclusive images you can get inspired by.

The Swedish army fight for LGBTQ-rights:

Facebook shows icons of two men instead of a man and a woman when two men get married:

I recommend everyone to check out this Swedish guide: Images that change the world. Even if you don’t know Swedish, just flip through the guide and look at the great images, you’ll get the point!

Here’s one of the images featured in it, pointing out that older LGBTQ-couples are extremely rare to see in images.

Here’s a great banner image on Stångåstaden a Swedish site for renting apartments:

The Swedish youth clinic site has some awesome, inclusive illustrations on their site. The great thing about the one below is that it’s on a page about friendship. It’s not on a page about dating with disabilities. So they picked an inclusive image without making a point of it. This is a great way to help widen the norms we live by.

Sometimes it can be difficult to find inclusive images, especially on regular stock photography sites. But luckily Jenny Hellenberg (@jenhell) shared some good tips with me, so here are some great places to look for images with diversity:

LGBT section at Twenty20 (the screenshot above is from this site)
Unsplash (free)
Tetraimages
Photoability
Getty images lean in collection
Natural Woman Photos

Hope this inspired you to keep improving your inclusive design!
Happy pride everyone!

Your skip links are broken

Hampus Sethfors — Thu, 21 Jun 2018 08:16:59 +0000

Many websites have an accessibility feature called skip links that help some users navigate the site. However, there’s a problem with basically all skip links on mobile devices, which hurts your site’s accessibility instead of improving it.

What are skip links?

Skip links are a common accessibility feature on websites. They are simply shortcuts to important parts of the webpage that makes it easier and quicker for some users – especially users with disabilities – to find their way around.

Skip links are usually hidden visually by default and appear when users navigate to them using the tab key on their keyboard. “Who would ever use a keyboard to navigate?” you may ask yourself. Well, lots of people actually! For instance many users with motor or sight impairments will rely on keyboard navigation. But more on the use cases under the next heading.

If you want to try out a skip link using your laptop, go to Starbuck’s website and press the tab key after you have entered the site.

Here’s an attempt at illustrating what happens.

So when you “tab into” the site the skip link appears, and you can activate it with the Enter key to skip to where it points. On Starbuck’s site you can (in theory) skip to either the main navigation, content or footer.

Skip links work well on desktop. Here’s a short video where I’m using them on a few sites with the VoiceOver screen reader on Mac. It might be a bit difficult to follow along if you’re unused to hearing a screen reader in action, and to make things worse mine switches between Swedish and English. But the important thing to notice is how the focus indicator jumps into the content area after I press the skip links:

Skip links are great when they work, and this type of functionality is recommended in the Web Content Accessibility Guidelines (WCAG):

2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.

– WCAG 2.1

We can sanity-check your skip links across iOS/Android and desktop as part of a WCAG review.

Who are skip links for?

Skip links are mainly used by:

Users with motor impairments who navigate with a keyboard instead of a mouse.
Users with motor impairments who navigate with switches.
Users with severe visual impairments who use screen readers on desktop or mobile devices.
Users with low vision who use screen magnification software in combination with keyboard navigation.

Instead of having to spend time tabbing through the logotype, links in the header, menu, etcetera, on each page you visit, skip links provide a handy shortcut to jump straight to what you’re after.

They’re also quite popular among users. In the latest Web AIM screen reader user survey – which almost 1800 people responded to – over 30% said they always or often use skip links when they are present.

We’ve seen in user tests that skip links are even more used by novice screen reader users. Tech savvy users tend to use shortcuts on their keyboard or special gestures to skip between different parts of the page. But less “techy” users are not always aware of those features, and will instead often use the skip link to find their way to the main content.

Update april 2020

The problems we describe below have been fixed by many (all?) of the browsers/assistive tech/operating systems. So skip links seem to work as intended in most devices right now.

The problem

We became aware of a major issue with skip links after seeing it in two user tests a few months apart, where two different screen reader users struggled with the same type of problem on two different websites.

One of our clients was kind enough to let us share a video clip from their user test in this article. So thanks, Council of the European Union, for that . The user in the test has also given us her consent to spread this video.

So take a look at this clip (sorry for the blurry start), then we’ll tear apart exactly what’s happening.

So in the clip we see a screen reader user trying to use the skip link with her iPhone. This is what happens:

She activates the skip link.
The page scrolls down visually – which she and other blind user will not be helped by.
She swipes right to go to the next object – you can think of it like pressing the tab key on a desktop.
The screen reader puts focus on the cookie message, not the main content.
She naturally gets quite confused and annoyed.

We started investigating the problem and found the same issue on every single skip link we tested. You can try it yourself if you know how to use the screen reader on your smartphone at these sites:

Or just check out this video where we try to use skip links with VoiceOver on an iPhone on the sites above. You’ll see the sites scrolling, but as soon as we swipe the screen to go to the next item, we’re back at the top of the page.

Skip links are almost always constructed in the same way. They are simply anchor links pointing to a part of the page.

Something like this:


Skip to main content

//Menu and other stuff users might want to skip..

…

For some reason, these simple anchor links don’t work as intended on iOS. We tried in Safari, Firefox and Chrome – all have the same issue.

To be clear, this problem exist on mobile when the user navigates by swiping to go from one object to the next. There is another way of navigating (explore by touch – moving your finger over objects on the screen), and then it works fine on iOS.

Affects Android as well, but in a different way

Regular skip links don’t work with VoiceOver on iOS as shown above. Sadly they don’t work with Android’s screen reader TalkBack either, but this time it’s not the anchor link that’s causing the problems.

In Talkback, skip links don’t even show up when the screen reader focuses on them. Here’s a video where you’ll hear the skip link being announced, but it’s not showing on the screen like in iOS. We try to activate the link when it’s announced, but nothing happens.

This is caused by a bug in Android that stops the focus event from being triggered. It’s probably easiest to understand if you look at this video comparing what happens when tabbing on desktop, using VoiceOver on iOS and using TalkBack on Android. You’ll see that when tabbing on desktop or using an iOS screen reader, the focused links turn orange. On Android, you never see the orange focus style.

For some reason, Android doesn’t trigger the CSS focus event with TalkBack. This is the reason skip links never show up visually on Android, since they are programmed to show up when they receive focus. This is a bug reported to Google, so hopefully they’ll fix it soon.

But shouldn’t it still be possible to use the link, even though it’s visually hidden? Sadly, that’s not possible. If you click on a hidden link with TalkBack, the link will not be activated. So, we guess that Google will need to fix this focus issue before skip links will work at all on Android.

Interesting enough, some Android phones have a version of TalkBack called VoiceAssistant. With VoiceAssistant, skip links work exactly as intended!

What can you do?

Solving this bug is mostly up to browser and screen reader vendors. So we hope you’re listening Google, Apple, Mozilla and the rest.

But there are some things you as a site owner can do while we wait for a more robust solution.

We created and played around with this codepen where you can test skip links that reference different types of elements like headings, <main> ,<div>, and more. We found cases where including the attribute tabindex="-1" on the element you reference would solve the issue, but unfortunately only for iOS users. Here’s how:


Skip to main content

//Menu and other stuff users might want to skip
...

…

So simply adding tabindex="-1" to the element you’re skip link points to is the best solution we can offer at the moment. It won’t make your skip links work for all your screen reader users, but at least you’ll have catered the needs of the majority of them.

See update 3 below for problems with this solution and other, better ways to solve this

Update 1 – a better solution!

A lot of clever people read our articles, and it turns out that there’s an even better solution. Paul J. Adam (@pauljadam) uses javascript to move focus to the first heading. Like this with jQuery:


$('#skip-link').click(function(e) {
e.preventDefault();
$(':header:first').attr('tabindex', '-1').focus();
});

It works splendidly! Check it out on Paul’s website.

Update 2 – Vanilla javascript solution

Ben Buchanan made a regular “vanilla” javascript solution from Paul Adam’s solution above, since many people don’t use jQuery. And he was also kind enough to share it with us and the world, so here it is:

Codepen – Working skip links using vanilla JS

Mike Foskett also made a really nice Codepen:

Mike Foskett’s skip links codepen

Update 3 – A comment from gov.uk

Anika Henke e-mailed us some great input:

I’m a developer working in the accessibility team at GDS (the people behind gov.uk).

I was made aware of your article about skip links and that it mentions gov.uk.

We investigated the very same issue on gov.uk last year and I created a bug report for the iOS issue as it’s clearly a browser or screen reader bug.

Your suggested solution introduces worse barriers, though. See our Pull Request about removing tabindex from main to understand why. To quote:

“When clicking anywhere in the page focus will return back to the top. Consider a user interacting with an input field who clicks away from it to remove the focus style. Should they then hit tab they will be taken to the top of the page.”

The JavaScript solutions are a bit better because they focus on a smaller element. But it is too specific. It is dependent on certain elements or IDs being present.

Since ages I’ve been using a better fix in my personal projects which fixes all in-pages links, not just skip links, and removes the tabindex the moment the focus moves away.

Thanks for that great input Anika!

Hand tremors and the giant-button-problem

Hampus Sethfors — Mon, 09 Apr 2018 07:37:36 +0000

In this article we’ll examine an overlooked accessibility problem that mainly affects users with hand tremors. It’s in almost every interface out there, but barely ever highlighted in accessibility guidelines or discussions. It’s also super easy to fix!

We’re writing this together with Erik Zetterström of ICT Enablers. Erik has worked with accessibility products, services and standardization since graduating in 2003, with a Master of Engineering in Computer Science. A few years ago Erik was diagnosed with Parkinson’s disease.

Have you ever clicked something by accident? Most of us have. Maybe as you tried to scroll on your smartphone while on a bumpy bus, train or car ride? Annoying, right!

For a lot of people with hand tremors – caused by for instance Parkinson’s disease or essential tremor – unintentional clicks happen all the time. Especially while scrolling on a touch screen.

If you think about it, touch screen scrolling requires a lot of fine motor control. You need to place your finger on the correct part of the screen, flick it at the right speed and in the right direction, and most importantly: keep it on the screen at all times during this gesture.

Oops! I clicked it again

Many web and app interfaces are designed in a way that causes big problems for users who have a hard time with this scroll gesture. Luckily, there are simple ways of making your interface more hand-tremor-accessible. Let’s dive in!

A lot of sites and apps contain lists of clickable things, for instance products or news articles. These are usually placed back-to-back, with no space between the touch targets. Like this:

Here is a video showing a user with Parkinson’s disease trying to scroll through such an interface during a user test we carried out a while ago. He speaks Swedish, so turn on the captions if you’re not one of the 10 million people who understands our fine language!

If you look closely, the user is trying to place his finger between the news stories. He’s hoping the space is unclickable, so that an accidental tap while trying to scroll will not activate a link. However, every part of the screen is linked. It’s like the whole interface is one giant button – hey what a clever comparison, let’s add that to the title of this article!

Here’s a quote from the video that explains the essence of it:

They should add some space between the different objects so that I can put my finger down without activating something.

– User with Parkinson’s disease

The simple solution

It would help enormously if there was just a little bit of space between each touch target in the list. Like this:

Now users can place their finger in that unclickable space and accidentally tap without flying off to another page. A little space between the touch targets also makes the interface feel less crowded. Win-win!

This is how it looks on our site, scrolling through our articles. Not too shabby, right?

Hey browsers! You can help out too

Another way of solving this scroll-conundrum would be for browsers to make it possible to have a scrollbar visible at the side of the screen on mobile.

The scrollbar could be activated through the browser’s settings menu – or in some other smart way – so it doesn’t have to show all the time for all users.

But wait! Why isn’t this in the accessibility guidelines?

We don’t know. The Web Content Accessibility Guidelines (WCAG) do not include this problem. We can only speculate as to why. It might be because:

Touch screen scrolling has only been around since the smartphone revolution, like ten years. Seems like long enough, but the WCAG is a standard and standards move at glacier speeds. The 2.0 version WCAG was released in 2008 and it’s not until the summer of 2018 – ten years later – that WCAG 2.1 arrives.
There’s a lack of knowledge about accessibility issues that affect users with motor impairment.
The WCAG is primarily focused on vision impairments and assistive technologies. Motor impairments are sadly not covered as well, which they’re trying to change but not succeeding with. For instance, for a long time it was looking like they would add a minimum touch target size criteria to the new 2.1 version of WCAG, at level AA. But sadly, last minute this criteria was bumped up to level AAA, basically meaning nobody will care about it since all legislations and requirements are concerned with level A and level AA.

Whatever the reason, the lack of focus on motor impairments in accessibility guidelines is a big problem that needs to be addressed. Hopefully the folks working with the 3.0 version of WCAG are listening!

Also, this illustrates the point we make time after time: you need to user test with people with disabilities. No checklist or guideline will ever be able to replace meeting actual users and watching them use your product (tell us if you need help with this).

Let’s make the web more hand tremor friendly

Thanks for showing an interest in accessibility by reading this article. Hopefully you’ll help out in making the web a little more inclusive. Make sure there’s some unclickable space on each screen, it’s as simple as that!

Do you need help with your project?

An embedded accessibility consultant can join your design or dev team to continuously test with real users and guide accessible solutions from prototype to launch

If you liked this article, here are some others you might enjoy:

Text Splitting Causes Screen Reader Problems

Daniel Göransson — Sun, 04 Mar 2018 15:41:18 +0000

I am a screen reader user, and I am annoyed! I repeatedly encounter the same problem on websites. It’s about text splitting up. Let me share my agony with you!

The problem

First a short background if you’re not familiar with screen readers. When navigating a web site on a touch screen, my screen reader – VoiceOver – will read what’s under my finger. It enables me and other people with visual impairments to use technology.

What I should hear when touching a link with my finger is:

The name of the link.
What type of element it is: “link”.

For instance: “Contact information, link”.

However, sometimes I just get to hear what type of element it is, not it’s name. Just “Link”. Not very helpful.

The 16 second video below is from a Swedish site, but I think you’ll get the point even if you don’t know Swedish.

Notice how it just reads “Link” if my finger is on the right side of the elements – a bad user experience. If I touch the left side of the links, I get to hear the names together with the type of element – a good user experience.

What’s going on here? Well, let’s take the last link in the example above. It’s made up of two parts: The name “Arkiv” and the link icon.


   Arkiv

In the code, the icon is placed in its own span-element. A perfectly fine way to code your links. It should be read as one object, as the link-element is wrapping both the link name and the icon-span.

But VoiceOver interprets it as two different objects if I touch the right span, rendering me confused.

OK, so Apple should fix this?

Yes, I wish. But I reported this error in 2012 and it’s still not fixed, so my hopes aren’t great. While we wait for Apple, there’s an easy workaround for developers to fix this on your sites.

The solution: role=”text”

We had a similar problem on our site with headings, but the solution I used will work for links as well. Let’s look at it.

Here I’ve got an h1-element that looks like this in the code:

Digital accessibility, 

for everyone.

As you can see in the video below, the br-tag causes the screen reader to interpret the title as two separate objects, just like the span did in the previous example. I want it to read the whole heading to me at once.

So to force a screen reader to interpret the heading as one object, I wrapped the text inside the heading in a span and added role=”text”.


  Digital accessibility, 

    for everyone.

And voilá, here is the result:

Beware! Don’t put role=”text” in the heading-element. This would erase the h1-semantics, so it would not appear as a heading in a screen reader. Every element inside the role=”text” will lose it’s semantics. So you need to add a span within the element and put role=”text” in that span.

Apple, if you’re listening, please fix this. But until then, developers, please do the visual impaired community a favor and check your elements with a screen reader and fix them if necessary.

Update – questions and answers

This post went a bit viral! Which is great, but I’ve gotten a few questions that I want to clarify.

Can’t we just use aria-hidden on the icon?

Yes, we can, in some cases! In my first example, the link-icon is unnecessary to understand the purpose of the link, so you can just use aria-hidden=”true”. But we’d like the recommended technique to work in as many scenarios as possible.

So imagine the following case. You have a link or heading with three words, where the middle one is stylized. For instance:

Buy t-shirts now

Here, VoiceOver would announce them as separate links: “Buy link”, “t-shirts link”, “now link”.

Now we can’t use aria-hidden since that would hide a word for the screen reader user. It would just say “Buy now link”, skipping the t-shirt part.

However, using the role=”text” technique will work great in this scenario as well.

Is this just a problem with explore by touch?

To navigate with a screen reader you can either touch parts of the screen and have the objects you’re touching read to you – explore by touch – or swipe your way across the interface from object to object. I use explore by touch in my videos.

One person asked if this problem only occurs if you explore by touch.

However, sadly it happens both on explore by touch and when swiping.

Why don’t you keep writing to Apple?

Apple have actually answered me. They think this is a feature. It makes it possible to recognize that different words are styled in different ways.

I think it’s a nice thought. But in reality, it’s not practical. For us screen reader users, it’s more important to get the whole sentence read than to recognize that something has a different styling.

One idea would be to make the styling differences clear in some other way, like changing the pitch of the voice.

Assistive Technologies – The Switch

Hampus Sethfors — Mon, 19 Feb 2018 14:26:53 +0000

A switch is an assistive technology primarily used by people with motor impairments to access and control computers, smartphones, electric wheelchairs, smart home appliances and more. Let’s look at some switches in action and go through how you design switch friendly interfaces.

So what is a switch?

At its core, a switch is simply a way for a user to activate a control. This can be done in multiple ways, and different users prefer different switches.

The classic example of a switch looks like a big round button:

This type of switch can be placed in the users’ hands, by their head, elbows, feet or wherever they feel most comfortable with it.

On the screen, there’s usually a focus indicator moving automatically across the different objects, and the user clicks by activating the switch. Some users have multiple switches and can use one to move the cursor forward and another for clicking.

Video editor Christopher Hills has multiple switches placed on his head rest. Here’s a video where he shows how he uses his switches together with Apple Switch Control.

World famous theoretical physicist Stephen Hawking used a handheld switch, or “clicker”, earlier in his life. But as his control of his hand muscles decreased due to his Amyotrophic lateral sclerosis (ALS), he now uses a “cheek-switch”. If you look closely, you can see it in the video below. It’s a black sensor just below his glasses. So he moves his cheek to activate the switch.

On Stephen’s screen, a focus cursor will move across his computer’s interface automatically, and he moves the cheeck-sensor to activate the object in focus.

Most operating systems integrate with switches right out of the box, with no need to download special software or apps. For example, Apple devices have a setting called Switch Control (Settings, General, Accessiblity, Switch Control) and Android devices have Switch Access (Settings, Accessibility, Switch Access). You can use a Bluetooth keyboard with an iOS or Android device to try it out yourself. Or buy a switch, the cheapest ones cost around € 100.

Another type of switch is a “Sip-and-puff”. In this case, the users activate the switch by either inhaling – sip – or exhaling – puff.

Usually these types of switches come with a lip-controlled joystick that moves the mouse cursor on the screen.

Here’s how one of those products look, the Integramouse:

Not only people with motor impairments use switches. Some people with intellectual or learning impairments can find keyboards or game controllers too complex. They use switches to play simple games, communicate using digital boards or quickly access their favorite sites.

How to design switch-friendly interfaces

Here are some things for developers and designers to think about when designing digital interfaces for switch users.

Make your interface keyboard accessible.
That is, make sure you can control it only using the tab, space and arrow keys of your keyboard. If that doesn’t work, then switch users most likely will run into trouble.
Place key information, buttons and links “above the fold” – visible without scrolling.
Scrolling usually requires a lot more time and effort for switch users. With iOS Switch Control, a user needs to activate the switch seven times to scroll: 2 clicks to see the interaction menu, 3 clicks to navigate and activate the scroll and 2 clicks to remove the menu.
Don’t require hover, click-and-drag or other advanced gestures.
Although most switch interfaces have functionality for these gestures, they take a lot of effort to carry out and many less tech-savvy users will not know about them.
Use a large text size as default.
Many switch control users physically can’t lean close to a screen to read tiny, italics text.
Avoid time limits.
It will take most switch control users longer to complete a form or navigate your interface. So avoid using time limits. But if you do, make sure to give the user a way of increasing the time and give them a warning long before time’s up.

There are – of course – more things to consider when creating switch accessible interfaces, but I think that is enough detail for this introductory article. Get in touch if you want a more complete checklist on switch accessibility: [email protected]!

Want to experience assistive technologies like screen readers, switches, and eye-tracking in action? Sign up for our interactive accessibility workshop!

Hope you learned something new! Thanks for reading and leveling up your accessibility know-how!

Title Texts Suck

Hampus Sethfors — Thu, 08 Feb 2018 15:15:51 +0000

Many people I meet think title texts, also known as tooltips, improve both the accessibility and usability of their sites. They don’t. In fact, they can even cause problems. Let’s see why!

What’s a title text?

Here below is a link with a title text. Hold your mouse pointer over it for a while and a small text will pop up. That’s the title text. It’s added with the title-attribute in the link.

Demo link with title

This is how it looks:

“Wait a minute” a lot of you will be thinking. “I’m on my phone, I don’t have a mouse pointer.” Great observation! It brings us perfectly onto our next topic…

The problem with title texts

1. Title texts don’t work on touch screens

Title texts only show up on hover, and you can’t hover on 99.9% of all touch screens. I think most people would agree that a design pattern that doesn’t work on touchscreens kind of sucks.

2. Title texts cause problems for screen magnifiers

For users with screen magnification, title texts will often be somewhat of a bully. The title text can be cut off the screen because the user is zoomed in so far. When the user moves the mouse pointer to be able to see it, the title text will often disappear. More on this in our article How to make your site accessible to screen magnifiers.

Another problem for users with screen magnification is that the title text can cover essential parts of the content. In the example below the title text for the image covers the link below it.

You might be thinking: “Well, just move the mouse cursor.” Sadly it’s often not possible for users who are zoomed in very far and need to have the cursor where they are reading.

As icing on top of the cake for this group of users, title texts will not be enlarged when you use browser zoom (control +). So yeah, title texts really suck for people with visual impairments.

Apart from not working on touch screens, title texts don’t show up for users who navigate with the keyboard or with the many assistive technologies for users with motor impairments. There are ways to make the title text show on keyboard focus, but it’s not there by default and almost no developers will add that feature.

4. Title texts require users to guess

There is no way to tell if a link, icon, form field, button or other element has a title text before hovering over it. Most users will not bother to waste energy hovering over something to possibly get help. In the words of usability guru Jakob Nielsen: the interaction cost is too high.

5. Title texts require users to wait

Not only does the user have to guess if there’s a title text, they also have to wait a second before it possibly shows. Users are usually in a hurry when navigating the web, so most won’t stop and dwell.

6. Screen readers read title texts inconsistently

Many users with visual impairments use screen readers to navigate the web. Some screen readers will read title texts. Some will not the read title texts. Some will pause before reading them. Some have a setting that the user can enable to read them, but most will not know of that setting or bother activating it.

The point is, title texts are handled differently and you can’t rely on how it’s conveyed to the user.

Don’t trust me?

David Ball of @silktide wrote this nicely researched piece on the same subject a few years ago:

I thought title text improved accessibility. I was wrong.

He asked html-expert Jeffrey Zeldman on his thoughts on title-texts.

@silktide No! Do not use.

— zeldman (@zeldman) December 12, 2012

Web accessibility guru Bruce Lawson isn’t a fan of the title-text either:

@silktide kill it with fire. Or, as Bim, a blind screenreader user with RNIB would say: http://t.co/y6tN6UZU

— Bruce Lawson (@brucel) December 12, 2012

Also, here’s another nice article on title texts: Don’t rely on the title attribute for accessibility.

What should I use instead of title texts?

Well, just make sure your link and button names clearly describe where they take your user and you’ll be fine. Also, write text labels for your icons, then you’ll not need to worry about title texts.

Don’t confuse title texts with alt-texts. Alt-texts are very important and don’t suck at all:

Alt-texts: the Ultimate Guide

What about iframes?

Some accessibility experts say there’s one exception where they recommend using the title text: iframes. First off: don’t use iframes unless you really have to. They can really confuse screen reader users.

But if you use them anyway, just add an aria-label that describes the iframe’s content instead of the title attribute and this conundrum is solved.

Other things that suck

This was our third article on the topic of things that suck. You should check out our other two master pieces:

Disabled Buttons Suck

Captchas Suck

Hope you enjoyed!

Paying Employees to Work on Open Source Projects

Hampus Sethfors — Thu, 18 Jan 2018 09:41:11 +0000

Open source is awesome and even though we’re a startup we’ve found a way to pay our employees to contribute to the community. Here’s how and why we do it.

Photo: Samedaypapers

We, like most other companies that build software, base a lot of what we do on components and frameworks that were built in open source projects.

Even though we are a small (but growing) startup – five employees at the moment – we wanted to find a way to actively contribute to the open source community. We were inspired by how Futurice sponsors free time open source activities, and set up our own version of it.

The deal

As an employee at Axess Lab, you get paid 15 € an hour for up to 10 hours a month for open source work if:

It’s done outside of working hours
The project or task is related to accessibility, inclusive design or something similar

The employees have a time code in our time reporting system where they report the open source work and add a copy to a relevant pull request or commit.

That’s it. We don’t make it more complicated than that.

What’s in it for us?

Why would a startup like us do this. Well, we see many benefits:

It makes our employees even more skilled at accessibility.
It’s a good way to give something back to the open source community
It increases our chances of recruiting great people to our company
It aligns with our company’s vision of creating a more inclusive digital world
It makes our employees happy

Want to know more?

Hopefully this will inspire some other companies to set up something similar.

If you want to know more, get in touch with us by mailing [email protected] or tweeting @axesslab.

You’re extra welcome to message us if you live in Sweden and are interested in working with us to make the digital world more accessible!

Our Top Articles 2017

Hampus Sethfors — Fri, 29 Dec 2017 12:01:13 +0000

It’s been a great 2017 at Axess Lab! We celebrate by listing our most popular articles all year.

The podium

Here are the top three. Congratulations!

Accessibility According to Actual People with Disabilities
43 000 page views
“If you have a disability, what’s the hardest thing about browsing the web?” We sum up the answers to a viral Twitter thread.

How Icons are Ruining Interfaces
18 300 pageviews
More and more designers are using icons in the wrong way. And it’s hurting both the usability and accessibility of interfaces.

Alt-texts: The Ultimate Guide
15 200 pageviews
Practical tips on how to craft the perfect alt-texts. We also go through when to – and not to – use them.

Happy losers

Here are some articles that fought hard but just missed the podium. Ouch!

Disabled Buttons Suck
Showing buttons as disabled might seem like a good idea. It is not. Here’s why disabled buttons suck and what to do instead.

Fonts Don’t Matter
If you’re an art director, you might want to sit down for this. Here’s why fonts are overrated and what actually matters for readability.

Top 7 Free Color Contrast Checkers
Seven great free tools that help you measure color contrasts and create beautiful, accessible color schemes

Practical Examples of Accessibility Improvements

Hampus Sethfors — Thu, 28 Dec 2017 16:33:08 +0000

“It would be great to see actual examples of accessibility in action. Like before and after accessibility improvements.” I got this great comment from a woman in the audience at a meetup. So let’s make that idea a reality!

Offer alternatives

Accessibility is a lot about offering people alternatives.

Here’s an example from “real life”. When I was user testing with people with disabilities, this slider proved to be an obstacle for people with motor impairments. It was difficult to set it to the specific value the users wanted to.

We solved it by offering an alternative. Users can now either use the slider or input the numbers directly in the input fields.

This turned out great for mobile users as well. Their fingers were previously covering the value under the slider as they were adjusting it. Now they could see it above the slider in the input fields as well. A win for everyone.

Here are some other examples of offering alternatives to users:

Instead of forcing people to call customer service, offer an alternative to write in a chat or email.

Instead of forcing people to understand a diagram, offer an alternative to see the data in a table:

Instead of forcing people to read an article, offer an alternative to watch a video:

Note that it’s the combination of alternatives that’s the key. Not just a video or just text, but the combination of them. Let the user choose!

Colors

There are two main things to keep in mind when it comes to colors and accessibility: color contrasts and not relying solely on color.

Color contrasts

Good contrasts between text and background is important to make your content accessible to low vision users, or users who have sunlight reflecting off their screens.

Here’s an example of light gray text on Squarespace that doesn’t fulfill the contrast guidelines in the Web Content Accessibility Guidelines (WCAG):

A normal contrast failure is for link colors. Mediatemple have links that are far from acceptable:

To give you a feel for how little it takes to make your contrast sufficient, here is an example of failing contrasts for both the gray text and blue link, and an example of sufficient contrasts for the gray text and blue link.

You wouldn’t believe how hard I sometimes have to fight with art directors to get them to increase the contrasts to an acceptable level. Even though – in my view – everyone benefits and there’s not that big a difference aesthetically. Or is it just me?

Anyway, it’s easy to measure contrasts yourself. Here are some free contrast checkers we recommend!

Don’t rely solely on color

Some people with color vision deficiencies can’t tell different colors apart.

Here’s an example that would create problems:

Simply labeling your colors is a way to make color pickers accessible:

A common fail to this criteria is links that are only blue:

Viewing this in grayscale makes it clear why this is important:

Some ways to make your links pop out is underlining them, giving them link icons or making them look like buttons:

If you want to know more on this subject, check out our article on color blind accessibility.

Keyboard accessibility

Some users with motor impairments navigate using their keyboard. Many assistive technologies like switches, magnification and screen readers also rely on keyboard accessibility. But what does it mean to make your site or app keyboard accessible?

Focus indication

Make sure that it’s clear which element has focus when tabbing around in your interface.

The default focus indicator varies between browsers, but it’s often not very easy to spot.

Some sites, like Only.in, have even removed the default focus indicator. Most likely because someone googled how to remove it because they thought it looked ugly when focus was on their search field.

On gov.uk focus is indicated with an orange background that really stands out from the surrounding:

So design a clear focus indicator and implement it using the :focus selector in your css.

Skip-links

Skip-links are a bit magical! They don’t show up for most people, but if you navigate with a keyboard you’ll find them very helpful.

They are made visible only when they receive focus and basically provide a shortcut past all the links in the site header and menus, so you quickly can get to the content of the page.

Here’s a skip-link in action at www.starbucks.com.

Try it out yourself by going to Starbucks and pressing the tab key on your keyboard until you see it (in any other browser than Safari, where keyboard navigation first needs to be activated in settings for some reason).

Making your site or app accessible for users with visual impairments who use screen readers is a lot about coding correctly and following the html-standard. For example: instead of building buttons and links out of spans, use the button and link elements.

Another thing you need to do is add alt-texts to images, which conveys their meaning to people who can’t see them. Editors need to learn how to do this in their Content Managment System. It takes about 5 seconds for each image.

You should check out our Ultimate Guide to Alt-texts!

Accessibility is a lot about simplicity and usability. Make your interface intuitive and use a clean layout and you’ll help all users, including screen reader users.

Sometimes online shopping is more accessible than health care, simply because e-commerce sites focus so heavily on usability and streamlined design.

Wrapping it up

There is of course more to accessibility than I’ve listed above. But the point is that it’s not rocket science. Also, making your site or app accessible does not mean you have to make it boring and remove all colors, images and videos.

Accessible sites can – and should – be made awesome and beautiful! If you want our help achieving this in your projects, let’s work together!

Finally, I’d want to recommend the world’s best tumblr:

a11ywins.tumblr.com

It’s a collection of accessibility wins – that is, examples of awesome accessibility solutions on sites and apps. Jump over there and read it all!

“Our Users Have no Disabilities”

Daniel Göransson — Sun, 17 Dec 2017 11:45:08 +0000

There are a lot of unfortunate misconceptions about people with disabilities. Many trickle down into IT-teams who use them as arguments not to care about accessibility. So it’s time to set some things straight!

Things we hear all the time

When we at Axess Lab are out consulting or speaking about accessibility, time and time again we hear the same types of arguments from people who are not very keen on focusing on accessibility:

I work on an intranet. We don’t have disabled employees.

Our customers are athletes, not handicapped people.

I’m building a site for this upcoming movie. Obviously, blind people are not part of my target audience.

The many, many people who think or say these kinds of things probably don’t do it because they are pure evil! Instead, the comments are likely to stem from a lack of knowledge and preconceived ideas about disabilities.

So, let’s bust some myths and straighten this thing out once and for all!

All disabilities are not visible

Most of the time, you can’t tell if a person has a disability just by looking at them. Even though you might not think you have colleagues or users with disabilities, you probably do. Here are some disabilities that usually are hidden:

Autism
Adhd
Hard of hearing
Dyslexia
Color vision deficiency
Chronic pain
Mental illness
Many more

Even some disabilities that you think are visible are not always. I am legally blind. If I don’t chose to tell people, they usually have no idea. Just by looking at me, there’s no way to tell.

Here I am, roller skating!

So guess what! You’ll probably pass a lot of people today that have disabilities, but you won’t even notice!

And me roller skating leads us nicely onto the next topic…

People with disabilities have interests too

There are a lot of preconceived ideas about what people with disabilities do. We do everything. Or nothing. Or exactly what we want to. And we want different things, just like everyone else.

Some of my favorite interests are:

Video games – not special games for special people. Right now I’m playing Tekken 7, accessible to me through great sound design and contrasts.
Sports – I both like to watch sports and play it myself. I play a type of soccer that involves eye shades and sounds. Here’s a link to the best goals in the 2016 Paralympics.
Movies – Contrary to popular belief, many blind people enjoy movies. I use a combination of the little sight I have and audio descriptions that describe what’s happening, like who’s beating up whom in a fight scene.

I have friends who are blind. Some hate sports and don’t do video games. Some love them like me. I know people with hearing impairments that love music, theatre and musicals.

The point is we are different and have many interests!

This means that we buy soccer shoes, book movies tickets and hang out on video game review sites. And skateboards!

So let’s agree on that you can’t assume that their target audience has no disabilities. We are everywhere!

Young people have disabilities too

Many people tend to believe that disabilities is something that only elderly people have. It’s true that many disabilities are more common among the older population. But not all.

Think of dyslexia, color vision deficiency, autism and adhd. They are just as common in all age groups. And there are, of course, young people with disabilities like vision and hearing impairments, even if they are more common among elderly.

We would also like to congratulate you, our dear reader. You’ve just set a personal record! You’ve never been older than you are right now! And you’re getting older every day. Design for your future self!

Employed people have disabilities too

One of the most common situations where we hear excuses for not caring about accessibility is when it comes to intranets, administrative systems or any other system that is used by professionals. There is a widespread misconception that people with disabilities don’t work. At least not at your own office.

This, of course, is false.

People with disabilities can be found at any workplace. Sometimes you don’t know about it, because many disabilities are hidden. But trust me, we’re there!

And even if you don’t have a colleague right now who is, say, blind, that doesn’t mean you can assume you never will.

Let’s say a highly qualified individual is applying for a job. She’s better than all the competition and would be perfect for the position. However, she happens to use an assistive technology. And your intranet and administrative systems are not accessible at all. Because of that, she can’t do her job and you hire someone else.

In that scenario, apart from the terrible discrimination, you also lose a great recruitment.

So don’t just make your external website accessible. The inside counts as well!

You can’t know your user’s environment

Impairments can be situational. A user without a disability could be stressed, tired, drunk (maybe not for intranets..) or using their device in sunlight. Anyone could be riding the subway on a poor internet connection. All users have disabilities sometime in their day-to-day life.

In web analytics, there is no good way of examining if the visitor has a disability or is using an assistive technology. So you can’t know if a user is using a screen reader or an eye tracker to navigate. So even if you know that over 90% of your users are using a large screen, you can’t assume that everyone is using a mouse. Which in turn means you can’t rely on hover to navigate.

Tech enables

Digital services like apps and web are often more important to people with disabilities than the so called average Joe out there.

Let’s look at an example. Stephen Murray crashed on his BMX-bike and was paralyzed from the neck down. He now uses an eye tracker to control his technology. He runs his own company, pays his bills and communicates with friends and family, all by only using his eyes. Tech has enabled him to do all this, and to be independent again.

But Stephen Murray is also very reliant on the accessibility of the services that he uses. More so than most other people.

Say you want to book a meeting room. If the booking system is a piece of paper by the meeting room, most people could use it, even if it would be a bit annoying not to be able to do it from the computer.

Stephen wouldn’t be able to book it at all independently. The same goes for other people with disabilities, like someone in a wheelchair who might not reach the paper, someone with a hand tremor who can’t write with a pencil or someone with a vision impairment. An accessible digital booking solution is crucial fort these users, but benefits everyone.

One last tip

Now you’re hopefully equipped with enough arguments to convince your colleagues and bosses to prioritize accessibility. People with disabilities are everywhere and inclusive design is important for everyone. No matter what prject you’re in

Here comes our last tip! The best way to get empathy and understanding from someone is to let them experience accessibility issues themselves. One way is to get Funkify – the disability simulator, a free Chrome extension that we’ve been a part of building! Another way is to let us meet your team. We’ll let you use your site or apps with screen readers, magnification, eye control and a lot more. An empathy lab that will convince even your most stubborn colleague!

Thanks for reading and keep on spreading accessibility awareness!

5 Ways to Make Your App More Accessible

Guest — Tue, 21 Nov 2017 08:10:44 +0000

Users spend a large portion of their days in apps. However, there is not yet as much focus on app accessibility as web accessibility. It’s time to change that!

This is a guest post by Bryn Gelbart from Fueled, who builds apps with accessibility in mind.

Why care about app accessibility?

One billion people, or about 15% of the world’s population, live with some form of disability. Combine that with the fact that smartphone and app usage is booming in all parts of the world, across all ages and abilities. This means that in order to truly maximize the impact, reach and profit of your mobile app you need to make sure it is easy to use for people of all ability sets. It must be accessible.

An app can do this by addressing the core accessibility checklist that the Web Accessibility Initiative puts forward. But if you don’t have time to read through the long checklist, here are five practical ways to improve your app’s accessibility.

1. Design for colorblindness

Approximately 8% of men and 0.5% of women are color blind according to visiontechnology.co. This comes close to 300 million people worldwide, a majority of those being caucasian men. That can be a bigger issue than you think considering the demographics of the tech industry.

A core accessibility principle is to not rely solely on color to convey meaning. Don’t just make error messages red. Also add an error icon to make it clear to everyone.

It is imperative to use easily distinguishable colors. Avoid mixing green and red, as that is the color combination that most people with color blindness can’t tell apart.

You must make your backgrounds pop from your foregrounds, so no crucial information is lost on the color blind user. For example measure contrasts and make sure they comply with the color contrast threshold in WCAG (Web Content Accessibility Guidelines). Also, don’t have too similar hues of the same color, as this is likely to be seen as the same by many colorblind users.

The screenshot from Candy Crush Saga below uses distinct shapes and varied shades to cater to colorblind users:

2. Provide captions and alternative text

Captions for video are essential for users with hearing impairments. Providing this alternative also benefits all users, as closed captioning can be useful in many situations, including commutes and while using your device in loud environments.

Additionally, people who rely on text-to-speech voice technology are a demographic to consider when talking about accessibility. All photos and icons should have alternative text that can help all users get the full experience.

To add this alternative description to images and icons in apps, refer to these guides provided by Google and Apple:

Android Accessibility
iOS Accessibility

In short, for Android use android:contentDescription and for iOS use the label attribute.

Another good guideline is to complement icons with text. That way, it’s more clear to everyone what the icon means. In the Remente app, each icon for feeling is complemented with a number from 1 to 5. Also, the thumbs up and thumbs down icons have a label “Negative” and “Positive”.

3. Readable and distinguishable interface

Making sure displays on your app are easy to see goes beyond proofing for colorblindness. Giving your text a strong brightness-contrast and using larger font sizes is a good place to start.

It is also important to differentiate clickable content. Hyperlinks and buttons that take the user to other screens should be both colored differently and highlighted with non-color characteristics, like a border on the button, a link underline or a link icon.

Also, keep formatting consistent. Users with cognitive limitations may become confused if components are formatted differently on different pages.

4. Be aware of seizure inducing elements

According to stats from Healthline, about one in every 26 people will experience recurring seizures in their lifetime. The causes range from epilepsy to other less common conditions that can come into effect without prior warning or experience.

Avoid putting in features that frequently flashes on the screen or makes use of the camera flash on devices. Alternating colors or patterns are a bad call as well. If these are features that you must include, provide a warning and an option to disable them.

5. Multiple language settings

While it does not fall into the same category as these other tips, it is important to recognize when your concept may be applicable to a non-English speaking audience. Translating all text is an easy way to expand your accessibility. On mobile these options will often be automatically changed based on user settings.

An additional feature for multilingual users could be a slick drop down menu built into the interface that can give language options from within the app.

Thanks Fueled

It’s nice to see more and more companies spreading accessibility awareness! Thanks Fueled for writing this post. And no, we didn’t get paid to feature this. We just like working together with people who work with accessibility in mind!

iPhone X – Welcome Screen Inaccessible to Blind Users

Daniel Göransson — Fri, 17 Nov 2017 13:25:05 +0000

I just got the new iPhone X. To my surprise, the first impression was not good at all for me as a user with a visual impairment. Apple usually don’t let me down, but now they seem to have made blunder.

Explain what happened in text, please!

Ok, so I use a screen reader that speaks information about the elements on the screen as I hold my finger over them.

The first screen was totally blank to me, I got no information on how to proceed. Visually, there is text there, but I can’t see it and it’s not read with the screen reader. So it doesn’t help me.

I couldn’t swipe across the screen to find elements to interact with, which I usually can.

After struggling a while I found an element at the very bottom of the screen that said: “Home indicator, dimmed. Swipe one finger up from the bottom of the screen to go home”. I tried it even though I don’t want to go to the home screen, but it was the only thing I could do. That led me to the installation process.

So I made it, but the experience was far from pleasant. I think many people with visual impairments will get stuck here and have to ask for sighted help, compromising their independence. Apple, hope you’re listening. Fix this please!

Captchas Suck

Hampus Sethfors — Thu, 02 Nov 2017 16:01:07 +0000

Captchas were invented to protect websites from spam. However, like the well-meaning invention of nuclear fusion, captchas too got some unethical and destructive side effects. Here’s why captchas suck and what to do instead.

Introducing the evil

Nobody likes captchas. They are at best an irritating, conversion-killing step users need to get past. At worst, they can be a complete roadblock to people.

I’ll share my true feelings towards captchas at the end of this article in a poem. Yes – a poem. I’ve heard poems are good for expressing feelings. Anyway, first I’ll be more objective and describe what they are and why they do damage.

Captchas are meant to tell humans and computers apart. The whacky name is an acronym for Completely Automated Public Turing test to tell Computers and Humans Apart.

They come in some different shapes and forms. Here’s one that everyone would struggle with:

Here is a captcha to sign up to a movie website, which – at least – is a bit whimsical!

Captchas are seriously inaccessible

Imagine that you’ve spent what felt like an eternity filling out a form. Finally you get to the end of it and find this question.

Prove you’re not a robot. Click on the animals in the image below.

You can’t see any animals, but luckily you find a give-me-a-new-challenge-button. You click it:

Prove you’re not a robot. Solve this simple math problem:

These may be silly examples, but it’s a pretty accurate experience of how many people with disabilities experience captchas.

For users who are blind or have visual impairments, these types of image-captchas are usually impossible to solve:

For users with learning impairments, a math problem like 21+42 can feel like a complex integral:

For users with dyslexia or other reading impairments, blurry images of squiggly text can be impossible to solve.

Here are some users – with and without disabilities – expressing their not so loving feelings towards captchas on Twitter.

https://twitter.com/megsiobhan/status/841296437153525765

https://twitter.com/krrnlyd/status/925985592160133120

@n5up I'm trying to contact you via web for ask a question but I can't 'cause I'm blind and I can't resolve the form CAPTCHA.Please help me

— EA3GZA (Miguel) (@ea3gza) August 22, 2017

https://twitter.com/thejoycean/status/822981228408274944

As to what drives her nuts, non-accessible captchas are the top. It can severely limit which services are available to her.

— Totally Not a Giant Bug in a Hat (@DannyDoesCode) June 3, 2017

Dear @Audible_com, introducing a CAPTCHA during iOS app login process is completely inaccessible and useless. #a11y

— Pratik Patel (@ppatel) March 25, 2015

Stupid captcha is blocking me from completing AWS registration!!! arghhh i hate captchas

— José Rodrigues (@jrocharodrigues) October 23, 2017

No, Google’s new ReCAPTCHA is not good enough

You might have come across the “I’m not a robot” captcha:

It’s not as bad as the standard captchas. But it’s still bad. People with assistive technologies like screen readers often report that they get classified as a bot and need to solve a regular, inaccessible captcha.

Here is a video of a screen reader user trying to get past the captcha and failing. Get ready for some quick robotic speech. It can be hard to understand what’s going on if you’re not used to it.

Also, here’s a robot beating a captcha

No, the audio alternative is not good enough

Many captchas offer an audio alternative. Try listening to the next one you come across and you’ll understand why it’s not good enough. It can be really, really hard to hear the message, since it’s got to be distorted enough that computers can’t figure it out.

Another problem with the audio captcha is that the icon to switch to the audio captcha is usually really small and difficult to find. Screen reader users also tend to struggle as the audio starts playing before they’ve found the field for inputting the text. Focus should be put on the field automatically, but usually isn’t.

A few years back, the White House had a CAPTCHA that prevented blind people to sign a petition for an international treaty that was supposed to help the blind. Here’s what they had to say about the audio captcha:

An audio code option — meant to help the blind complete the Captcha — is incomprehensible, according federation spokesman Chris Danielsen. And that same flawed audio code system is in use for people who wish to write the White House an email with any suggestions or complaints regarding the “We The People” site.

Captchas hurt conversions

So captchas exclude many users with disabilities. This should be the only reason you need to seriously question their existence. But let’s look at another serious problem: it’s a conversion rate killer.

Everyone struggle with captchas, not just people with disabilities. Many have conducted A/B tests and shown how they hurt conversion rates.

Webnographer conducted an online usability test where only 62 percent of users completed Captcha on their first try. 23 percent gamely struggled through multiple attempts before succeeding, but 15 percent gave up entirely.
– Do the new Captchas Affect Conversion Rates (pagewiz.com)

They ran the test until 99% confidence level was achieved. The form with a captcha converted at 48% whilst without it converted at 64%. A 33% increase in conversions!
– Web form optimization (acquireconvert.com)

So – not surprisingly – captchas will lower your conversions. That – to most organisations – means less revenue. Another awesome reason to seriously question captchas.

What to do instead

Throw it out

The first thing you should consider is to just not have a captcha.

Sifting through SPAM is irritating and time-consuming, but it’s better to get more SPAM and conversions than not to.
– Why Your Captcha is Killing Your Conversions (medium.com)

Having an accessible site with high conversion rate might be worth the spam.

Also, there’s something iffy and unprofessional about web site owners putting the burden of their spam problems on their users. Solve it “on your side” instead.

Don’t make users take responsibility for our problems.
– Beyond Captcha (sitepoint.com)

Replace the captcha with an accessible alternatives

There are ways to verify your users without using a captcha. Here’s one example that allows users to skip the captcha:

Check out these articles on Captcha alternatives:

9 Captcha Alternatives That Won’t Wreck Your UX (dtelepathy.com)

Not all of the 9 methods are accessible, so focus your attention on number 3 – “Biometric security”, number 4 – “Text message verification” and number 6 – “The honeypot method”.

Think Your Site Needs A CAPTCHA? (usertesting.com)

Same as with the previous article: not all alternatives they suggest are accessible. Focus your attention on “Honeypots”, “Timestamps” and “Verified sign in”.

A final poem to captchas

So here’s what I promised at the beginning of the article. Be advised, I haven’t written a poem since I was in the eight grade.

But I feel it’s time. I’ve got some strong feelings I need to express. No it doesn’t rhyme. And excuse the harsh language.

Anyway, here goes!

Dear captcha.

They say everyone is good inside.
But you are pure evil.
The dark side of cyberspace.
The Voldemort of the web.

So duck you, captcha.
Duck your squiggly faded tilted letters.
Duck you for making users squint and curse.
Duck you for excluding users with disabilities.

You inaccessible, abelist piece of sh….shoe.
A blocker to people with vision, reading or learning impairments.
You are to accessibility what cigarettes are to lungs.
You are technological discrimination

To be fair, you’ve made one accomplishment.
You improve spam robots’ letter recognition.
Maybe one day that can be used for something.
Other than ducking up people’s life.

Developers, web designers, user experience professionals.
You’re smart, creative, empathetic people.
Google “captcha alternatives”. Start questioning them.
You can do better than a captcha.

Trends That Exclude

Hampus Sethfors — Wed, 18 Oct 2017 12:04:41 +0000

Jumping on a new trend is risky business, both in fashion and web design! Here is why trends often hurt the user experience and exclude users with disabilities. I’ll also go through what you can do to avoid this from happening.

Trend #1: Bright and light

For a while now, it’s been considered modern to design things that are difficult to see. It’s a strange trend that’s causing problems for all sorts of users. Let me walk you through some troublesome bright and light trends out there.

Thin, small, grey font

Slim, tiny, grey letters are popping up in interfaces all over the web, forcing users to strain their eyes while reading. Companies like Squarespace are even winning awards for this kind of unsightly design:

Running this interface through the disability simulator Funkify, this is what the interface above looks like with blurry vision:

Not very pleasant, right?

Nobody likes to strain their eyes when reading, but this trend is especially hurtful to some user groups:

Users with small devices
People who are outside in bright sunlight
Elderly users
People with low vision

When asked what causes accessibility problems on the web (our full article: Accessibility According to Actual Users with Disabilities), quite a few people brought up this topic:

Nearly blind in my left eye. Tiny, thin font with low contrast to the background

— Andrew So (@AndrewDixonSo) 3 juni 2017

I know what you’re thinking: It’s Apple’s fault!

Yes, Apple introduced a thin font in iOS a couple of years back and they used grey text color a lot in their designs. However, they made sure the grey had a sufficient contrast level (how to check color contrasts) and the thin font wasn’t measured in nanometers.

The problem was that when other designers jumped on this trend, they made the grey color brighter and the letters thinner. Suddenly the text was only readable by designers with 52 inch retina displays and predator birds.

That’s why it’s so nice to hear that Apple is ditching it’s thin, grey fonts. Here’s a comparison between the old and new phone interface:

So Apple is moving away from the thin, grey trend. You should too.

Bright color schemes

Many users with disabilities struggle on the web because of contrast issues in trendy interfaces.

Lack of contrast between font color and background color. Photo backgrounds that overpower the text on top of them.

— Megan Lynch (@may_gun) 4 juni 2017

One common offender is white text on brightly colored backgrounds:

The color contrasts between the text and backgrounds above are terrible and far below the accepted contrast level in the Web Content Accessibility Guidelines (WCAG).

Like the tweet above said, another common contrast problem is when text is placed right on top of images, which is trendy now.

So start measuring contrasts and make your content easy to read for all your users.

Ghost buttons

Ghost buttons are transparent, thin buttons that have become popular lately. Like the name suggests, it’s quite a frightening design trend!

The background overpowers the important content, making the buttons harder to spot and read:

Make buttons stand out. It improves usability, conversions and accessibility. I think it’s time to stop scaring users away with ghost buttons.

Trend #2: Motion

Motion in interfaces is one of the top things that causes frustration when user testing with people with disabilities. It’s extra irritating for some people with cognitive disabilities, like adhd and autism.

ADHD: If there’s a “subtle” animation always running, I cannot focus. Biggest offender: https://t.co/KgfCA4a7lB‘s header gradient

— Taylor Hunt (@tigt_) 3 juni 2017

Assuming ADHD counts, it’s hard to locate content on overly busy pages and animations are a nightmare of distraction. #clickthemonkey

— mkb (@mojinations) 4 juni 2017

related, I’m also autistic and can get frustrated with, or repelled by, glitzy mouseover effects/animations, sudden autoplay, etc.

— back at the holler (@elementnumber46) 3 juni 2017

Let’s look closer at two motion trends that are annoying users: parallax scroll and image carousels.

Parallax scroll

Parallax scroll is a technique that became popular recently. To highlight how terrible this design trend is, I give it two poop-emojis instead of just one.

Don’t you just love coming to a site to realize they’ve hijacked your scroll wheel? So that when you scroll, strange things happen on the site.

You’re not alone in thinking that’s frustrating!

Here’s an example where animations start cluttering the interface as the user scrolls:

https://axesslab.com/wp-content/uploads/2017/10/parallax2.mp4

It might look cool at a glance, but after a few seconds it gets really annoying. Not many users like it and some even get seasick, especially people with balance disorders.

Try the madness yourself at parall.ax.

Image carousels

Image carousels is another motion trend you should avoid, and something that the user experience (UX) community has warned about for years. Sadly, there are still plenty of sites that use them, creating distractions for users who are trying to focus on reading the site’s content.

Why are carousels bad? I’ll let my favorite site on the web tell you the answer: shouldiuseacarousel.com.

In feeds all across social media platforms, we’re seeing posts that exclude users with low vision or reading impairments. Let me take two examples.

Images of text

“Hahaha check out this epic meme:”

Hilarious, right? Didn’t think so. The image is a meme that contains text, which will not be read by assistive technologies. So this is the experience many users with disabilities will get.

Some social media platforms like Facebook will automatically describe what images might contain (like TV and dog indoors) to users with visual impairments who can’t see the image. But this description will not include the text in the image. So if you post an image of text, you should describe the text in the actual post.

Let’s try it again:

“Hahaha check out this epic meme! Making my dog watch commercials of the homeless dogs so he knows how good he got it.”

Much better right? And more along the lines of the experience a sighted user has:

The text description will also help users with reading impairments who use assistive technologies to read text. These assistive technologies will not be able to read image of text, so writing the text in the actual post is very helpful.

If you’re interested in learning more about accessible images in social media, check out this article on accessible social media posting.

Videos with text only

An awesome trend that has started on social media is captioning videos. Facebook autoplays videos in your feed, and 85% watch videos without turning the sound on. So people have started captioning, which is great for everyone but crucial for hard-of-hearing or deaf users.

However, lately this nice trend has shifted a bit too far. Now many skip the soundtrack altogether and only write text in videos.

Here’s an example, in Swedish but you get the point:

https://axesslab.com/wp-content/uploads/2017/10/lxI7vf.mp4

This excludes users who have a severe sight or reading impairment who depend on a voice narrating the video.

So don’t just use text on videos. And don’t just use sound. Sound and text in videos are like pancakes and jam – awesome together!

Trend #4: Icons only

Icons without text labels have blossomed with the rise of smartphones. There is a major shortage of screen space on small devices, so the idea of replacing text with icons is obviously an attractive one.

However, icons without text labels require users to do a lot of thinking and it’s causing significant usability problems. I wrote a whole article on that topic: How Icons are Ruining Interfaces.

Apart from usability problems, the icons often cause specific problems for assistive technologies. When there is no text label, a screen reader user is dependant on the presence of a description of the icon in the code. This is not difficult to do for a developer, but many, many, many forget it. Then the screen reader will say something along the lines of: “Button 3” instead of “Button Play clip”.

A young girl with a vision impairment I interviewed a while back told me about how her favourite app had updated, and suddenly there were no descriptions of any of the buttons. She had to get sighted help and memorise patterns to be able to using it:

To start I press button 3, then 7, then 2. I change track on button 11. It’s difficult to find but I’ve gotten quite good at it!
– Screen reader user

Not a very nice user experience, right? So the icons-without-text-labels-trend is causing problems for all sorts of users.

Why, oh why, does this happen?

Here’s my theory as to why so many new trends exclude users.

Go to Google Images and search for “web designers”. You’ll get a lot of results like this one:

Young people sitting in front of giant monitors designing. This is how it looks in many tech offices around the world. Of course these people are not likely to react to problems with color contrasts or thin letters.

Almost anything looks good on such an expensive screen! However, the users’ reality is often a lot different.

Most designers and their colleagues are also very much more tech-savvy than the average person out there. Designers will often find new tech trends interesting, while most users just want interfaces to look and work like they’re used to.

What should we do about it?

Glad you asked! Here are my three best tips on reducing the excluding-trends-problem.

1. User test with a wider audience

I assume you already user test your interfaces. Otherwise start right away! But either way, make sure you recrute a wide range of users to your tests, for example:

Old people
People who are not fluent in your language
People with disabilities

User testing with these user groups is extra important when you’re considering jumping on a new trend, to spot potential accessibility issues. If you make sure your interface works well for these users, you’ll also make it easier to use for everyone. Win-win!

2. Train your team

The best way to create inclusive products is to educate yourself and your team on the topic of accessibility. Take a course and learn to see things from new perspectives. Make sure your developers know the techniques for coding accessibility into their interfaces, designers know how to check for contrasts and testers know the basics of using some assistive technologies. Accessibility is not a one man show, it’s a team effort!

3. Test with Funkify

We’ve created a free browser plugin, Funkify, that let’s you simulate different disabilities, right on your site. View your site through a blurry filter, try navigating with a trembling mouse pointer and more. It can help you evaluate your interface in your day to day work!

Here’s a demo of the plugin in action:

https://axesslab.com/wp-content/uploads/2017/10/Använder-Funkify.mp4

That’s all, folks!

Let’s work together to embrace inclusive trends that make the digital world a better place for all users!

Alt-texts: The Ultimate Guide

Daniel Göransson — Sun, 15 Oct 2017 16:44:25 +0000

This post contains everything you need to know about alt-texts! When to use them and how to perfectly craft them. By me, Daniel, a web developer with vision impairment who use a screen reader in my day-to-day life.

My experience of images on the web

I use a combination of magnification and screen reader when surfing the web. As a rule of thumb, I use magnification on larger screens and a screen reader on smaller devices.

I, like everyone else, come across many images when surfing the web. If I’m using a screen reader I depend on getting a description of the image – the alt-text – read to me.

Many times the alt-text is not helpful, often even a waste of my time because it doesn’t convey any meaning.

Let me illustrate this on The Verge’s startpage. This is what it looks like for sighted people:

Below is what I see. I’ve replaced the images with what my screen reader reads:

Not very useful, huh?

Here are some common alt-text-fails I come across:

“cropped_img32_900px.png” or “1521591232.jpg” – the file names, probably because the image has no alt-attribute.
“
” – on every image in the article, probably for improving search ranking (SEO).
“Photographer: Emma Lee” – probably because the editor doesn’t know what an alt-text is for.

Alt-texts are not always this bad, but there’s usually a lot to improve upon. So whether you are a complete beginner or want to take your “game” to the next level, here’s our ultimate guide to alt-texts!

What is an alt-text

An alt-text is a description of an image that’s shown to people who for some reason can’t see the image. Among others, alt-texts help:

people with little or no vision
people who have turned off images to save data
search engines

The first group – people with little or no vision – is arguably the one that benefits most from alt-texts. They use something called a screen reader to navigate the web. A screen reader transforms visual information to speech or braille. To do this accurately, your website’s images need to have alt-texts.

Alt-texts are super important! So important that the Web Content Accessibility Guidelines (WCAG) have alt-texts as their very first guideline:

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose.
– WCAG guideline 1.1.1

If you want a second pair of eyes, our WCAG accessibility review covers image alt-text quality and coverage.

Or, if you prefer hands-on help while you ship, embed an accessibility consultant from our team to review alt-text patterns as you design.

How do I add an alt-text?

In html, an alt-text is an attribute in an image element:

Most content management systems (CMS), like WordPress, let you create the alt-text when you upload an image:

The field is usually named “Alt-text”, “Alternative text” or “Alt”, but in some interfaces it’s called “Image description” or something similar.

Let’s create the perfect alt-text!

Here are the steps to crafting fabulous alt-texts!

Describe the image

It might sound obvious, but an alt-text should describe the image. For example:
“Group of people on a train station.”
“Happy baby playing in a sand box.”
“Five people in line at a supermarket.”

Things that do not belong in an alt-text are:

The name of the photographer. This is very common, but makes absolutely no sense.
Keywords for search engine optimization. Don’t cram alt-text with irrelevant words you’re hoping to rank high on Google with. That’s not what alt-texts are for and it will confuse your users.

Content of the alt-text depends on context

How you describe the image depends on its context. Let me give you an example:

If this image was featured in an article about photography, the alt-text could be something along the lines of:

“Close up, greyscale photograph of man outside, face in focus, unfocused background.”

If the image is on a website about a TV-series, an appropriate alt-text could be completely different:

“Star of the show, Adam Lee, looking strained outside in the rain.”

So write an alt-text that is as meaningful as possible for the user in the context they’re in.

Keep it concise

Reading the previous section, you might be thinking to yourself: “I, as a sighted user, can see many details in the image, like who it is, how it’s photographed, type of jacket, approximate age of the guy and more. Why not write a detailed, long alt-text so a user with visual impairment gets as much information as I do?”

Glad you asked!

Well frankly, you can also get the necessary information from the image at a glance, and that’s what we’re trying to achieve for users with screen readers as well. Give the necessary information in the alt-text, but make it as short and concise as possible.

One of the few times you should write long alt-texts is when you’re describing an image containing important text. Ideally, you should not have images of text, but sometimes you need to. Like on some screenshots or photos of signs.

But the general rule of thumb is to keep it concise and avoid a verbose experience.

Don’t say it’s an image

Don’t start alt-texts with “Image of”, “Photo of” or similar. The screen reader will add that by default. So if you write “Image of” in an alt-text, a screen reader will say “Image Image of…” when the user focuses on the image. Not very pleasant.

One thing you can do is end the alt-text by stating if it’s a special type of image, like an illustration.

“Dog jumping through a hoop. Illustration.”

End with a period.

End the alt-text with a period. This will make screen readers pause a bit after the last word in the alt-text, which creates a more pleasant reading experience for the user.

Don’t use the title-attribute

Many interfaces have a field for adding title-texts to images close to where you can add an alt-text. Skip the title text! Nobody uses them – they don’t work on touch screens and on desktop they require that the user hovers for a while over an image, which nobody does. Also, adding a title-text makes some screen readers both read the title-text and the alt-text, which becomes redundant. So just don’t add a title-text.

When not to use an alt-text

In most cases you should use an alt-text for images, but there are some exceptions where you should leave the alt-text blank. Important note: never remove the alt-attribute, that would mean breaking the html-standard. But you are allowed to set it to an empty string, that is: alt=””. Do that in the following cases.

Repeated images in feeds

Pretend you’re scrolling through your Twitter feed. Everytime you want to read a new tweet, you first have to listen to “Profile picture of user ”. In my opinion, that would be super annoying!

Other examples of feeds are:

A list of links to articles. Like the one on our page Articles.
Chat or messaging feeds
Feeds of comments

So for an ideal user experience, leave the alt-text blank for images that are used repeatedly in feeds.

Icons with text labels

You should always have text labels next to icons. Assuming you do, the icon should not have an alt-text. Let me explain why!

Let’s take a social media button as an example:

If you would write an alt text to the Facebook icon, a screen reader would say something along the line: “Facebook Facebook.” Very redundant!

OK, this is technically not about alt-texts but still important: make sure both the icon and the link text are in the same link-attribute, to get a smooth experience. Like this:


  
  Facebook

Another common mistake with icons is on menu buttons:

If the menu button has no visual text label – which, by the way, is really bad for the user experience – then it needs an alt-text (or another way of describing its function in code, like aria-label). Explain the icon’s function, like “Menu”. Don’t write “Three horizontal lines” or “Main hamburger”, which sadly are real examples I’ve stumbled on.

If the menu icon has a label, you should leave the alt-text blank. I often find menu buttons which are read as “Menu menu”. Once I even came across “Hamburger menu menu”. Somewhat confusing wouldn’t you say?

Images in links

Usually an image within a link is accompanied by a link text. Like in the example below:

In this case, the image and the link should be in the same link-tag in the html. In this case, you can just leave the alt-text blank. The important thing for the user is to hear the link text. An alt-text of the image would only distract by adding information that the user will not find necessary. The image is probably found on the page that is linked, and then you can give a good explanation of it in the alt-text.

If you really, really have to have an image in a link without an accompanying text, then the alt-text should describe the link destination, not the image.

Decorative images

Preferably, decorative images that do not convey any meaning to the user should be placed as background images in css. It probably goes without saying, but this means you don’t need alt-texts on them at all.

I’d classify most images that you place text on as decorative. You don’t need an alt-text on them. One example is the background image on Netflix’s startpage:

Some images intend to give users a certain feeling, like an artsy photo of a sunny beach next to a section about “Vacations”. Do not make the mistake of classifying such images as decorative just because they are pretty! If an image enforces a feeling, then a description of the image should be set to allow screen reader users that same feeling.

If an image is used to clarify a heading or label, like an image of a wooden table next to a heading called “tables”, it is not decorative and it should have an alt-text. It clarifies to users that we do not mean “tables of content” or any other kind of tables, but the ones you use to dine on. Such clarification should be given to all users.

A good rule of thumb when it comes to decorative images is that it is better to have one alt-text too many than one to few. And if you have to analyze the content of a photo to determine if it is decorative – then it probably isn’t! (We don’t need to know what is in the netflix background image above to know that it’s decorative).

Special cases

Logos in the banner almost always link to the websites start page. The opinions vary a bit on the topic of alt-texts for logos.

Some say it should include the company name, the fact that it is a logo and the destination of the link. Like such:

“Axess Lab, logotype, go to start page.”

In my opinion, this is a bit verbose. Too much noise! Since my screen reader already tells me it’s an image and a link, I only feel I need to hear the company name. From the fact it’s an image I assume it’s a logo and from the fact it’s a link I assume it follow conventions and links to the start page.

Svg

Scalable vector graphics (svg) is an image format that’s becoming more and more popular on the web. And I love them! They keep their sharpness while zooming and take up less space so websites load faster.

There are a two main ways of adding an svg to an html-page.

Inside an img-element. In that case, just add an alt-text as usual:
Using an svg-tag. If you use this method, you can’t add an alt-attribute because there’s no support for that. However you can get around this by adding two wai-aria attributes: role=”img” and aria-label=”.

Actually, for the second case, you’re supposed to be able to add your alt-text as a title-element in the svg, but there is not enough support for that from browsers and assistive technologies at the moment.

Can’t a machine do this for me?

Although machine learning and artificial intelligence is improving quickly and can describe some images quite accurately, they are not good enough at understanding the relevant context at the moment. On top of that, machines are not good enough at deciding what is “concise”, and will often describe too much or too little of the image.

Facebook has actually built in a feature that describes images automatically. But I feel like the descriptions are usually too general. One image in my feed right now is described as: “Cat indoors”. The actual photo shows a cat hunting a toy mouse.

So I’m sorry, you still have to write alt-texts yourself!

Thanks for making the web better!

I’m happy you read this far! It means you care about making the web a better place for all users. Spread the knowledge and keep being awesome!

Charming interfaces – make your users smile

Hampus Sethfors — Sat, 30 Sep 2017 14:26:31 +0000

Using charm and humor in interfaces is a hugely underestimated technique that can make the user experience delightful, memorable and sharable. Here’s how to design, write and illustrate your way to smiling users!

Hey…aren’t you accessibility experts?

Yes, at Axess Lab we specialize in accessibility.

But what does this post have to do with accessibility? Are you really allowed to use humor around people with disabilities?

Well, I’ve carried out some rigorous research and it turns out people with disabilities actually enjoy having fun!

Also, since technology is usually full of frustrating accessibility issues, I’d argue that people with disabilities benefit more from charismatic interfaces than most users.

The polite registration form

In this article I’ll give you a bunch of examples of charming interfaces, talk about the benefits of using humor and give tips on how you can succeed. But first, a short anecdote on how I stumbled on this topic.

A few years ago, I was stuck at a login screen, trying a gazillion different email-password-combinations. My frustration grew for every incorrect-email-or-password-message I got thrown at me. You probably know the feeling.

I finally gave up, cursed and went to their registration screen to set up a new account. I was in a terrible mood.

I typed my first name in the registration form. A message popped up to the right of the field:

“Nice to meet you!” It caught me off guard, got me smirking and made me curious. I quickly moved to the field for last name. Another reply from the form:

“Great name!”

Probably the first complement I had got all week! It. Felt. Great!

I was probably humming Lego The Movie’s themesong “Everything is awesome” as I finished the last two fields.

New delightful messages at each field. In less than a minute a form had turned my mood from “please kill me” to “I’m the king of the world!” For the first time ever I felt sad that I was done with an online form!

How to use humor in interfaces

This experience got me thinking about how we can use charm and humor to enhance the user experience. I started collecting examples of interfaces that do it well. It’s an underused technique, so it’s quite hard to find good examples, but I’ve been searching for a long time!

So now I’d like to share what I’ve found and hopefully inspire some of you to work on making your users smile.

I’ll give examples on three ways to use humor in interfaces:

Make errors less frustrating
Make users smile at details
Convince users to do something they don’t really want to

Let’s dive in!

Make errors less frustrating

One great place to start experimenting with charm is in error messages. Try to make your users smile with an illustration or unexpected wording. If you succeed, it will make your users more forgiving and they’ll hopefully find the energy to get around the error.

Twitter shows an adorable illustration when it’s down due to overload:

Google also uses funny illustrations if there are no results when searching for flights:

Spotify cleverly complements the user instead of just saying “There are no lyrics available for that song”:

Mailchimp hints of an evil twin if the username you want is taken:

Basecamp has an illustrated boy pointing to each form field as you fill them in. He turns surprised when you make a mistake:

A 404-page is an awesome place to add some humor. Olivia Ricci exploits every user’s strong feelings for cute kittens. Aww!

Why do charming error messages works wonders?

Well, users will likely be irritated when they see the error. Luckily, it’s close to impossible to stay angry when you’re looking at a cute kitten.

If you’re interested in the science behind it: smiling and laughing releases dopamine, endorphins and serotonin which acts as mood-lifter and makes you relaxed and feel less pain. You’re basically drugging your users when they need it the most!

Make users smile at details

Another great place to use humor is in the details. Leave small treats for your users!

There is a great site dedicated to this: Little Big Details. If you find this article interesting, you should definitely check it out. I got quite a few of my examples from it.

In Spotify the time bar turns into a light saber in the Darth Vader playlist:

Google Hangouts show charming animations when you type certain words, like “Happy new year”:

Tumblr changes their wording depending on the age of the user:

A Lego figure covers his eyes when you type your password on Lego Universe:

Siri answers some philosophical questions in clever ways:

Generally, you should not ask users for their gender if you really don’t need that information. But assuming you do, you can add some humor:

Mailchimp shows a high-fiving chimp hand when you’ve shipped an email campaign. Clicking it – or high-fiving it back – makes the hand gradually more red.

If you continue to click the hand, a high-five game starts in your browser. It made me wonder if Mailchimp’s developers have a bit too much time to spare…Or hey! Maybe they prioritize this type of content because they know it works!

Here are some advantages of using humor in the details:

It makes the interface sharable. The first thing I did when I saw the Mailchimp high five feature was to take a bunch of screenshots and share them with my colleagues on Slack. You’ll get your users to market your product for you. Genious!
It makes the user feel special. It’s kind of like finding a hidden treasure! It builds a connection between the user and your brand.
It makes users search for more special details in your interface. A quick search on Google and you’ll find tons of funny things to ask Siri. This can help build loyal users who share their findings.

Convince users to do something they don’t really want to

Increase conversion rates by manipulating with charm! It might sound a bit odd, but you can use humor as an energy-boost for carrying out tasks that users might not feel like doing.

Songkick charms their users by offering something silly if they track 20 artists. Who wouldn’t put down the effort just to see the drawn picture they offer?!

Nobody likes to wait, but as the old saying goes: “Time flies when you’re having fun”. There are some charming progress bars and loading spinners out there. Here’s a nice one by Dennis Perepelenko:

OkCupid shows this epic banner to people who use ad-blockers to get them to donate.

You will be much more inclined to do something if you’re in a good mood! That’s the simple brilliance behind this technique!

Still skeptical?

“I see your point, but I can’t design whimsical interfaces because I run a professional/business-to-business/multi-million-dollar/fortune 500/ company.”

I understand your concern, but – at the risk of sounding like a polite Englishman – I beg to differ. People don’t stop liking humor just because they go to work or become rich CEO’s. It’s human nature to enjoy smiling. And to appreciate the person (or interface) that made you smile.

As you’ve seen in the examples in this post, there are many ways to be charming. Everything will not work in every interface, but you should always be able to find a style that fits your brand. Everyone benefits from happy users!

Create memorable experiences

Lastly, I’d like to draw a parallel to one of the best articles on user experience I’ve read: User Memory Design: How To Design For Experiences That Last.

In short, the article is based on research done by Nobel Prize-winning psychologist Daniel Kahneman and talks about something called the “peak-end rule”. The gist of the rule is:

People’s memories of an experience are based on a rough average of the most intense moment (the peak) and the final moment (the end).

So when people evaluate your interface, their feelings about it will be based mainly on what they felt at the end and what they felt at the most intense moment. So when designing interfaces you should focus on creating one powerful peak moment and a great last impression.

You probably see where I’m going with this!

Happy is a powerful feeling. You can use charm and humor to achieve that! It’ll be extra effective if you inject humor when the user is done with a task, like the Mailchimp high-five example from earlier in this article.

Spotify cleverly uses humor in their offboarding by offering the user a “Farewell playlist” when they cancel their subscription:

Maybe they won’t make a whole lot of users change their mind, but at least the user is more likely to leave with a smile on their face and have a slightly better memory of Spotify, which probably increases the chance they’ll come back some day.

A final joke

I want to live like I learn! Since the article is just about over, here’s a joke:

How many graphic designers does it take to change a light bulb?

Four. One to change the bulb and three to argue about whether they should have used serifed or sans serifed fonts on the packaging.

Ahh, priceless! If I listen closely, I can just about hear the endorphins flowing through your body helping you remember this article!

Hope you enjoyed!

Web Accessibility Directive – What it is and how to comply

Hampus Sethfors — Wed, 27 Sep 2017 18:27:22 +0000

Worried about the new directive on accessibility that you need to follow? Great, you’re in the right place! Here’s everything you need to know about the directive and a seven step guide on how to comply.

About the accessibility directive

In October 2016 the EU parliament approved a directive on digital accessibility that had been worked on since 2012. The directive will become law in all EU-countries.

In this section, we’ll give an overview of the directive. In the next section, we will talk about what steps you need to take to comply.

The directive in a nutshell

If you work with web or apps in the public sector, the directive states that you must:

Make sure your website, intranets and apps comply with accessibility standards (more on that later in “What are the actual rules”).
Provide a feedback mechanism where anyone can notify you of failures to comply with the accessibility standards.
Regularly provide a detailed accessibility statement on your compliance, using a template from the EU Commission.

Who is affected

The directive affects EU-countries, and its full name gives a good hint of what is covered: “Directive on the accessibility of the websites and mobile applications of public sector bodies”.

So you’re definitely affected if you – or your clients – fulfill the following criteria:

Work with web, intranets or apps
Work in a public sector body
Work in an EU-country

Even if you’re not a government organization, you’re still affected by the directive if you:

Provide services that are essential to the public, or services that specifically address the needs of, or are meant for, persons with disabilities.

Exactly what’s considered essential to the public is not clear, but it will likely include companies in the transportation, food and finance industries, among others.

The directive lists some exceptions. The most prominent are:

Broadcasters (TV, radio etc)
Online maps
Live video or audio content

There are a few other exceptions that you can read about in Article 1 Section 4 of the directive if you’re interested.

Will they audit me?

Yes. Here are some quotes from the directive:

Member States shall ensure the availability of an adequate and effective enforcement procedure to guarantee compliance with this Directive

Member States shall periodically monitor the compliance of websites and mobile applications of public sector bodies with the accessibility requirements

Member States shall ensure that public sector bodies provide and regularly update a detailed, comprehensive and clear accessibility statement on the compliance of their websites and mobile applications

So to cite George Orwell: “Big brother is watching you!”

What happens if I don’t comply

The most important problem if you don’t comply is that you’re making it difficult for your users to access your services, especially users with disabilities.

But also, since the directive will be made into a law in each EU country, not conforming to it will literally mean you’re breaking the law. Details about the actual consequences are decided by each country’s authorities and may differ between countries.

Deadlines – How long do I have to comply?

23 September 2018 – deadline for countries to have put laws and regulations in place to comply with the directive.
23 September 2019 – all new websites (created after 23 September 2018) need to be accessible
23 September 2020 – all websites (not just new ones) need to be accessible
23 June 2021 – all mobile apps need to be accessible

This does not mean you can wait until 2019 to address this. Accessibility is a team effort that involves developers, designers, publishers, executives…well basically everyone. If you’re not working actively with accessibility now, it will take time and energy to make accessibility part of your processes and increase the knowledge of your organization.

For most public sector bodies we’ve worked with, it takes about a year of calendar time to put the right strategies in place to become successful with accessibility. So get started in time!

What are the actual rules?

If you want to dive into the actual standard, you should! But be prepared to do some serious reading.

The directive is only 15 pages. But it doesn’t include the actual requirements for complying. Instead it references the EU standard for accessible public procurement which is 134 pages long. In turn, that standard points to WCAG 2.0, which is about 1 000 pages if you include techniques of how to comply with it.

If you are like most people, you don’t have nearly enough time to go through all that. So below we’ve put together a guide to what you need to do to comply with the directive.

Practical seven step guide to compliance

“Only seven steps!?” you might be thinking, but it gets even better:

Apart from making your site or app accessible to people with disabilities, we guarantee it will become more usable for all your users. Win-win!
You might be able to skip some steps, depending on what type of organization you are.
If you’re only going to procure apps or websites, you should focus on step 1, 3, 4 and 7.
If you’re only building the apps or websites, focus on step 1, 2, 5 and 6.

So here we go! Our guide for building accessible products that comply with the accessibility directive:

1. Educate yourself and colleagues

To succeed with accessibility, different roles need to have the right know-how. Like we said before, accessibility is not a one-man-show, it’s a team effort.

Here are some key roles and the competences they’ll need:

Developers need to learn how to use techniques like WAI-ARIA to make their code accessible to assistive technologies.
Testers and developers need to learn the basics of assistive technologies like screen readers, so they can validate the user experience of their interfaces.
Designers need to learn how to create accessible user experience and design, like how to check the contrasts of their color schemes etc.
Editors need to learn how to produce accessible content, like how to write alternative texts for images and create captions for videos.
Managers need to know how to plan for accessibility and incorporate it into their requirements and agile processes.

Luckily, it doesn’t require weeks of education to get your team on track with accessibility. Most courses offered on accessibility are done in a day or two.

If you don’t have an accessibility professional to teach your team, here are some companies that offer accessibility training:

Axess Lab (yes we shamelessly promote ourselves because we’re really good at this!)
Paciello Group
Simply Accessible
Funka

A set up that we like to use is half a day of general training where people get to try out different assistive technologies, understand the users and learn the fundamentals of accessibility. Then we follow that up with half a day of specific accessibility training for different team roles. “Technical accessibility” for developers, “Accessible design” for the User Experience team etc.

2. User test

User testing is an absolute key task to succeeding with accessibility. If you’re not user testing on a regular basis right now, you should definitely start!

Trust us, we’ve worked with loads of clients who tried to make accessible products just by following different checklists. You will not succeed in building an accessible product unless you let actual users test it. Accessibility and usability are closely related. You can’t have one without the other.

If you’re user testing right now, great! Then all you need to do is start recruiting users with disabilities as test subjects as well. Check out our article on seven tips for user testing with people with disabilities.

3. Rework your style guide

I can’t even count the number of times an inaccessible style guide has caused problems in web projects. Since the style guide is the foundation that you build all your digital products from, an inaccessible style guide results in problems all across your interfaces.

Usually it’s because it specifies color combinations that have insufficient contrasts. A good tip is to have an accessibility expert work together with your designers to make sure your style guide complies to the accessibility standards.

Put in the effort to rework the style guide once and you’ll see so much fall into place automatically.

4. Feedback mechanism

The directive requires you to have a feedback mechanism that encourages users to comment on accessibility issues. You’ll also need to set up a strategy of how you handle issues that come in through the feedback mechanism.

For example, this can be a special email, like [email protected] that you add to your contact or support pages of your sites and apps.

Many larger companies also have special social media accounts for accessibility, where they promote work they do on accessibility and encourage feedback and discussions. Get inspired by the following examples on Twitter: @fbaccess, @MSFTEnable and @BarcalaysAccess.

5. Automatic testing

There are plenty of tools out there that help you catch some accessibility issues automatically. However, I need to be really clear on this: automatic tools will not find the majority of accessibility issues in your interface. Accessibility guru Steve Faulkner put it clearly in this tweet:

Automated accessibility checking is great, but it needs to be clearly understood that you can only auto-check about 30% of #a11y issues pic.twitter.com/kAXYGqpiOg

— Steve Faulkner (@stevefaulkner) May 12, 2017

Here’s a great article from Gov.uk on automatic testing tools: What we found when we tested tools on the world’s least-accessible webpage. The overall gist of the article is:

It’s important that teams don’t rely on them too heavily.

Automatic testing tools are a good resource if used together with manual reviews and by a team with accessibility knowledge. But don’t count on them to fix all your problems.

Here are some automatic testing tools that you can compare:

6. Manual testing

You should complement your automatic testing with manual accessibility testing. In other words: let someone who knows about accessibility test your site or app.

Here, you can either work together with accessibility specialists or educate people in your testing or development teams to do the accessibility testing.

You will be required to do manual accessibility testing when you update the accessibility statement required by the directive. How often this needs to be done is not specified in the directive. It just says “regularly update a detailed, comprehensive and clear accessibility statement on the compliance of their websites and mobile applications”. A good guess is that it will be at least once a year.

A good way to succeed with this is to make accessibility testing part of your agile process. A lot of teams have a “definition-of-done” that specifies the criteria that need to be checked off before they release a new feature. Make both a manual and automatic accessibility test part of the definition-of-done.

7. Procurement and requirements

If you’re not developing your own sites or apps it will be crucial that you have clear accessibility requirements and that you follow up on those requirements.

Just pointing to a standard like WCAG and relying on your client to ship an accessible product is not a good way forward. WCAG is long, abstract and difficult to understand and it’s very likely your contractor didn’t even read it, knowing you probably wouldn’t either. But you are the one getting in trouble if the result is not accessible!

You need to make the requirements concrete and easy to understand. You need to decide how you will test the delivery and state what will happen if the requirements are not fulfilled. You wouldn’t imagine how often organizations fail with this. It’s not rocket science, but you need to be thorough and not take the easy road.

High five!

By following the web directive and creating accessible websites and apps you’re doing a great thing for democracy and people’s independence.

When focusing on the needs of users with disabilities you’ll make your products better for everyone. That’s called design for all and is what accessibility is really about.

On behalf of all users, we thank you for your commitment and wish you the best of luck with your accessibility journey. If you have any questions don’t hesitate to get in touch at [email protected].

Statistics on disabilities – the one stat you need to know

Hampus Sethfors — Tue, 19 Sep 2017 06:42:05 +0000

We often get asked how many people have a disability. So here is everything we think you need to know about the statistics.

Yea, that’s it! You really don’t need to go dig into more details than that.

Accessibility affects everyone in a positive way. And the older you get, the more you’ll depend on accessibility. So start building accessible products right away – and let us help you if you need a hand!

But if you really, really want to know how many people live permanently with a disability, it’s around 15 % of the world population (who.int).

Text transcript of the infographic

100 % of the world population spend part of their life with a disability.

Here are some examples of why:

Bright sunlight on your phone screen leads to vision impairment.
Big thumb on small mobile device on shaking train leads to motor impairments.
Loud environment leads to impaired hearing.
Alcohol leads to lowered cognitive abilities.
Tired or stressed results in lack of focus.
Ageing leads to all of the above.

Accessibility matters to everyone.

Design for all. Always.

Skip the WCAG! User test with people with disabilities instead

Hampus Sethfors — Thu, 14 Sep 2017 10:24:05 +0000

If you’re trying to make your website or app accessible, you’ve probably stumbled over the Web Content Accessibility Guidelines (WCAG). But don’t waste your energy trying to understand them. Just don’t.

Get out and test with actual people

I know it’s a bold statement. But the WCAG will confuse you. And probably scare you away. It’s really, really, really long and difficult to wrap your head around.

How long? Well, I took the WCAG, pasted it into Microsoft Word and zoomed all the way out. Voilà, here are the 98 pages:

On top of that, there are the actual techniques for succeeding – the blue links on the latter half of the pages above lead to those techniques. Probably another 1 000 pages or so.

So instead of diving into WCAG, if there’s one thing you should do to improve the accessibility of your website or app it’s to let people with disabilities test it.

I’ve done this a lot in my role as an interaction designer at accessibility focused companies. And there is no doubt in my mind: testing with users with disabilities will help you improve accessibility far more than reading any checklist or standard ever could. Period.

“Normal” users are not good enough

Testing with users with disabilities will also help you improve your usability far better than testing with your “regular” test subjects. Why?

Well, for instance, a person with cognitive impairment like autism will react to the same things that another user will. But they go further. They are much better at spotting inconsistencies in design, problems with navigation and unnecessarily difficult content.

Things that other users will find annoying but work their way around without mentioning. In a similar way, a person with low vision will react to small text or low contrast, which will make reading difficult for anyone out in the sun with a smartphone.

If you want to test with people with disabilities, I’ve put together a list of tips to get you going in another article:

Seven tips for user testing with people with disabilities

And if you feel it sounds a bit scary, we can hold your hand and help you with recruiting users and carrying out the tests.

Don’t hang me…

And finally, I turn to the awesome people of the accessibility community: Please don’t hang me for suggesting people to skip the WCAG. The fact is, I love the WCAG! It’s probably one of the most important documents around, all categories. But it should be used by people who’ve matured further in their accessibility career or mindset.

First, you have to witness people in action, otherwise you’ll not understand how to use the WCAG, why it’s around and it’s strengths and limitations. Hope you get what I mean!

Accessible datepickers

Hampus Sethfors — Wed, 06 Sep 2017 12:26:29 +0000

Datepickers often cause problems to assistive technology users and fail several basic criteria in the Web Content Accessibility Guidelines (WCAG). But datepickers can – and should – be made accessible. Here is how to do it and a few examples you can steal or get inspired by!

Criteria for accessible datepickers

Don’t force people to use the datepicker. Make it possible to write directly in the input field as well. And make sure the required format is specified in the label.
Make it possible to navigate with a keyboard (here is where most fail). For example by tabbing to the calendar and using arrow keys to pick the right date.
Don’t hide the calendar button from screen readers. We’ve met a few clients who considered setting aria-hidden=”true”, forcing screen reader users to input directly in the text field. But that’s not a great idea. Some screen reader users use a combination of sight and screen reader, so hiding the calendar button and calendar view for screen readers will harm their user experience. Make the actual datepicker accessible instead.
Make sure that the buttons and icons in the calendar view have proper labels so that they get correctly read by screen readers. For example, the dates of the month should not just be “1”, “2″ etc. They should be read “1 January, Thursday” or something similar. You can use aria-label for this.

Examples of accessible datepickers

Here are a few accessible datepickers that fullfil the criteria above that you can get inspired by:

Accessible Bootstrap Datepicker

Aria Datepicker

Deque Datepicker

WebAxe have some more examples in their article Accessible Date Pickers (webaxe.org).

Colorblind Accessibility on the Web – Fail and Success Cases

Hampus Sethfors — Wed, 06 Sep 2017 05:43:00 +0000

It’s Colorblind Awareness Day today! To celebrate, we raise awareness by giving you some practical examples of how design can hurt or help users with color vision deficiencies.

Diagrams and infographics

Diagrams and infographics are common offenders when it comes to creating accessibility barriers for people who can’t tell certain colors apart.

Green and red are the most common colors that are difficult for people to tell apart, which makes the diagram below extra problematic.

This is what it would look like with deuteranopia, a color defiency that about 6% of the male population has.

Pie charts are usually really inaccessible.

Reasons why I hate pie charts pic.twitter.com/e1ooavL7Zd

— Color Blind Probs (@WeTheColorBlind) January 28, 2014

If you really want to use a pie chart, put your labels in the chart.

Or just use a bar chart instead because piecharts kind of suck.

Here’s a great article on how to make your charts more accessible with color blind friendly palettes.

Color pickers

Color pickers without labels will create a barrier for people with color blindness.

Instead, label the colors. This will help all users, since it can be hard to see the difference between certain colors like black, tortoise and brown. The great example below is from warbyparker.com.

Apple also does a good job with this. Instead of showing a color palette they show the actual product in the different colors, with a label below.

Toggles

Here is what one person on Twitter answered when asked what causes accessibility problems for people with disabilities:

Colourblind. Text on background is usually fine, but things like colour-coded toggles, heatmaps, etc can be hard.

— Dan (@phrawzty) June 4, 2017

This is what iPhone’s toggles look like if you remove colors. Which one is on and which one is off?

A simple solution is to just use check boxes instead:

Error messages

A red frame around error messages is not good enough, like illustrated by this image from the great article Designing eCommerce for colourblind users (uxplanet.org):

You need to make the error stand out more clearly by adding an error message:

Links

Don’t just use color to differentiate links from other text. If you remove the color it’s really difficult to understand that the heading “Modules” is clickable in the example below.

You can use color, but in combination with something structural, like an underline, a link icon or a button design.

Here are a few examples of links that work well even if you have a color vision deficiency.

Contrasts

Make sure that you have sufficient contrasts between your colors. Avoid writing text on top of images, like in the example below from the article Improving The Color Accessibility For Color-Blind Users (smashingmagazine.com):

Make the background darker to improve the contrasts:

Measure your contrasts and make sure they are at least 4.5:1. Here’s a list of our favorite free color contrast checkers.

Below is an image of a big contrast fail in real life:

The overall accessibility guideline

The guideline for creating accessible content for people with color vision deficiencies is pretty straight forward:

Color is not used as the only visual means of conveying information (Level A)
– Web Content Accessibility Guidelines 2.0

So it’s fine to use colors to convey information, as long as it’s also conveyed in some other way.

A great way to check it is by viewing your design in greyscale before each release. You can use the free tool Funkify to do it right in your browser.

If you’d like to go deeper, you can join a practical workshop with our team, or even prepare for WAS certification to strengthen your skills in accessibility.

Keep updated on color blindness

Here are tips of two awesome Twitter accounts to follow that raise awareness on color blindness:

@colourblindorg
@WeTheColorBlind

And while you’re following great accounts on Twitter, follow me as well: @hampelusken!

Let’s end with this Tweet from @colourblindorg showing that color problems limit people outside of the web as well.

1/2 Why no section for ppl unable to watch matches due to ‘colour blind’ kit clashes #1in12men #1in200women @EHCR?https://t.co/bHnx8cqj1K pic.twitter.com/2jssIGPicA

— ColourBlindAwareness (@colourblindorg) August 11, 2017

Fonts don’t matter

Hampus Sethfors — Fri, 01 Sep 2017 13:45:27 +0000

If you’re an art director or font fanatic, you might want to sit down for this. Take a few deep breaths. Go to your happy place. Because I’m going to explain why fonts are overrated and what actually matters for readability.

The hard truth

What’s important when picking out a font?

It’s one of the most common questions I get when I consult in accessibility.

People expect me to start lecturing on the importance of fonts for people with dyslexia or other reading impairments.

How different typefaces and kerning really can make a difference for the readers.

How the choice of serifs or sans serifs in headings is as close to a life-or-death changing decision a web designer can get.

So I always get perplexed reactions when I reply:

Actually, font’s do not matter very much…

I know it’s a really bold thing to say. Telling web designers that fonts don’t matter is like stealing a kid’s favorite toy.

But before you compose an angry tweet about it or respond with a “Fonts matter a lot” article on Medium, please hear me out.

Fonts are overrated

I’m asked to talk about fonts so often that I consulted members of the Dyslexia Association here in Sweden. They are experts on readability and get font questions so often that they even had a prepackaged answer referencing different studies made on the subject.

Here’s the gist of what they had to say:

The energy put on fonts is hugely overrated. There are other things that are of much greater importance for our members.
– Representative from the Swedish Dyslexic Association

The folks at Dyslexia Action agree with this:

Research shows that fonts matter relatively little.
– dyslexiaaction.org

What really matters for readability

So first I want to go through what really matters to people with reading impairments. At the end of the article you’ll find some pointers on fonts as well. You’re only allowed to read that once you’ve understood the other things that matter more. So promise me you won’t skip to that right away.

Structure the text – headings, sub headings and paragraphs

Here are two of the answers from our article Accessibility According to Actual People with Disabilities:

Dyslexic – not really seen as a disability, but large walls of text is painful.
Also never ending sentences and over complicated language.

— Mustafa Kurtuldu (@Mustafa_x) June 3, 2017

When ppl type large blocks of text w/ no spaces added

— Dead Ass (@MeBeShe4815) June 3, 2017

So giving your text a reader friendly structure is important.

Here are a few things you can do to structure the text in a nice way:

Include plenty of headings and sub headings
Use bullet lists a lot (like I’m doing now)
Keep paragraphs short

Complement text

Letting users choose how to obtain the content is a key to accessibility.

Work on complementing text content with:

Infographics
Videos
Illustrations
Images
Audio

I tie a tie about once every five years. I’m happy for the combination of video, text and illustrations on tie-a-tie.net (see example below). Usually I look at the illustrations, but if I can’t figure them out I switch to the video. I have a friend who is completely blind. He prefers the text version.

The point is that we can choose, and that’s awesome!

Don’t use italics

I could cite a few studies done on the readability of italics, but instead I’ll just write this in italics to prove my point. It takes more effort to read for everyone. Especially words you don’t come across very often, like absquatulate. On top of that, imagine that you have a reading impairment where letters tend to blend together. Then italics will make things so much worse. So just don’t use italics.

Keep it clean

Let the user focus on the content without distractions.

Avoid:

Movement, animations and other “concentration thieves”. Common offenders are advertisement banners, image carousels, popups and fly-ins.
Too much clutter around the content, like multiple columns with related articles.
“Sticky” objects that follow along when you scroll, especially ones that cover part of the content.

Ladies, gentlemen and everyone in between, I present to you the pride of my home country Sweden, the world’s most cluttered site: Arngren.net.

Gaah! Do not follow their example.

Line length – keep them short!

A common problem for people with reading difficulty is that they jump to the wrong line of text at line breaks if the lines are too long. In other words, when you can’t find the way from the end of one line to the beginning of the next line.

One way to reduce this problem is by keeping paragraphs short.

Another important guideline is to keep line length short. 50–75 characters – including spacing – per line is a good line length guideline for big screens. Shorter of course on mobile screens.

Line height – make it large enough

Usually the problem with line height on websites is that it’s too tight. This contributes to the problem for the user finding the next line from the previous one. It can also make the page feel like a “wall of text”, a common comment when user testing with people with dyslexia.

A good guideline is to use a line height that’s 150 % of the font size (Smashing magazine). It’s what we use on this site.

Font size – make it large enough

Anyone who has used their phone to surf to a site that is not adapted to small screens knows that font size matters for readability.

As with line height, the problem is usually that it’s too small. It probably has to do with the fact that most people who design websites are young and have a better than average vision.

Show your interface to someone who is over 65 years old and see if they pinch or hold the device really close to their eyes when reading.

Usually we see font sizes between 15–18 pixels on the web. Here is one good reason to crank that up a few pixels:

A larger typeface has been proven to enhance readability for all types of users, regardless of one’s age or quality of eyesight.
– Your body text is too small (marvelapp.com)

Here’s a rule of thumb I made up that should work for most designers:

Pick a font size that you think is nice. Then make it at least 2 pixels bigger.

What matters with fonts and accessibility

Yes, I lied in the title of the article. A little bit. Because even though fonts are overrated and get far too much energy and attention in projects, I’m not arguing that they don’t matter at all. Just that other things matter far more.

For example, if you’d use Comic Sans on your site many readers would probably react.

If you’ve done your best with all the other factors that I’ve mentioned above, then it’s time to think about the font.

So here are some pointers when choosing a font for good readability.

Pick a common font

When studies compare reading speed and user preference of different fonts, common fonts usually win.

People tend to prefer reading letters they’re used to reading.
– Representative from the Swedish Dyslexic Association

…duh! Quite obvious when it’s put in that way, right?

When a font looks odd, it’s hard to focus on the actual content.

The best font choices are ones where the reader does not notice the font, but the message
– WebdesignerDepot.com

Which font are common on the web? Here’s a great article on the most popular fonts on the web (theultralinx.com).

A note on “dyslexia friendly” fonts

There are a few fonts out there that market themselves as “dyslexia friendly” and they’ve gotten a lot of spread lately.

Below is Open Dyslectic, probably the most well known font designed for readers with dyslexia. As you can see, the foot of each letter is bold, which is meant to reduce risk of flipping the letters around when reading.

However, people with dyslexia tend to prefer common fonts to dyslexia-friendly fonts when comparing them.

Special fonts often result in the reader mentally thinking about the font, when reading actually is about getting beyond the font and reading the content.
– Representative from the Swedish Dyslexic Association

There is no evidence that dyslexia fonts help people with dyslexia to read faster and more accurately.
– Understood.org

So don’t overestimate their dyslexia friendliness. Use common fonts instead.

Let people choose

Depending on what type of interface you’re building, it might be a good idea to make it possible for your users to switch to a font they prefer. Most e-book readers – like Amazon Kindle below – have a feature to pick font, line spacing, margins and more.

Web browsers also let users set global font and color schemes. Try it out in the settings of your browser and make sure it works on your site.

Safari’s Reader Mode also let’s the user pick fonts, colors and sizes that they prefer:

Far from everyone who need the font styling features will find them, so you still need to format the default text in a way that works well for readers.

Even though it can be good to let users pick their fonts in some interfaces, it’s doesn’t work for all of them. For example, if you place a font changing feature in the header of a website, it’s usually not something that users will find or bother to use. They want to set it globally so it affects everything they read – like in the Reader Mode on Safari – not have to do it separately on each individual site.

Serif or sans-serif

The question of serif – squiggly decorative ends of strokes on letters – or sans-serif font is always a well debated issue. Some readers think it helps the flow of the text, others will say it causes letters to blend into each other.

So I will recommend you to fall back to the previous guidelines:

Use common fonts. On the web, most use sans-serif fonts so that’s what we recommend for body text.
Let the user choose. Make sure that changing the font in the browser settings works on your site.

Final words

I’ve sat countless of hours in web design meetings where fonts choice was debated back and forth. I just want to cry out “Please put this energy on making great content, user testing, information architecture or something else that matters more!”

Sadly, I’m way too polite to say that out loud. Instead I hide behind my keyboard and write this article about it.

So please help me out. Do talk about fonts in your projects. But keep it to a reasonable amount. Pick one, then move on to something more important.

How icons are ruining interfaces

Hampus Sethfors — Mon, 21 Aug 2017 15:02:07 +0000

Icons used correctly can enhance both the user experience and look of your interface. Sadly, more and more designers are using them in the wrong way. And it’s hurting both the usability and accessibility of the interface.

My dad and his TED app

I love to watch my dad use technology. It’s such a great learning experience for me as an interaction designer.

He is 57, wears glasses when reading and always delays getting a new phone until his old one completely stops working. You see, he does not like to learn new technology. He just wants his stuff to do what he needs it to do without having to think.

My dad does a lot of long distance flying. So recently, he asked me:

Can I download TED-talks to watch on flights?

I answered as I always do to that type of question:

I don’t know. Try!

Then I stood behind his shoulder looking at how he tried to solve it. Not helping, just looking. I love it! The only thing missing was a bowl of popcorn.

He quite quickly found a video. He looked at his options. Four icons.

He hesitated a bit, looking through them. It could be the heart or the list icon with a plus sign. But he decided to go for the down arrow. It looked the most correct. Which it was. But he clearly felt a bit unsure.

He got some sort of notification that a file was downloading by the Android operating system. But then he immediately started looking for the downloaded clip in the app. Did it work? Where was it now?

The main menu of TED is a collection of five icons:

My dad started clicking the icons one by one, clearly not understanding what any of them meant. He could not rule out a single icon. Since he felt unsure of them all, he gave each page a very limited amount of scanning.

When he couldn’t find the downloaded clip in the app he went out of the app and looked for some kind of folder where the video could have ended up. “Maybe it’s in a Downloaded folder” he mumbled. Clearly hoping his Android had a file system like his computer. Which it does, but not as visible as on desktop computers so he couldn’t find it.

Then he gave up. It’s not worth it.

So I had to step in and help, and I found the downloaded clip under the last icon, the one that looks like a user profile. He had clicked that but not had the energy to look closely enough. Too tired from checking every other place that he thought could be correct.

So this story illustrates one key problem with how many interfaces use icons…

Icons could mean a lot of things

The icons are given meaning by the user, in regard to the task they’re carrying out at the moment.

Icons are like abstract paintings. They get different meanings for different people. It’s all through the eyes of an observer. And that ambiguity is really exciting with art. But not so much in user interfaces.

What’s the icon for offline downloads? It could be a folder, star, heart, down arrow. Or even a profile icon, like in the TED app. It’s very hard to rule out any one icon.

So what I’m trying to say is that icons don’t work alone.

Icons should have labels

When icons are used to save space, things go wrong. Icons should not be used in that way. To a designer of tight mobile interfaces, using an icon to save space is really compelling. At first glance, the interface looks so clean and tidy!

However, for the user it’s usually the second glance that counts. The one where they look at the icon when they are carrying out a task.

My dad doesn’t give a poop that the interface has a clean first impression if it confuses him when he’s trying to get something done. And your other users probably work in the same way.

You recognize an icon used to save space by a lack of a text label.

Icons without labels suck

Here are some examples of interfaces with labels without icons.

The Gmail app. It took me – an interaction designer – an eternity to find the “Mark as unread” feature which I want to use all the time. It’s the mail icon. And the box with the down arrow means “archive”, not “download”.

I recall at least three different people I’ve had to help download an app from the App Store after they exclaimed “where the hell is the download button?”. Yes, my dad is one of them. A cloud with a down arrow? Apple, you can do better than that.

Instagram is packed with icons without labels. You can probably guess what they do, but you probably have to do a fair bit of thinking and you’ll not feel totally confident. You should aim to make your users feel confident.

Icons without labels are not only a problem in digital interfaces. Ever wondered why you always use the same setting on your oven, dishwasher or washing machine? Probably because you have no idea what the other features mean.

Here’s a washing machine I came across in France that made me go “Merde sacré bleu”!

Icons + labels = true love

If you label icons, they suddenly become awesome, accessible and understandable. An icon with a label:

makes it easier for the user to find the most important features – the ones with icons.
makes it easier to remember where you clicked the next time you come back.
makes the interface more aesthetically pleasing than if there were just text buttons.

A text and icon combination also improves the experience for people who have a hard time reading, like many users with dyslexia, autism, aphasia or other reading impairments.

Icons with labels are awesome

Below are some examples of interfaces that label icons.

The Tripadvisor app uses icons with text labels on their startpage and on their tab navigation menu.

Just for comparison, here’s what it would look like without the text labels.

Not as clear without the labels, huh?

Headspace uses text or icons with text labels. Never icons by themselves.

Slack uses icons with labels in their menu. They also use colors to highlight some of them. Together this assists their users’ memory and lightens up the look and feel.

Quora uses icons with text labels both in the header and footer of their app.

Are you considering solving the “my-stupid-users-don’t-understand-the-icons” problem by showing tooltips when the user hovers over icons? An understandable – yet not excusable – mistake.

Why is this not a good solution? Well, two main reasons:

You can’t hover on touchscreens.
Not all users use a mouse, for example a lot of people with motor impairments. Lesson one in accessibility is to make it possible to navigate your interface using a keyboard only.

Yes, there are exceptions

There are some icons you can use without a label. Like a trash can for delete:

Or the magnifying glass for search. But even that icon’s functionality can differ. Sometimes it means zoom or preview:

The main thing to know is that the number of universally understood icons are far fewer than you think.

If you’re reading this post, you probably live in a bubble where your the people you hang with are far more tech savvy than most people out there. So just because you and your friends and colleagues know what the icon means, doesn’t mean everyone does.

Kids now days don’t even recognize the floppy disk as a save icon. Oh my! Where’s this world heading?

Another good example is the hamburger menu icon. You probably know what it’s for. And it’s in interfaces everywhere! But A/B tests have shown many people don’t use the hamburger menu icon if it’s missing a label.

Icon guideline

So lets boil down this post into a simple icon guideline:

Awesome: Icon with text label
Totally fine: Text with no icon
Almost never cool: Icon without text label

Or to make it even shorter:

Stop using icons to save space.

Want to learn more about accessibility?

In our accessible design workshop we teach practical patterns for icon+text labeling that test well with low-vision and cognitive-load scenarios.

Interested in deepening your skills? Our WAS training course helps you prepare for the international WAS certification, with hands-on practice and guidance to master accessibility in real projects.

Why online shopping is more accessible than health care

Hampus Sethfors — Mon, 14 Aug 2017 13:24:17 +0000

I recently met people with motor impairments to do user research. To my surprise, they turned out to prefer online shopping sites to public health care sites. This in Sweden, a country at the forefront of technology and with supposedly the best health care in the world. Is this really possible?

Who are these people?

I was doing user research on motor impairments in order to create a realistic motor impairment simulator. I’m in a super exciting project where we’re creating a browser plugin that simulates different impairments, like motor, vision, reading and cognition. I’ve added a link at the end of this article if you want to check out the plugin.

Anyway, the people I met had Reumatism, Parkinson’s, Arthritis or some combination of the above. Most, but not all, were senior citizens.

Online shopping versus health care sites

I asked them to give some examples of sites they liked and disliked, and then explain what it was about the sites that made them pleasant or difficult.

To my surprise, most people said they liked different e-commerce sites where you can buy clothes, tickets, books and similar items. When asked to give examples of sites that they didn’t like, the same site kept popping up: Sweden’s hub for health care 1177.se.

This blew my mind a bit. Is it really possible that online shopping is more accessible than health care sites?

What shopping sites do well

I love filling out forms
– No one ever

Forms suck. The longer the form, the greater the risk of making a mistake. And for many people with disabilities, inputting data takes longer and more mistakes are made. Stephen Hawking for example, types around two words per minute using his assistive technology. So it’ll take him, and many other assistive technology users, at least ten times as long to fill in a form than for most people.

E-commerce sites tend to put a lot of energy on making their forms easy to use. Health care? Not so much.

When buying books online, I simply enter my social security number in the checkout and all other form fields get prefilled. It’s super easy! When booking health care, it’s a complete mess.
– Woman with Rheumatism

She went on to explain different rules concerning which clinic she is allowed to pick, how most clinics have different routines for bookings, how she has to fill out information about her condition from scratch at each place she goes. The list went on. And on. And on.

Most users really dislike forms.
Most users with disabilities really hate them.

So to make your site accessible to people with disabilities you should focus on simplifying your forms. Amazon has taken form-simplification to the extremes with their “buy-with-one-click” checkout process (maybe they’ve even taken it too far).

Compare that to the form for booking a time with the health care system below. Lots of fields in a cluttered layout. I know it’s in Swedish, but you get the point (sidenote: it doesn’t seem to be possible to get it in English, another big accessibility problem).

Just the fact that you’re supposed to pick the times you can’t go to the clinic…wow. Imagine the number of mistakes made there.

I just want to talk to someone

Another person complained about how the health care system these days want everything to be done online and what a big a pain it is to get to talk to someone.

If you don’t call right when they open the phone lines in the morning, you can spend the whole day in a queue, and sometimes not get through before they close.
– Woman with Arthritis

The last couple of years more and more effort has been put into forcing users to the web interface. Giving people the opportunity to make a phone call is a service that costs too much, so the health care system is making it a hustle in hopes that people will do everything online instead. This is not appreciated by many people, especially by some elderly who are not comfortable with new technologies.

Choice is a key to accessibility. Give people the choice of which channel suits them best. Phone or web. That’s user centered design and client focused health care in practice.

So to summarize this section: contacting health care seems to be difficult, time consuming and a form fiesta.

Disabilities amplify usability issues

I’m pretty sure that if we’d check the accessibility standards conformance of all e-commerce and all health care sites, health care would win big time. But accessibility is so much more than conforming to accessibility standards.

Accessibility is mostly about issues that are not black or white.
Accessibility is mostly about “softer” things that are hard to put in a checklist or standard.
Accessibility is mostly about usability.

When most people in the IT sector think about accessibility, they think about coding and other techy things.

I’ve done hundreds of user tests with people with disabilities, and a majority of the problems that affect these users are not tech issues. Of course, making your site accessible for assistive technologies like screen readers is important. But most accessibility problems are usability related and affect all users.

But, one thing is really important to understand: usability problems are usually amplified by a disability. For example, finding the right country in a dropdown with 200 countries is irritating for everyone. But imagine your hand shakes constantly, your vision is blurry or you have dyslexia. The irritation is amplified.

So improving the usability of your interface is important for everyone. But it is crucial for users with disabilities.

It’s all ’bout the money

I believe that the main reason e-commerce sites often are better at usability – and thereby accessibility – is that they have a greater incentive to convert the users on their site into paying customers. They measure conversion rates and know the effect that simplifying form fields in the checkout has on conversion.

Health care obviously also care about money. But for them, it’s often measured in time spent by the health care employees. Phone calls take a lot of time, which costs money. So they have an incentive to reduce that time.

They end up hiding their contact info like a squirrel hides an acorn.

And patients generally don’t have much choice. It’s not like if the site is a pain to use they’ll skip getting treated. And there is often no where else to go. It’s not like shopping, where you just can head over to a different store.

So users use the site even though it’s frustrating. Or sit for hours waiting to talk to someone who can help them.

Health care – time to shape up

Don’t get me wrong. Online shopping sites – like basically all sites out there – have their fair share of accessibility issues as well. But they prioritize user experience, and that pays off.

The health care sector, and the public sector in general, need to get better at user experience and put less of a burden on their users. User experience and user testing should be prioritized higher.

Because getting good health care should be just as easy as shopping online. Anything short of that is an embarrassment for a democratic society.

Check out the simulator plugin

Like I promised at the start of this post, here’s the link to the plugin that simulates different disabilities, if you’d like to check it out:

www.funkify.org.

It’s in Beta right now but will be released sometime in the fall of 2017.

How to make your site accessible for screen magnifiers

Daniel Göransson — Sun, 16 Jul 2017 17:21:43 +0000

There are around ten times as many people who use screen magnifiers than screen readers. However, focus always seems to fall on screen readers in accessibility discussions and guidelines. Let’s change that! Here are a few tips on how to make your interface accessible to screen magnifiers.

This article is inspired by and based on this original blog post: How to Make Your Website Accessible to People Who Use a Screen Magnifier (dev.to).

I also use a screen magnification daily, and experience many of the same pain points as discussed in the blog post. Here is a summary and a few thoughts of my own on this issue.

What’s a screen magnifier?

A screen magnifier is a software that magnifies the screen and displays a portion of it enlarged. Below is an example of how it can look.

Screen magnification is different to browser zoom (that you do with ctrl +) in that it doesn’t cause responsive layout to kick in. Using browser zoom, the layout is usually changed to match the width of the screen, so the user doesn’t have to scroll sideways. With screen magnification you’ll always need to scroll sideways to see all content.

Making your interface screen magnifier friendly

1. Complement hover with click

The screenshot below shows how only part of a popup is visible when the user hovers over an info icon with a screen magnifier. However, when the mouse pointer is moved over to the popup it closes. So there is no way for the user to read it.

Instead, make the icon clickable so the user can decide to show the popup. This is also necessary for touch screens where there is no way to hover because of the lack of a mouse pointer.

2. Check your hover contrasts

Color contrasts need to be good for people with low vision, and many design teams know how to check contrasts. However, most forget to check their contrasts on hover. This can create a big problem for users with screen magnification, who may have no choice but to hover over what they want to read.

Below is an example from Kickstarter where content becomes almost completely unreadable when hovering.

Most people could just move the mouse pointer to another place and read the text. But a person using screen magnification will probably have no choice but to hover over the area to read it, since they need the text to cover all the screen for it to be readable.

In the example below from MediaTemple, the links change to a really light blue color with insufficient contrast on hover.

So hey! I’ve got an idea. Instead of lowering the contrasts on hover, increase them!

Show results close to where it was triggered

When a user interacts with something they will often be shown feedback on what has happened. This feedback should be presented close to where the action was triggered.

A common place where this fails is in error messages. The user presses a submit button and the error message shows up at the top of the form, or as a “toast message” (that also might disappear after a few seconds which is another problem).

Here is an error message that is displayed at the top of the screen that can be hard to find for screen magnification users.

Instead, show the messages close to where the user is when it’s triggered. The example below is better – but not perfect as many users zooming will not see things that far to the right of the field.

The best design pattern is to show the message just below the field that the user is at. Then they will not miss it.

Keep as much as possible to one column

Users with screen magnifiers don’t get as good an overview as other users. Because of that, they are more likely to miss the second column in forms and articles. In the form below, users with screen magnifiers will probably miss the required field “Message” since it’s in a separate column.

You can put navigation in a separate column because it’s a common design pattern on the web. But other than that, keep it simple and have only one column for your information. If you have “related links”, put them in the content where they are relevant or below the article. Not in their own column.

Want to learn more?
In our Interactive accessibility lab, your team gets hands-on with tools like screen magnifiers and works through real bugs together.

Disabled buttons suck

Hampus Sethfors — Fri, 07 Jul 2017 16:56:58 +0000

Showing buttons as disabled until a form is complete might seem like a good idea. It is not. They usually create a lousy user experience and exclude many people with disabilities. Here’s why disabled buttons suck and what to do instead.

Why I got pissed and decided to write this

A couple of weeks ago I got this comment at an event:

I really have to go now, but add me on Facebook and we can continue talking.

And I was thrilled! You see, I usually don’t thrive in social situations. Networking has never been my cup of tea. But there I was. At a meetup. Talking to an interesting person who asked me to be their online friend. Oh the joy!

So I threw myself on my phone, opened the Facebook app and found her. I got to the screen below, and that’s when everything almost went down the drain:

At first I didn’t see it at all. But luckily, I’ve got the eye sight of an eagle! I was just able to read the light grey text. “Add friend”.

Seeing as the text and the icon matched my goal perfectly, I pressed it!

Nothing happened.

Maybe I missed the touch target?

So I pressed it again. Same result. Started tapping it like it was the browser refresh button and Justin Bieber’s concert tickets were just about to go on sale. Didn’t work either. And I felt stupid for thinking it might.

Had the wifi crashed? Were we already friends? Had I reached the limit of the number of friends I’m allowed to have on Facebook? My brain was working on full speed.

Let’s pause the story a while. Sorry! I realize that you must be on the edge on your seat. What happened next? Why was the button not clickable? And would a disabled button spoil yet another friendship?

However, like all great entertainers, I’ll reveal the unfolding of this thriller at the end of this article. #cliffhanger

But first…

Why disabled buttons suck

Here are a few reasons why disabled buttons are gruesome things that will ruin your users’ day.

They fool users into clicking

Disabled buttons usually have call to action words on them, like “Send”, “Order” or “Add friend”. Because of that, they often match what users want to do. So people will try to click them.

When nothing happens users can feel irritated, confused, disappointed, nauseated, let down, angry or stupid. Terrible design patterns make users feel terrible.

They are hard to see

Most disabled buttons are really hard to notice and read. They make the users squint and feel at least 30 years older. Even though the button is disabled, the text can be crucial for understanding the context.

White text on light grey background, come on!

These insane contrasts, of course, create even bigger problems for users with low vision. For some unthinkable reason, the Web Content Accessibility Guidelines (WCAG) do not require sufficient contrast ratios for disabled buttons:

The visual presentation of text has a contrast ratio of at least 4.5:1, except for the following:
Text or images of text that are part of an inactive user interface component.

It’s simply impossible to understand why this exception is in the guidelines. Just another reason why you can’t follow them blindly (pun intended). But more on accessibility later.

They don’t give any feedback

99% of the disabled buttons out there give no feedback as to why they are disabled when you click them (source: gut feeling. No one studies disabled buttons. Probably because they suck).

Below are three disabled form elements in Google Analytics. Nothing happens when you try to interact with them.

The reason they’re disabled is actually that the user doesn’t have the necessary permissions to control them. Why, oh why, is there no message to help them realize that?

They give design teams a reason to rush through error handling

If you’re working with IT, you probably hate error handling. “Hey! My users won’t make any errors in my perfect interface.”

You might think error handling is taken care of with live error messages that show up when the user makes a mistake.

Sadly, the users are often busy thinking hard about the answer to your next form field or looking down at the keyboard while typing, so they often don’t see your error message.

But you have a plan B! You reckon that the user will see the disabled submit button and realize what’s wrong.

Sadly many users don’t get why the button is disabled. And most who do first get pissed off pressing the disabled button a million times before realizing what’s wrong.

You’ll need to put in some more effort to take care of the users who click the button. More on how later.

They make users think

Why does this button look so strange? What does it say? Why can’t I click it? What should I do now?

Few form fields can make a user think as much as a disabled button.

But is that really so bad? Yes. There’s a whole – epic – user experience book written about it: Don’t make me think. Users don’t want to think about your interface, they want to complete tasks with as little effort as possible.

Disabled buttons disable disabled users

Now that’s a tongue twister! But it’s true. Disabled buttons often create a big barrier for people with disabilities.

Why? Well, let’s pretend that you have low vision and you’re filling in the register form on eBay:

If you’re zooming the interface because of your low vision, you’ll most likely not see the second column:

Maybe you’ll think they only need the first name. Or you might simply fill in both your first and last name in the field for “First name”. I’ve seen that done so many times in user tests, both by users with and without disabilities. You’re so used to writing your last name after you write your first that you do it by default.

So this is what you’ll end up with:

You’ll find yourself clicking the register button and getting no feedback. By the time you’ve realized there’s a second column in the form, eBay will have gone bankrupt for losing so many customers.

Aside from that, assistive technologies like screen readers and switches are usually not even able to navigate to disabled buttons. Try using the tab key on your keyboard to get to one in the eBay form. You’ll see it skips right over it. Frustrating, right? Many assistive technologies simulate keyboard navigation, so that’s the experience many assistive technology users will have.

Disabled buttons also tend to cause greater problems to people who make more mistakes when filling out forms. And this means many users with cognitive or learning impairments. Or people with dyslexia. Or problems with their motor skills. Or less tech savvy users. The list goes on.

So disabled buttons exclude users with disabilities. It’s one of the best reasons to stop using them.

What to do instead

Just don’t disable buttons! Have them enabled and then show an error message when the user clicks them.

Don’t trust me? Well, take it from A Definite Guide to Sensible Form Validations instead:

It is a bad practice to disable buttons. Disabling the button prevents our chance to tell the user what is wrong. The user keeps clicking the button and is totally in the dark why nothing happens. Keep the button enabled. Let the user click the button. Then show the message why it can’t proceed.

If you really, really want to indicate that a button is disabled, do some css magic and make it look a bit grey (but with sufficient contrasts). And then turn it green or blue when everything is filled in correctly. But keep the button enabled in the code at all times and put focus on an error message if it’s clicked and there’s something wrong.

Do you need help with this on your project? Our accessibility review service covers toggles, states, and interaction patterns across platforms.

The end of the thriller

The suspense is probably killing you..! Why was the “Add friend” button disabled on the Facebook profile?

The answer is – surprisingly – patriarchy! Ah, yet again, poor respect of women pops up as the cause of a problem in society.

She had activated a setting on Facebook that blocks friend requests from people that don’t share a mutual friend with her. It turns out that many women get spammed with friend requests from strange, creepy men. It makes me happy I’m not a woman, but at the same time embarrassed of my gender.

Luckily she was still around and could figure out why the button was disabled. We solved it by having her friend request me instead. But come to think of it, the disabled button almost cost me both a friendship and an important new insight! #feminism

So yeah…disabled buttons suck!

Accessible tech example: Queue management system

Hampus Sethfors — Tue, 20 Jun 2017 14:10:22 +0000

Standing in line isn’t fun for anyone, but it’s often extra annoying for people with low vision due to inaccessible technology. In a pharmacy in Stockholm we found an awesome, simple solution by Qmatic. Check out this 13 seconds video (captioned) to see it in action!

What’s usually the problem?

Below are some tasks that can be tricky for people with low vision when it comes to queue management systems:

Where do I press? Physical buttons are easy to find, but today many have moved over to touch screens.
What number is on my note? Usually the font is pretty big, but for people who are blind or have limited vision it can be impossible to read.
What number is now being served? Often there is just a sound notifying that a new number is being served, but requires good vision to see the actual number.

How they solved it

Qmatic solved this with a few simple features:

A tactile overlay on the touch screen, with braille writing for “low vision”. Even though most people with low vision can’t read braille, they’ll notice that it’s there and understand it’s for them.
A machine voice speaks the number on the note when it’s printed.
A machine voice speaks the number that is now being served. A great feature for anyone who doesn’t want to take their eyes of their phone!
Placed at a “wheelchair-friendly” height, with a tilt so that tall, standing people also can access it.

Great job Qmatic. This is a textbook example of how a few simple features can create an inclusive product and improve the user experience for everyone!

Need help with making your tech accessible?

Just contact us at [email protected] or say hi to us on Twitter @axesslab.

Accessibility according to actual people with disabilities

Hampus Sethfors — Sun, 04 Jun 2017 10:30:46 +0000

“If you have a disability, what’s the hardest thing about browsing the web?” The answers to Safia Abdalla’s tweet are truly eye-opening and shows us what web accessibility should really be about.

Photo: Francis Clarke for Wikimedia

The tweet that started it all

i'm curious to know: if you have a disability, what's the hardest thing about browsing the web?

rt for visibility, please and thanks!

— Safia Abdalla (@captainsafia) June 3, 2017

In this article I’ll summarize and group the main topics that people bring up in the thread.

But do click on the tweet and read through all the answers. It’s an awesome read for anyone interested in making the web a better place for all. And, in my opinion, a far better place to learn about accessibility than reading any checklist or standard.

Lack of captions

Videos without captions (subtitles) was by far the obstacle that most people commented on. Here is what a few had to say:

Being deaf, got to say captioning videos is number one issue for me

— Jay Jackson (@jjackson) 4 juni 2017

Video/audio with no captioning or transcript.

— Katelyn Reilly (@k_hack) 4 juni 2017

I’m hard of hearing so big pain for me is video with no captions. tweet or article just says “can u believe he said this?” & no summary

— Carol Carpenter (@carolmcarpenter) 3 juni 2017

Also, my sister says that she hates it when she comes across videos that are not closed captioned. She’s Deaf.

— Erica Boleyn (@radcrochetqueer) 3 juni 2017

Non-existing captions is something that can completely exclude users who are deaf or hard of hearing. But it affects many others as well. Anyone on the bus who forgot their headphones. Or some autistic users:

I’m Autistic and when I get overloaded, it’s harder to process auditory input. Especially if the person talking is offscreen or something

— act up, fight back (@UntoNuggan) 3 juni 2017

Many are hoping that automatic captioning solves this problem. But alas, not yet!

Not really YouTube’s auto subtitling is not accurate enough.

— Robin (@tohereknowswhe) 3 juni 2017

And the auto-captioning feature sadly isn’t available for most languages. So it’s still up to the video creators to caption.

Motion, animations and cluttered pages

Motion and animation can be annoying to anyone, but is extra frustrating to many users with cognitive impairments:

ADHD: If there’s a “subtle” animation always running, I cannot focus. Biggest offender: https://t.co/KgfCA4a7lB‘s header gradient

— Taylor Hunt (@tigt_) 3 juni 2017

Assuming ADHD counts, it’s hard to locate content on overly busy pages and animations are a nightmare of distraction. #clickthemonkey

— mkb (@mojinations) 4 juni 2017

related, I’m also autistic and can get frustrated with, or repelled by, glitzy mouseover effects/animations, sudden autoplay, etc.

— back at the holler (@elementnumber46) 3 juni 2017

Do your users a favor by not distracting them with autoplaying videos, advertisements or image carousels.

Wall of text

Many replies, especially from people with dyslexia or cognitive impairments, were about large chunks of text.

Dyslexic – not really seen as a disability, but large walls of text is painful.
Also never ending sentences and over complicated language.

— Mustafa Kurtuldu (@Mustafa_x) 3 juni 2017

When ppl type large blocks of text w/ no spaces added

— Dead Ass (@MeBeShe4815) 3 juni 2017

Huge paragraphs. A page on Wikipedia often consists of many long paragraphs with long sentences. I lose my place within seconds.

— Ava Jarvis Art (@AvaJarvisArt) 3 juni 2017

ADHD + large, uninterrupted blocks of text or small bits of animation not part of the main content of a page

— back at the holler (@elementnumber46) 3 juni 2017

Large paragraphs, too many moving images, too much content as videos (especially help files), no subtitles, pages with too much going on.

— Polenth Blake (@Polenth) 3 juni 2017

The solution is so simple. Just create more paragraphs and sub-headings! And throw in more bullet-lists. Voilà!

Small font size

Amazingly there’s no minimum font size requirement in the Web Content Accessibility Guidelines. Even though it affects so many low-vision users.

Nearly blind in my left eye. Tiny, thin font with low contrast to the background

— Andrew So (@AndrewDixonSo) 3 juni 2017

Fonts are often too small and sites break when I increase font sizes.

— Brandon Savage (@brandonsavage) 3 juni 2017

Tiny font size and certain animations.

— Morgan Estes (@morganestes) 3 juni 2017

Zooming problems

Some users with low vision point to layout and navigation problems when zooming or increasing font-size.

My daughter has low vision and has to use 300-500% magnification. Many web sites are hard to navigate at this level

— Kir Kolyshkin (@kolyshkin) 3 juni 2017

Neurological vision problems due to CFS/ME. Small fonts, I browse everything with fonts enlarged, but sometimes it screws up the layout.

— Maija Haavisto (@DiamonDie) 3 juni 2017

for visually challenged, it is understanding the layout

— VAMSI KRISHNA (@VamsiJKrishna) 3 juni 2017

Low contrasts and image of text

One of the cornerstones of accessibility, color contrast, is still a major problem in a lot of interfaces.

Lack of contrast between font color and background color. Photo backgrounds that overpower the text on top of them.

— Megan Lynch (@may_gun) 4 juni 2017

Text rendered as graphics instead of text with no alt tags, no image description. From websites to memes.

— Megan Lynch (@may_gun) 4 juni 2017

That’s definitely lack of contrasts in colors

— charles dominic (@gamescharlie79) 3 juni 2017

So it is vital for web designers and art directors to understand how to measure and create accessible color schemes. Check out our list of seven great, free color contrasts tools.

Bright color schemes

Bright color schemes can be a big problem for users with low vision and is something that gets too little focus in accessibility discussions. It was interesting how many commented on it in the thread, and the different strategies they had to get around the problem:

(cont) so this is fairly simple but I really appreciate the “night” modes that some things have. Less eye strain that way.

— Callie (@cxllielayne) 4 juni 2017

re: frequent & debilitating migraines, so many sites are coded with light color scheme&I can’t use them even w/ sunglasses on & monitors dim

— Pyrrh-T900XV1 (@xpyrrh) 3 juni 2017

I need to be able to get the article onto my Kindle Oasis to avoid backlight. I’ve also found the reader feature to be hit-and-miss.

— Kal Cobalt (@kalcobalt) 4 juni 2017

Relying only on color

This is also a cornerstone of accessibility that so many miss.

Colourblind. Text on background is usually fine, but things like colour-coded toggles, heatmaps, etc can be hard.

— Dan (@phrawzty) 4 juni 2017

It’s really easy to test, just view your site in greyscale. Here’s an example of a toggle that’s really difficult to understand when you take colors away. Which one is on and which one is off?

And it’s not only people who are color-blind who need information to be conveyed in other ways than color:

Sleep disorder: I have to read after 5pm with f.lux cranked up all the way, so sites that assume hyperlinks can be blue w/no underline…

— Taylor Hunt (@tigt_) 3 juni 2017

Mouse-focused sites

Even in this day of the touch-screen-revolution, too many sites still rely on mouse interaction. Especially for navigation on large screens. That needs to change.

I don’t have one but my mother has Parkinson diseas and mouse Interactions are really hard for her

— A dev has no name (@KodierKroete) 4 juni 2017

The number of sites which insist on using mouse over as the only means of menu triggering.

— Zack (@zkline) 3 juni 2017

For some users with motor impairments that navigate using only their keyboard, a clear focus outline is vital to being able to navigate the web.

Lack of focus outlines. Especially on links (they look ugly to most designers so they remove them) and custom components (eg dropdowns).

— nuton.dev (@NutonDev) 3 juni 2017

Too small touch-targets

This topic is related to the mouse-focused heading above. Many people bring up the problem with too small touch targets.

My brother-in-law has cerebral palsy, buttons and links are too small for him to use. He can only use touch because he can’t hold a mouse.

— Gary Rozanc (@garyrozanc) 3 juni 2017

Mobile twitter is also rly hard bc I have a tremor + visual-spatial processing issues. Often will click on the wrong thing by mistake.

— (((self crytptid))) (@plathituudes) 3 juni 2017

A great new insight for me came from Dave Ross who brought up the problem of too large click targets:

(Sometimes I have hand tics that make precise mouse control hard or I tap a touchscreen screen unnecessarily)

— Dave Ross (@csixty4) 3 juni 2017

Multi-touch gestures are also a deal-breaker for some users.

Yes! Kindle app has this “tap twice & hold” to get to the menu 4 display settings on books and it is super difficult. (Hand deformity)

— Kristen Anne Strater (@KristenAnneSF) 4 juni 2017

These are actually some of the more common problems we find in our Accessibility Reviews ever since mobile browsing became the norm. Fingers are never as precise as a mouse pointer, even with perfect motor skills.

CAPTCHAS

Finally, we end with a classic accessibility failure: the dreaded CAPTCHA. Annoying everyone who comes across it, but completely locking out many with visual impairments or learning disabilities.

As to what drives her nuts, non-accessible captchas are the top. It can severely limit which services are available to her.

— Danny Does Code (@DannyDoesCode) 3 juni 2017

Final thoughts

Reflecting on the answers to this thread, a few things become clear:

Web accessibility is about so much more than just blind people with screen readers.
Basically everything that people with disabilities comment on are things that annoy everyone, so fixing these issues makes your interface better for all users!
A lot of what people comment on is not covered by the Web Content Accessibility Guidelines. So you need to test with users with disabilities!

So thank you Safia Abdalla for tweeting your question. And thanks for everyone who responded and taught me (@hampelusken), and many others, a lot about accessibility.

WCAG 2.1 – what’s up and coming?

Hampus Sethfors — Wed, 17 May 2017 08:53:24 +0000

The Web Content Accessibility Guidelines 2.1 are planned to be released in June 2018. Even though a lot may change before the release, we already have some indication of what’s going to be new in the 2.1 update.

The journey ahead

When I’m writing this, it’s just over a year before the planned release in June 2018. WCAG 2.1 is on a journey through seven iterations called “Working Drafts”.

Right now “Working Draft 2” is out, and a new one will be released each month from now until November 2017. Everyone is invited to comment on the working drafts on the WCAG 2.1 GitHub.

So what’s going to be in it?

Well, it’s hard to know for sure right now.

In the first working draft released last month there were 28 newly proposed success criteria. Compare that to the total of 61 success criteria in WCAG 2.0, and you understand that it would be quite a big update.

However, in Working Draft 2, only 4 of the 28 new success criteria are left. So it’s hard to know how they will change in the future. A few of the 24 criteria that didn’t make the cut in Working Draft 2 will probably come back, but we don’t know which ones.

One thing we do know is that WCAG 2.1 is going to be backward compatible with WCAG 2.0, meaning that if you fulfill 2.1 you’ll automatically fulfill 2.0.

Four likely new criteria

These are four newly proposed success criteria that will probably be in WCAG 2.1 in some shape or form:

1.4.10 – Resize content, level A
Requires that content can be resized up to 400% without the loss of content or functionality. And without horizontal scroll. This is a change from the 200% requirement in WCAG 2.0

1.4.11 – Graphics contrast, level AA
Extends the contrast requirements to include graphical objects that are “essential for understanding content or functionality”. So no more low contrast hamburger menus or tab icons allowed. However, logotypes are sadly excluded from this success criterion.

2.2.6 – Interruptions, level AA
Requires an “easily available mechanism to postpone and suppress interruptions and changes in content”. They are trying to address popups that interrupt the users’ focus, which is annoying to everyone but extra tough on people with some cognitive impairments like adhd or autism.

3.2.6 – Accidental activation, level A
This addresses a problem many people with lowered motor skills have: activating the wrong button or link by mistake. The success criterion requires activation to be on the up-event, so that a user can touch the screen, realize they are touching the wrong target and move their mouse or finger to the right target.

Some proposed criteria that might make it

Outside of the four likely new criteria, there are plenty of other proposals that might make it into WCAG 2.1. Here are a few that we think look extra interesting:

Target sizes. Require at least 44*44 pixel target sizes for touch and 22*22 pixels for mouse targets.
Plain language. “Instructions, labels, navigation, error messages in simple tense, common words, basic rules of grammar, clear writing.”
Animations. “No motion over 3 seconds as a result of a user activating something, or provide a way to turn it off. Addresses parallax scrolling.”

Interested in more? Read this great blogpost by David MacDonald on all proposed news:

Quick guide to WCAG.2.1

Milestones in the past and future

Here’s a quick summary of the long history of the WCAG, and some planned milestones in the future. As you can see, the standard really does move forward at great speeds compared to glaciers.

1999 – WCAG 1.0
2008 – WCAG 2.0
2018 – WCAG 2.1 (planned)
2020 – WCAG 3.0 (planned)

A lot has changed in the world of tech since 2008, so the 2.1 update is welcome. For example, the use of touch screens has exploded and so has the knowledge of cognitive impairments. We’re happy to see that WCAG 2.1 addresses both of those changes, with quite a few new criteria focusing on touch and cognition.

Follow us on Twitter for more accessibility news and tips

@hampelusken and @axesslab

Seven tips for user testing with users with disabilities

Hampus Sethfors — Tue, 16 May 2017 14:32:41 +0000

Like regular user tests, it’s not rocket science to test with users with disabilities. And it will give you so much more than reading checklists or testing with non-disabled users.

Tips for testing

Earlier, I wrote an article on why you should test with people with disabilities:

Skip WCAG! User tests with users with disabilities instead.

So in that article I go through why. But now I’d like to focus on how.

Below are seven practical tips that I’ve learned through years of conducting user tests on digital products with people with disabilities.

1. Don’t call it “user test”

The word “test” is something most people associate with anxiety, failure and other rotten feelings. And it can be extra negatively loaded for many people with disabilities, who may have been forced to go through tests to show they have a lowered intelligence or lowered functional ability.

So call the user tests something else when you communicate to test subjects. For example: “Feedback session”. This makes it clear to the users that you’re looking to improve your product, so they know they can’t do anything wrong.

2. Get help recruiting test subjects

People are often very supportive when you say you want to improve the accessibility of your product. So go search for groups to collaborate with. Maybe find someone in charge at an elderly center nearby or post in a Facebook group for people with autism. Or if it’s too big of a hassle, contact us and we will recruit and do the tests for you.

3. Give some love to the invitation

A good invitation will both make the test subject feel more comfortable and reduce the number of people who don’t show up to the test session. So make it clear in the invitation on what is going to happen at the user test. This is extra important for people with cognitive impairments who might have a hard time imagining what will happen. Include this in the invitation:

Image and name of the people they’ll meet, for example the test leader.
Time – how long will the session last.
Address and direct link to a map.
Details on what to do when I get there. Which level to go to? Is there a code to get in? Who do they ask for when they get there?
Contact information and what to do if they’re late or have to cancel.
What to bring. For example: “If you use any assistive technology like a screen reader, it would be great if you bring it to the session”.

4. Send Reminders

Send at least one reminder before the user test. Preferably in a text message. This will be super helpful for everyone and reduce your no-shows. And for people who have a hard time with time management, these reminders will be crucial. In Sweden we are using a service called “There-in-time” but you can use any reminder service out there really.

5. Don’t ask questions, give tasks

I still fail at this a lot. When leading a user test, I find myself asking “What would you do to find the contact information?” And the user starts explaining instead of actually doing it on the computer: “I would probably go to Google and search for it.” And I have to ask them “Well, please do that!” which makes them feel stupid for not understanding they were meant to actually do it, and I feel stupid for asking such a bad question. Instead go straight to the point: “Find the contact information”.

6. Be patient

It can often take a person with disabilities more time to complete a test scenario, get set up with their assistive technology, process information, navigate the site etcetera. Be patient as a test leader. Skip a test scenario if there is not enough time at the end of the test instead of speeding through all of them.

7. Don’t force users to speak out loud

Many user tests apply the think-aloud-method, where you want the user to say what they think. You can still use this for most users with disabilities, but make sure to give alternatives. Some people find this type of communication really hard. So instead of saying: “Tell me what you’re thinking when using the site” say “If you want to, you can say what you’re thinking when using the site. Otherwise you can tell me after we’re done.”

If you need help getting started, we can help, or we can even do the user testing for you. In any case, we hope this guide was useful.

We are Axess Lab

Hampus Sethfors — Tue, 16 May 2017 13:57:02 +0000

Hello! We are Axess Lab, a Swedish startup focusing on digital accessibility. Glad you’ve found us!

We work as hard as we can to make everyday life easier for everyone, regardless of disability. We build digital products and help others who share our mission.

Access Lab

What’s the story behind the name Axess Lab? Well, we create innovative technology that give more people access to society, so we think Axess Lab suits us well. But why not just “Access Lab”? Simply because everything is cooler with an x!

We’ll use these articles to share what we know with you. Enjoy!

Axess Lab

System Generated PDF Accessibility

What’s the problem?

Example: an inaccessible system generated document

Example: an accessible system-generated document

, and so on for headings

and so on for headings

Figure out how accessible your system generated documents are

Three ways to approach the challenge

1. System upgrade or migration – “Accessibility by design”

2. Accessibility Add-Ons – “Accessibility by Remediation”

3. Change to HTML (with PDF as alternative)

Where to Start?

Optimizing VoiceOver in an iOS E-Commerce App with Conditional Accessibility

Conditionally Grouping PLP Elements (Actions Included)

PDP Options Becoming Adjustable

When One Fix Breaks Another

Optimizing VoiceOver Without Collateral Damage

Same Pattern Added to the Wishlist

One Wishlist, Various Wishes Fulfilled

Final thoughts

Making an iOS E-Commerce Product List Accessible to VoiceOver and Beyond

Product List Page: The Hidden Problems

Labels and Actions: Fixing the PLP

Wishlist: Too Much Information

Fixing the Wishlist: Grouping Information

Added to the Wishlist: Keyboard and Voice Control

We have a PLP Problem

Breaking the Original Premise

Final thoughts

Making an iOS E-Commerce Product Detail Page Accessible to VoiceOver and Beyond

The Accessibility Issues Hiding in Plain Sight

Hide-and-Seek (Labels and Headings)

Turning Visual Selection Into Accessible Feedback

Bringing the Page to Life With VoiceOver

A Little Less Full Keyboard Access

Voice Control Comes Along for Free

Final thoughts

Accessibility of Fuel and EV Charging Stations: Wheelchair user insights and the European Accessibility Act

What Wheelchair Users Experience at Fuel or Charging Stations

1. Needing assistance because of the inaccessibility

2. Steps and Curbs Are Major Obstacles

3. Equipment is Out of Reach

4. Unstaffed Stations Are a Problem

5. Big Differences Between Stations

6. Apps Make it Easier

Summary of wheelchair users’ experiences at fuel and charging stations

Fuel and Charging Stations under the European Accessibility Act

A new specification for accessible charging stations has been published

Want a helping hand?

ADA’s New 2026 Deadline: What Tech Vendors Need To Know

What’s happening in April 2026?

Who does this affect?

1. Tech vendors selling to US governments

2. Integrators and service providers

3. Agencies using off‑the‑shelf software

When is the deadline?

Are there any exceptions?

Archived content

Third‑party content

Certain live content

Legacy documents

What should tech vendors do now?

1. Get an accessibility audit

2. Publish a VPAT

3. Start remediation early

4. Train your teams

Why this matters: more than compliance

How Axess Lab can help

Professional accessibility audits

VPAT creation & publication

Developer & designer training

Ongoing accessibility support

Final thoughts

VPAT – Volountary Product Accessibility Template

What is a VPAT?

Why use a VPAT?

How do I get one?

What does it cost?

How Button Traits can make a chaotic iOS app accessible

,
and so on for headings