3 articles tagged “accessibility” — software, engineering, and related writing by idmontie.

Accessibility blog posts - idmontie's Portfolio

"use strict";
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = {
    a: "a",
    code: "code",
    h2: "h2",
    li: "li",
    p: "p",
    pre: "pre",
    ul: "ul",
    ...props.components
  };
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "Throughput is the name of the game now that the majority of engineers are using AI coding agents to write code. Delivering high quality product experiences that still provide accessible functionality is as important as ever."
    }), "\n", _jsx(_components.p, {
      children: "At Couchsurfing, I wanted to make sure that our web applications were as accessible as possible. As with my other articles touching on design systems and component architecture, my goal was to make it easy to write accessible applications, and make it extremely difficult – if not impossible – to write create bad experiences."
    }), "\n", _jsx(_components.p, {
      children: "This doesn’t just help those that need to use accessibility tools, but also uplifts the experience for everyone. Keyboard navigation works better, buttons are easier to click or press on any device, etc."
    }), "\n", _jsx(_components.h2, {
      children: "Make the Wrong Way the Hard Way"
    }), "\n", _jsx(_components.p, {
      children: "Let’s start at the bottom of the design hierarchy and recognize that if something is broken at the lowest level, there isn’t much hope of fixing it when delivering features or having a coding agent write code that utilizes that low level code."
    }), "\n", _jsxs(_components.p, {
      children: ["From ensuring that the low level tokens pass contrast rations, to ensuring that buttons always have an accessible label, our goal should be that if an engineer or coding agent uses a component from our component library, we provide an accessible experience. Writing good components is always a balancing act between creating a component that is too rigid, and one that is too flexible. The more flexible a component, the easier it is to use in the wrong way. I’ve ", _jsx(_components.a, {
        href: "/blog/post/2025-01-12-api-surfaces",
        children: "written about allowing too many boolean props"
      }), " in components before that can lead to a cartesian explosion in different component states, but also think about allowing too many pass-through props."]
    }), "\n", _jsx(_components.p, {
      children: "If, for example, we allow ariaLabel to be passed through to the button component, when do we expect engineers to pass in the prop? Leaving that question open means that we can end up in a case where we aren’t passing the prop when we need to, or we pass it in and conflict with the default accessible label of the button which would just be the content."
    }), "\n", _jsx(_components.p, {
      children: "When we split up components into their intended usage, it ends up being more clear when we should force an ariaLabel to be provided, and when we should just let the content act as the label."
    }), "\n", _jsx(_components.p, {
      children: "As a concrete example, I often have an IconButton split from the Primary|SecondaryButton family:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-jsx",
        children: " export interface IconButton extends CoreButtonProps {\n   ariaLabel: string;\n   icon: ReactNode;\n }\n \n export interface PrimaryButton extends CoreButtonProps {\n   label: string;\n   prefixIcon?: ReactNode;\n }\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["The rest of the props have been removed so we can focus on the label. I used ", _jsx(_components.code, {
        children: "ariaLabel"
      }), " as a required string, to indicate that we aren’t showing the label, but for accessibility purposes we require one. And on PrimaryButton, we don’t allow that prop at all, but we do require a string label. If we allowed arbitrary ReactNodes, we might not guarentee that it is text that can be detected as the label by the browser. This is also where I would enforce localization, but I have written ", _jsx(_components.a, {
        href: "/blog/post/2023-08-19-localization",
        children: "separate articles about that"
      }), "."]
    }), "\n", _jsx(_components.h2, {
      children: "Catching Issues"
    }), "\n", _jsx(_components.p, {
      children: "With our low level components set up for success, we beed a way to ensure we don’t introduce any issues – and we would like to catch any existing issues for any components that already exist. We’ll tackle this with a wide approach of tools:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsx(_components.li, {
        children: "Linting"
      }), "\n", _jsx(_components.li, {
        children: "Unit tests"
      }), "\n", _jsx(_components.li, {
        children: "Storybook"
      }), "\n", _jsx(_components.li, {
        children: "E2E"
      }), "\n"]
    }), "\n", _jsxs(_components.p, {
      children: ["At the linting level, I recommend looking at ", _jsx(_components.a, {
        href: "https://github.com/jsx-eslint/eslint-plugin-jsx-a11y",
        children: "eslint-plugin-jsx-a11y"
      }), " which catches a lot of bad patterns that seep into code. At Couchsurfing, we would also write out own custom rules on top of these any time we noticed a bad pattern being introduced."]
    }), "\n", _jsxs(_components.p, {
      children: ["For unit tests, we maintain a 80%+ code coverage metric which helps ensure we are writing tests for components. These gates fail the CI if they fall below the threshold. We would also use ", _jsx(_components.a, {
        href: "https://dev.to/ibn_abubakre/automated-testing-with-jest-axe-6fa",
        children: "jest-axe"
      }), " as a mechanism for catching a11y issues at the component level. The last tool we utilized as a jest plugin that turns all console warning and console errors into failing tests. If any unit test had an unexpected console warn or error, the entire test would fail."]
    }), "\n", _jsx(_components.p, {
      children: "At the storybook level, we would leverage the a11y plugin and periodically check if any components were breaking any issues. Typically these would be color contrast issues and we would work with designers to determine how best to fix them."
    }), "\n", _jsx(_components.p, {
      children: "For E2E testing, let’s shift our focus to Feature Delivery."
    }), "\n", _jsx(_components.h2, {
      children: "Feature Delivery"
    }), "\n", _jsx(_components.p, {
      children: "Delivering features typically has a different software lifecycle than working on a component library. Features are steadily shipped out, perhaps behind a feature flag, and combine a wide variety of design system level components and what I call “app level” components. These are reusable chunks of functionality that get shared across features in the application that might not belong to the design system. Maybe its a user card with functionality already wired up to load the user’s data. Or perhaps its an animated statistic that gets reused in a few spots in the application, but hasn’t been pulled into the design system."
    }), "\n", _jsx(_components.p, {
      children: "I typically treat these “app level” components similarly to that of a design system component. But in practice it is much harder to maintain the level of documentation, testing, and accessibility requirements at the “app level” since these are not all contained within a structured design system. These app level components might be scattered across different domains in the application, or maybe even different repos."
    }), "\n", _jsx(_components.p, {
      children: "To help ensure that accessibility is maintained across all these components and across the application as a whole, I like to add page level scanning as part of the continuous delivery pipeline. These type of tests might not run on every Pull Request, instead the might be a lagging indicator that runs nightly, and smoke checks a bunch of different pages in the application."
    }), "\n", _jsx(_components.p, {
      children: "One toolset I like to run nightly is Lighthouse CLI which checks a bunch of pages, and emits a reports that can be joined together. The output then goes to Slack or a ticket tracking system to be triaged and worked on by engineers. The nice thing about Lighthouse is that it already comes with a suite of accessibility checks that run against the actual running web application that customers would see."
    }), "\n", _jsx(_components.p, {
      children: "Even with jest unit tests and lint rules, there are some semantic accessibility checks that can still fail when components are composed together. For example, a link may have no descernable name when components are composed together and presented to the user. Or maybe the heading hierarchy of the page is out of order. In any case, the Lighthouse CLI audit will often catch these kind of issues."
    }), "\n", _jsx(_components.h2, {
      children: "Conclusion"
    }), "\n", _jsx(_components.p, {
      children: "Knowing all the different edge-cases that can cause accessibility issues is a challenge, but we can catch a lot of the issues early in the development cycle. This is especially true if we set engineering and coding agents up for success by building solid component libraries. The better these building blocks, the better the application will be overall. And with the majority of code being written by AI coding agents, having different types of checks at different points in the process will help catch issues that the agent may not have reasoned through."
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, {
    ...props,
    children: _jsx(_createMdxContent, {
      ...props
    })
  }) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>Throughput is the name of the game now that the majority of engineers are using AI coding agents to write code. Delivering high quality product experiences that still provide accessible functionality is as important as ever.</p>
<p>At Couchsurfing, I wanted to make sure that our web applications were as accessible as possible. As with my other articles touching on design systems and component architecture, my goal was to make it easy to write accessible applications, and make it extremely difficult – if not impossible – to write create bad experiences.</p>
<p>This doesn’t just help those that need to use accessibility tools, but also uplifts the experience for everyone. Keyboard navigation works better, buttons are easier to click or press on any device, etc.</p>
<h2>Make the Wrong Way the Hard Way</h2>
<p>Let’s start at the bottom of the design hierarchy and recognize that if something is broken at the lowest level, there isn’t much hope of fixing it when delivering features or having a coding agent write code that utilizes that low level code.</p>
<p>From ensuring that the low level tokens pass contrast rations, to ensuring that buttons always have an accessible label, our goal should be that if an engineer or coding agent uses a component from our component library, we provide an accessible experience. Writing good components is always a balancing act between creating a component that is too rigid, and one that is too flexible. The more flexible a component, the easier it is to use in the wrong way. I’ve <a href="/blog/post/2025-01-12-api-surfaces">written about allowing too many boolean props</a> in components before that can lead to a cartesian explosion in different component states, but also think about allowing too many pass-through props.</p>
<p>If, for example, we allow ariaLabel to be passed through to the button component, when do we expect engineers to pass in the prop? Leaving that question open means that we can end up in a case where we aren’t passing the prop when we need to, or we pass it in and conflict with the default accessible label of the button which would just be the content.</p>
<p>When we split up components into their intended usage, it ends up being more clear when we should force an ariaLabel to be provided, and when we should just let the content act as the label.</p>
<p>As a concrete example, I often have an IconButton split from the Primary|SecondaryButton family:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-jsx"> export interface IconButton extends CoreButtonProps {
   ariaLabel: string;
   icon: ReactNode;
 }
 
 export interface PrimaryButton extends CoreButtonProps {
   label: string;
   prefixIcon?: ReactNode;
 }
</code></pre></div>
<p>The rest of the props have been removed so we can focus on the label. I used <code>ariaLabel</code> as a required string, to indicate that we aren’t showing the label, but for accessibility purposes we require one. And on PrimaryButton, we don’t allow that prop at all, but we do require a string label. If we allowed arbitrary ReactNodes, we might not guarentee that it is text that can be detected as the label by the browser. This is also where I would enforce localization, but I have written <a href="/blog/post/2023-08-19-localization">separate articles about that</a>.</p>
<h2>Catching Issues</h2>
<p>With our low level components set up for success, we beed a way to ensure we don’t introduce any issues – and we would like to catch any existing issues for any components that already exist. We’ll tackle this with a wide approach of tools:</p>
<ul>
<li>Linting</li>
<li>Unit tests</li>
<li>Storybook</li>
<li>E2E</li>
</ul>
<p>At the linting level, I recommend looking at <a href="https://github.com/jsx-eslint/eslint-plugin-jsx-a11y">eslint-plugin-jsx-a11y</a> which catches a lot of bad patterns that seep into code. At Couchsurfing, we would also write out own custom rules on top of these any time we noticed a bad pattern being introduced.</p>
<p>For unit tests, we maintain a 80%+ code coverage metric which helps ensure we are writing tests for components. These gates fail the CI if they fall below the threshold. We would also use <a href="https://dev.to/ibn_abubakre/automated-testing-with-jest-axe-6fa">jest-axe</a> as a mechanism for catching a11y issues at the component level. The last tool we utilized as a jest plugin that turns all console warning and console errors into failing tests. If any unit test had an unexpected console warn or error, the entire test would fail.</p>
<p>At the storybook level, we would leverage the a11y plugin and periodically check if any components were breaking any issues. Typically these would be color contrast issues and we would work with designers to determine how best to fix them.</p>
<p>For E2E testing, let’s shift our focus to Feature Delivery.</p>
<h2>Feature Delivery</h2>
<p>Delivering features typically has a different software lifecycle than working on a component library. Features are steadily shipped out, perhaps behind a feature flag, and combine a wide variety of design system level components and what I call “app level” components. These are reusable chunks of functionality that get shared across features in the application that might not belong to the design system. Maybe its a user card with functionality already wired up to load the user’s data. Or perhaps its an animated statistic that gets reused in a few spots in the application, but hasn’t been pulled into the design system.</p>
<p>I typically treat these “app level” components similarly to that of a design system component. But in practice it is much harder to maintain the level of documentation, testing, and accessibility requirements at the “app level” since these are not all contained within a structured design system. These app level components might be scattered across different domains in the application, or maybe even different repos.</p>
<p>To help ensure that accessibility is maintained across all these components and across the application as a whole, I like to add page level scanning as part of the continuous delivery pipeline. These type of tests might not run on every Pull Request, instead the might be a lagging indicator that runs nightly, and smoke checks a bunch of different pages in the application.</p>
<p>One toolset I like to run nightly is Lighthouse CLI which checks a bunch of pages, and emits a reports that can be joined together. The output then goes to Slack or a ticket tracking system to be triaged and worked on by engineers. The nice thing about Lighthouse is that it already comes with a suite of accessibility checks that run against the actual running web application that customers would see.</p>
<p>Even with jest unit tests and lint rules, there are some semantic accessibility checks that can still fail when components are composed together. For example, a link may have no descernable name when components are composed together and presented to the user. Or maybe the heading hierarchy of the page is out of order. In any case, the Lighthouse CLI audit will often catch these kind of issues.</p>
<h2>Conclusion</h2>
<p>Knowing all the different edge-cases that can cause accessibility issues is a challenge, but we can catch a lot of the issues early in the development cycle. This is especially true if we set engineering and coding agents up for success by building solid component libraries. The better these building blocks, the better the application will be overall. And with the majority of code being written by AI coding agents, having different types of checks at different points in the process will help catch issues that the agent may not have reasoned through.</p>


Throughput is the name of the game now that the majority of engineers are using AI coding agents to write code. Delivering high quality product experiences that still provide accessible functionality is as important as ever.

At Couchsurfing, I wanted to make sure that our web applications were as accessible as possible. As with my other articles touching on design systems and component architecture, my goal was to make it easy to write accessible applications, and make it extremely difficult – if not impossible – to write create bad experiences.

This doesn’t just help those that need to use accessibility tools, but also uplifts the experience for everyone. Keyboard navigation works better, buttons are easier to click or press on any device, etc.

## Make the Wrong Way the Hard Way

Let’s start at the bottom of the design hierarchy and recognize that if something is broken at the lowest level, there isn’t much hope of fixing it when delivering features or having a coding agent write code that utilizes that low level code.

From ensuring that the low level tokens pass contrast rations, to ensuring that buttons always have an accessible label, our goal should be that if an engineer or coding agent uses a component from our component library, we provide an accessible experience. Writing good components is always a balancing act between creating a component that is too rigid, and one that is too flexible. The more flexible a component, the easier it is to use in the wrong way. I’ve [written about allowing too many boolean props](/blog/post/2025-01-12-api-surfaces) in components before that can lead to a cartesian explosion in different component states, but also think about allowing too many pass-through props.

If, for example, we allow ariaLabel to be passed through to the button component, when do we expect engineers to pass in the prop? Leaving that question open means that we can end up in a case where we aren’t passing the prop when we need to, or we pass it in and conflict with the default accessible label of the button which would just be the content.

When we split up components into their intended usage, it ends up being more clear when we should force an ariaLabel to be provided, and when we should just let the content act as the label.

As a concrete example, I often have an IconButton split from the Primary|SecondaryButton family:

```jsx
 export interface IconButton extends CoreButtonProps {
   ariaLabel: string;
   icon: ReactNode;
 }
 
 export interface PrimaryButton extends CoreButtonProps {
   label: string;
   prefixIcon?: ReactNode;
 }
```

The rest of the props have been removed so we can focus on the label. I used `ariaLabel` as a required string, to indicate that we aren’t showing the label, but for accessibility purposes we require one. And on PrimaryButton, we don’t allow that prop at all, but we do require a string label. If we allowed arbitrary ReactNodes, we might not guarentee that it is text that can be detected as the label by the browser. This is also where I would enforce localization, but I have written [separate articles about that](/blog/post/2023-08-19-localization).


## Catching Issues

With our low level components set up for success, we beed a way to ensure we don’t introduce any issues – and we would like to catch any existing issues for any components that already exist. We’ll tackle this with a wide approach of tools:

- Linting
- Unit tests
- Storybook
- E2E

At the linting level, I recommend looking at [eslint-plugin-jsx-a11y](https://github.com/jsx-eslint/eslint-plugin-jsx-a11y) which catches a lot of bad patterns that seep into code. At Couchsurfing, we would also write out own custom rules on top of these any time we noticed a bad pattern being introduced.

For unit tests, we maintain a 80%+ code coverage metric which helps ensure we are writing tests for components. These gates fail the CI if they fall below the threshold. We would also use [jest-axe](https://dev.to/ibn_abubakre/automated-testing-with-jest-axe-6fa) as a mechanism for catching a11y issues at the component level. The last tool we utilized as a jest plugin that turns all console warning and console errors into failing tests. If any unit test had an unexpected console warn or error, the entire test would fail.

At the storybook level, we would leverage the a11y plugin and periodically check if any components were breaking any issues. Typically these would be color contrast issues and we would work with designers to determine how best to fix them.

For E2E testing, let’s shift our focus to Feature Delivery.

## Feature Delivery

Delivering features typically has a different software lifecycle than working on a component library. Features are steadily shipped out, perhaps behind a feature flag, and combine a wide variety of design system level components and what I call “app level” components. These are reusable chunks of functionality that get shared across features in the application that might not belong to the design system. Maybe its a user card with functionality already wired up to load the user’s data. Or perhaps its an animated statistic that gets reused in a few spots in the application, but hasn’t been pulled into the design system.

I typically treat these “app level” components similarly to that of a design system component. But in practice it is much harder to maintain the level of documentation, testing, and accessibility requirements at the “app level” since these are not all contained within a structured design system. These app level components might be scattered across different domains in the application, or maybe even different repos.

To help ensure that accessibility is maintained across all these components and across the application as a whole, I like to add page level scanning as part of the continuous delivery pipeline. These type of tests might not run on every Pull Request, instead the might be a lagging indicator that runs nightly, and smoke checks a bunch of different pages in the application.

One toolset I like to run nightly is Lighthouse CLI which checks a bunch of pages, and emits a reports that can be joined together. The output then goes to Slack or a ticket tracking system to be triaged and worked on by engineers. The nice thing about Lighthouse is that it already comes with a suite of accessibility checks that run against the actual running web application that customers would see.

Even with jest unit tests and lint rules, there are some semantic accessibility checks that can still fail when components are composed together. For example, a link may have no descernable name when components are composed together and presented to the user. Or maybe the heading hierarchy of the page is out of order. In any case, the Lighthouse CLI audit will often catch these kind of issues.

## Conclusion

Knowing all the different edge-cases that can cause accessibility issues is a challenge, but we can catch a lot of the issues early in the development cycle. This is especially true if we set engineering and coding agents up for success by building solid component libraries. The better these building blocks, the better the application will be overall. And with the majority of code being written by AI coding agents, having different types of checks at different points in the process will help catch issues that the agent may not have reasoned through.

Building Accessibility into the Pipeline

"use strict";
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = {
    a: "a",
    blockquote: "blockquote",
    code: "code",
    h2: "h2",
    li: "li",
    p: "p",
    pre: "pre",
    ul: "ul",
    ...props.components
  };
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "Accessibility problems usually have recognizable solutions. A button needs an accessible name, text needs sufficient contrast, and a modal needs sensible focus management."
    }), "\n", _jsx(_components.p, {
      children: "The implementation may be wrong, but the path toward fixing it is usually understood."
    }), "\n", _jsx(_components.p, {
      children: "Then there are toasts."
    }), "\n", _jsx(_components.h2, {
      children: "What is a Toast"
    }), "\n", _jsx(_components.p, {
      children: "A toast is a small, temporary message that appears in response to an event or user action. It might confirm success, report an error, or tell the user that an asynchronous operation has completed."
    }), "\n", _jsx(_components.p, {
      children: "In Gmail, when you delete an email, the user is given a toast notification that allows the user to undo the action."
    }), "\n", _jsx(_components.p, {
      children: "In some systems, an action is asynchronous, and a toast is used to notify the user after the action has completed without blocking the user on a screen/form to wait for the result."
    }), "\n", _jsx(_components.h2, {
      children: "Why toasts are difficult"
    }), "\n", _jsxs(_components.p, {
      children: ["Dialogs have ", _jsx(_components.code, {
        children: "<dialog>"
      }), ". Buttons have ", _jsx(_components.code, {
        children: "<button>"
      }), ". Forms have ", _jsx(_components.code, {
        children: "<form>"
      }), ", ", _jsx(_components.code, {
        children: "<input>"
      }), ", and ", _jsx(_components.code, {
        children: "<label>"
      }), ". Toasts have… ", _jsx(_components.code, {
        children: "<div>"
      }), "."]
    }), "\n", _jsx(_components.p, {
      children: "For example, here is an HTML-only modal example:"
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        children: " <dialog id=\"hello_modal\" class=\"modal\">\n  <div class=\"modal-box\">\n    <h3 class=\"text-lg font-bold\">Hello!</h3>\n  </div>\n</dialog>\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "Native elements provide browsers and assistive technologies with semantics they already understand."
    }), "\n", _jsx(_components.p, {
      children: "The main issue is that there doesn’t exist any basic HTML element that perfectly encompasses a toast. Any implementation of a toast ends up being a custom implementation for whatever system implements it."
    }), "\n", _jsx(_components.p, {
      children: "Then there is the large amount of usability issues:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsx(_components.li, {
        children: "On large screens, toasts end up going unnoticed."
      }), "\n", _jsx(_components.li, {
        children: "On any page with visual clutter - for example a page with a map on it that contains map controls for zooming, searching, etc - a toast can often be lost in the visual clutter."
      }), "\n", _jsx(_components.li, {
        children: "A toast is often distracting. If the toast automatically dismisses itself, then the user only has a short period of time to read or interact with the message. If the toast does not automatically dismiss, it distracts the user from their flow by requiring them to dismiss it."
      }), "\n", _jsx(_components.li, {
        children: "If a user is using any screen magnification software, the toast can go unnoticed since it might be outside of the magnification window."
      }), "\n", _jsx(_components.li, {
        children: "A toast appearing is typically disconnected from the action that was taken, meaning the user may not understand the relationship between the toast and action that triggered it."
      }), "\n"]
    }), "\n", _jsx(_components.h2, {
      children: "What do we do about it?"
    }), "\n", _jsxs(_components.p, {
      children: ["The next question is of course: so what do we do about it? Can we make toasts accessible for users? Primer - the component library created by GitHub - has decided that ", _jsx(_components.a, {
        href: "https://primer.style/accessibility/patterns/accessible-notifications-and-messages/",
        children: "toasts were not worth the effort"
      }), ":"]
    }), "\n", _jsxs(_components.blockquote, {
      children: ["\n", _jsx(_components.p, {
        children: "Toasts pose significant accessibility concerns and are not recommended for use."
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "The accessibility problem with toasts isn't merely that screen readers can't announce them. It's that the entire interaction model assumes the user will notice a temporary piece of UI appearing somewhere else on the screen."
    }), "\n", _jsx(_components.p, {
      children: "For simple actions, the Primer documentation suggests to simply have a banner on the next page after a form submission with any additional information for successful states. The user successfully created an issue? Redirect to the issue. Need to provide feedback after a complex action? Use a banner at the top of the resulting page with the message."
    }), "\n", _jsxs(_components.p, {
      children: ["There are also many discussions on YCombinator, such as ", _jsx(_components.a, {
        href: "https://news.ycombinator.com/item?id=46135145",
        children: "this one"
      }), " where users argue about how useful toasts really are."]
    }), "\n", _jsxs(_components.blockquote, {
      children: ["\n", _jsx(_components.p, {
        children: "Toasts are a great way to lose information."
      }), "\n"]
    }), "\n", _jsx(_components.p, {
      children: "On Couchsurfing, we had a similar experience with toasts. We implemented toasts to alert the user that they needed to turn on Geolocation permissions to use certain features. We rendered the toast correctly, it had sufficient contrast, and assistive technology would announce it properly. None of that mattered though because users simply wouldn’t notice it. Toasts would get lost in the clutter of controls on our pages with maps on them."
    }), "\n", _jsxs(_components.p, {
      children: ["But if a toast is really required, the package ", _jsx(_components.a, {
        href: "https://github.com/emilkowalski/sonner",
        children: "Sonner"
      }), " offers a Toast implementation that is as accessibility friendly as it can be. Emil Kowalski, a design engineer, created the Sonner toast library and wrote a ", _jsx(_components.a, {
        href: "https://emilkowal.ski/ui/building-a-toast-component",
        children: "nice blog post here"
      }), " that describes the animation and API of the implementation, but the real important part of the toast implementation is how it renders the toasts, which roughly looks like:"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-html",
        children: "<section\n  aria-label={ariaLabel}\n  tabIndex={-1}\n  aria-live=\"polite\"\n  aria-atomic=\"false\"\n>\n  <ol tabIndex={-1}>\n    <li tabIndex={0}>\n\t    {content}\n    </li>\n  </ol>\n</section>\n"
      })
    }), "\n", _jsx(_components.p, {
      children: "Each section helps with accessibility as follows:"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsxs(_components.li, {
        children: [_jsx(_components.code, {
          children: "aria-label"
        }), " provides screen readers with an accessible name for the section"]
      }), "\n", _jsxs(_components.li, {
        children: [_jsx(_components.code, {
          children: "tabIndex={-1}"
        }), " takes the section out of the keyboard navigation flow"]
      }), "\n", _jsxs(_components.li, {
        children: [_jsx(_components.code, {
          children: "aria-live=\"polite\""
        }), " means that any changes within this node will wait to alert the user until their current action is complete"]
      }), "\n", _jsxs(_components.li, {
        children: [_jsx(_components.code, {
          children: "aria-atomic=\"false\""
        }), " means that assistive technology will only announce the changed portion of the region, rather than presenting the entire region again."]
      }), "\n"]
    }), "\n", _jsxs(_components.p, {
      children: ["Another implementation that is very accessibility aware is the ", _jsx(_components.a, {
        href: "https://react-aria.adobe.com/Toast/useToast",
        children: "React Aria library"
      }), ", which creates markup similar to:"]
    }), "\n", _jsx(_components.pre, {
      children: _jsx(_components.code, {
        className: "language-html",
        children: "<div\n\trole=\"region\"\n\ttabindex=\"-1\"\n\taria-label=\"1 notification.\"\n>\n\t<div\n\t\trole=\"alertdialog\"\n\t\taria-modal=\"false\"\n\t\taria-labelledby=\"title\"\n\t\ttabindex=\"0\"\n\t>\n\t\t<div\n\t\t\trole=\"alert\"\n\t\t\taria-atomic=\"true\"\n\t\t>\n\t\t\t<div\n\t\t\t\tid=\"title\"\n\t\t\t\tslot=\"title\"\n\t\t\t>\n\t\t\t\tToast is done!\n\t\t\t</div>\n\t\t</div>\n\t</div>\n</div>\n"
      })
    }), "\n", _jsxs(_components.p, {
      children: ["Which as we can see is slightly different than the Sonner implementation. Mainly that no section is used, but the div is marked a ", _jsx(_components.code, {
        children: "region"
      }), ". It also uses the role ", _jsx(_components.code, {
        children: "alertdialog"
      }), " ."]
    }), "\n", _jsx(_components.h2, {
      children: "Did we solve it?"
    }), "\n", _jsx(_components.p, {
      children: "Just looking at two implementations shows the problem with toasts - because they aren’t standardized into HTML, every implementation looks slightly different. In the end, that means that if we care about accessibility, we are mainly working around the constraints of HTML to provide a semantic and understandable toast component. And, even if we do implement a toast that is good enough, we still have to worry about the user experience of interacting with a toast."
    }), "\n", _jsx(_components.p, {
      children: "The two implementations also didn’t answer some of the main UX concerns when using toasts: did the user even see the toast? Did it disappear before they finished reading it? Did the user even understand the message, let alone which action caused it?"
    }), "\n", _jsx(_components.p, {
      children: "There are plenty of sites that use toasts though. My early example was Gmail, and that is used by millions of people around the world. Even Apple uses toasts. What is a notification on the Mac desktop if not a toast? We also have mobile notifications on Android and iOS devices that are basically toasts for different apps to get your attention."
    }), "\n", _jsx(_components.p, {
      children: "Toasts have their place, but they require considerably more thought than their simple UI suggests. The next time you reach for one, ask your team: is there a better way to convey the same information?"
    }), "\n", _jsx(_components.p, {
      children: "EDIT:"
    }), "\n", _jsxs(_components.p, {
      children: ["This continues to be a hot-topic among UX professionals. ", _jsx(_components.a, {
        href: "https://maxschmitt.me/posts/calm",
        children: "Calm UI"
      }), " is a great article that explores the use of toasts and other UI patterns to create a more calm and user-friendly experience."]
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, {
    ...props,
    children: _jsx(_createMdxContent, {
      ...props
    })
  }) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>Accessibility problems usually have recognizable solutions. A button needs an accessible name, text needs sufficient contrast, and a modal needs sensible focus management.</p>
<p>The implementation may be wrong, but the path toward fixing it is usually understood.</p>
<p>Then there are toasts.</p>
<h2>What is a Toast</h2>
<p>A toast is a small, temporary message that appears in response to an event or user action. It might confirm success, report an error, or tell the user that an asynchronous operation has completed.</p>
<p>In Gmail, when you delete an email, the user is given a toast notification that allows the user to undo the action.</p>
<p>In some systems, an action is asynchronous, and a toast is used to notify the user after the action has completed without blocking the user on a screen/form to wait for the result.</p>
<h2>Why toasts are difficult</h2>
<p>Dialogs have <code>&lt;dialog&gt;</code>. Buttons have <code>&lt;button&gt;</code>. Forms have <code>&lt;form&gt;</code>, <code>&lt;input&gt;</code>, and <code>&lt;label&gt;</code>. Toasts have… <code>&lt;div&gt;</code>.</p>
<p>For example, here is an HTML-only modal example:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code> &lt;dialog id=&quot;hello_modal&quot; class=&quot;modal&quot;&gt;
  &lt;div class=&quot;modal-box&quot;&gt;
    &lt;h3 class=&quot;text-lg font-bold&quot;&gt;Hello!&lt;/h3&gt;
  &lt;/div&gt;
&lt;/dialog&gt;
</code></pre></div>
<p>Native elements provide browsers and assistive technologies with semantics they already understand.</p>
<p>The main issue is that there doesn’t exist any basic HTML element that perfectly encompasses a toast. Any implementation of a toast ends up being a custom implementation for whatever system implements it.</p>
<p>Then there is the large amount of usability issues:</p>
<ul>
<li>On large screens, toasts end up going unnoticed.</li>
<li>On any page with visual clutter - for example a page with a map on it that contains map controls for zooming, searching, etc - a toast can often be lost in the visual clutter.</li>
<li>A toast is often distracting. If the toast automatically dismisses itself, then the user only has a short period of time to read or interact with the message. If the toast does not automatically dismiss, it distracts the user from their flow by requiring them to dismiss it.</li>
<li>If a user is using any screen magnification software, the toast can go unnoticed since it might be outside of the magnification window.</li>
<li>A toast appearing is typically disconnected from the action that was taken, meaning the user may not understand the relationship between the toast and action that triggered it.</li>
</ul>
<h2>What do we do about it?</h2>
<p>The next question is of course: so what do we do about it? Can we make toasts accessible for users? Primer - the component library created by GitHub - has decided that <a href="https://primer.style/accessibility/patterns/accessible-notifications-and-messages/">toasts were not worth the effort</a>:</p>
<blockquote class="border-l-4 border-gray-300 pl-4">
<p>Toasts pose significant accessibility concerns and are not recommended for use.</p>
</blockquote>
<p>The accessibility problem with toasts isn&#x27;t merely that screen readers can&#x27;t announce them. It&#x27;s that the entire interaction model assumes the user will notice a temporary piece of UI appearing somewhere else on the screen.</p>
<p>For simple actions, the Primer documentation suggests to simply have a banner on the next page after a form submission with any additional information for successful states. The user successfully created an issue? Redirect to the issue. Need to provide feedback after a complex action? Use a banner at the top of the resulting page with the message.</p>
<p>There are also many discussions on YCombinator, such as <a href="https://news.ycombinator.com/item?id=46135145">this one</a> where users argue about how useful toasts really are.</p>
<blockquote class="border-l-4 border-gray-300 pl-4">
<p>Toasts are a great way to lose information.</p>
</blockquote>
<p>On Couchsurfing, we had a similar experience with toasts. We implemented toasts to alert the user that they needed to turn on Geolocation permissions to use certain features. We rendered the toast correctly, it had sufficient contrast, and assistive technology would announce it properly. None of that mattered though because users simply wouldn’t notice it. Toasts would get lost in the clutter of controls on our pages with maps on them.</p>
<p>But if a toast is really required, the package <a href="https://github.com/emilkowalski/sonner">Sonner</a> offers a Toast implementation that is as accessibility friendly as it can be. Emil Kowalski, a design engineer, created the Sonner toast library and wrote a <a href="https://emilkowal.ski/ui/building-a-toast-component">nice blog post here</a> that describes the animation and API of the implementation, but the real important part of the toast implementation is how it renders the toasts, which roughly looks like:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-html">&lt;section
  aria-label={ariaLabel}
  tabIndex={-1}
  aria-live=&quot;polite&quot;
  aria-atomic=&quot;false&quot;
&gt;
  &lt;ol tabIndex={-1}&gt;
    &lt;li tabIndex={0}&gt;
	    {content}
    &lt;/li&gt;
  &lt;/ol&gt;
&lt;/section&gt;
</code></pre></div>
<p>Each section helps with accessibility as follows:</p>
<ul>
<li><code>aria-label</code> provides screen readers with an accessible name for the section</li>
<li><code>tabIndex={-1}</code> takes the section out of the keyboard navigation flow</li>
<li><code>aria-live=&quot;polite&quot;</code> means that any changes within this node will wait to alert the user until their current action is complete</li>
<li><code>aria-atomic=&quot;false&quot;</code> means that assistive technology will only announce the changed portion of the region, rather than presenting the entire region again.</li>
</ul>
<p>Another implementation that is very accessibility aware is the <a href="https://react-aria.adobe.com/Toast/useToast">React Aria library</a>, which creates markup similar to:</p>
<div class="overflow-auto rounded-2xl bg-[#0e005d6d] p-4 font-mono text-sm dark:bg-[#0e005d6d] dark:text-gray-100"><pre><code class="language-html">&lt;div
	role=&quot;region&quot;
	tabindex=&quot;-1&quot;
	aria-label=&quot;1 notification.&quot;
&gt;
	&lt;div
		role=&quot;alertdialog&quot;
		aria-modal=&quot;false&quot;
		aria-labelledby=&quot;title&quot;
		tabindex=&quot;0&quot;
	&gt;
		&lt;div
			role=&quot;alert&quot;
			aria-atomic=&quot;true&quot;
		&gt;
			&lt;div
				id=&quot;title&quot;
				slot=&quot;title&quot;
			&gt;
				Toast is done!
			&lt;/div&gt;
		&lt;/div&gt;
	&lt;/div&gt;
&lt;/div&gt;
</code></pre></div>
<p>Which as we can see is slightly different than the Sonner implementation. Mainly that no section is used, but the div is marked a <code>region</code>. It also uses the role <code>alertdialog</code> .</p>
<h2>Did we solve it?</h2>
<p>Just looking at two implementations shows the problem with toasts - because they aren’t standardized into HTML, every implementation looks slightly different. In the end, that means that if we care about accessibility, we are mainly working around the constraints of HTML to provide a semantic and understandable toast component. And, even if we do implement a toast that is good enough, we still have to worry about the user experience of interacting with a toast.</p>
<p>The two implementations also didn’t answer some of the main UX concerns when using toasts: did the user even see the toast? Did it disappear before they finished reading it? Did the user even understand the message, let alone which action caused it?</p>
<p>There are plenty of sites that use toasts though. My early example was Gmail, and that is used by millions of people around the world. Even Apple uses toasts. What is a notification on the Mac desktop if not a toast? We also have mobile notifications on Android and iOS devices that are basically toasts for different apps to get your attention.</p>
<p>Toasts have their place, but they require considerably more thought than their simple UI suggests. The next time you reach for one, ask your team: is there a better way to convey the same information?</p>
<p>EDIT:</p>
<p>This continues to be a hot-topic among UX professionals. <a href="https://maxschmitt.me/posts/calm">Calm UI</a> is a great article that explores the use of toasts and other UI patterns to create a more calm and user-friendly experience.</p>

Accessibility problems usually have recognizable solutions. A button needs an accessible name, text needs sufficient contrast, and a modal needs sensible focus management.

The implementation may be wrong, but the path toward fixing it is usually understood.

Then there are toasts.



## What is a Toast

A toast is a small, temporary message that appears in response to an event or user action. It might confirm success, report an error, or tell the user that an asynchronous operation has completed.

In Gmail, when you delete an email, the user is given a toast notification that allows the user to undo the action.

In some systems, an action is asynchronous, and a toast is used to notify the user after the action has completed without blocking the user on a screen/form to wait for the result.

## Why toasts are difficult

Dialogs have `<dialog>`. Buttons have `<button>`. Forms have `<form>`, `<input>`, and `<label>`. Toasts have… `<div>`.

For example, here is an HTML-only modal example:

```
 <dialog id="hello_modal" class="modal">
  <div class="modal-box">
    <h3 class="text-lg font-bold">Hello!</h3>
  </div>
</dialog>
```

Native elements provide browsers and assistive technologies with semantics they already understand.

The main issue is that there doesn’t exist any basic HTML element that perfectly encompasses a toast. Any implementation of a toast ends up being a custom implementation for whatever system implements it.

Then there is the large amount of usability issues:

- On large screens, toasts end up going unnoticed.
- On any page with visual clutter - for example a page with a map on it that contains map controls for zooming, searching, etc - a toast can often be lost in the visual clutter.
- A toast is often distracting. If the toast automatically dismisses itself, then the user only has a short period of time to read or interact with the message. If the toast does not automatically dismiss, it distracts the user from their flow by requiring them to dismiss it.
- If a user is using any screen magnification software, the toast can go unnoticed since it might be outside of the magnification window.
- A toast appearing is typically disconnected from the action that was taken, meaning the user may not understand the relationship between the toast and action that triggered it.

## What do we do about it?

The next question is of course: so what do we do about it? Can we make toasts accessible for users? Primer - the component library created by GitHub - has decided that [toasts were not worth the effort](https://primer.style/accessibility/patterns/accessible-notifications-and-messages/):

> Toasts pose significant accessibility concerns and are not recommended for use.

The accessibility problem with toasts isn't merely that screen readers can't announce them. It's that the entire interaction model assumes the user will notice a temporary piece of UI appearing somewhere else on the screen. 

For simple actions, the Primer documentation suggests to simply have a banner on the next page after a form submission with any additional information for successful states. The user successfully created an issue? Redirect to the issue. Need to provide feedback after a complex action? Use a banner at the top of the resulting page with the message.

There are also many discussions on YCombinator, such as [this one](https://news.ycombinator.com/item?id=46135145) where users argue about how useful toasts really are.

> Toasts are a great way to lose information.


On Couchsurfing, we had a similar experience with toasts. We implemented toasts to alert the user that they needed to turn on Geolocation permissions to use certain features. We rendered the toast correctly, it had sufficient contrast, and assistive technology would announce it properly. None of that mattered though because users simply wouldn’t notice it. Toasts would get lost in the clutter of controls on our pages with maps on them.

But if a toast is really required, the package [Sonner](https://github.com/emilkowalski/sonner) offers a Toast implementation that is as accessibility friendly as it can be. Emil Kowalski, a design engineer, created the Sonner toast library and wrote a [nice blog post here](https://emilkowal.ski/ui/building-a-toast-component) that describes the animation and API of the implementation, but the real important part of the toast implementation is how it renders the toasts, which roughly looks like:

```html
<section
  aria-label={ariaLabel}
  tabIndex={-1}
  aria-live="polite"
  aria-atomic="false"
>
  <ol tabIndex={-1}>
    <li tabIndex={0}>
	    {content}
    </li>
  </ol>
</section>
```

Each section helps with accessibility as follows:

- `aria-label` provides screen readers with an accessible name for the section
- `tabIndex={-1}` takes the section out of the keyboard navigation flow
- `aria-live="polite"` means that any changes within this node will wait to alert the user until their current action is complete
- `aria-atomic="false"` means that assistive technology will only announce the changed portion of the region, rather than presenting the entire region again.

Another implementation that is very accessibility aware is the [React Aria library](https://react-aria.adobe.com/Toast/useToast), which creates markup similar to:

```html
<div
	role="region"
	tabindex="-1"
	aria-label="1 notification."
>
	<div
		role="alertdialog"
		aria-modal="false"
		aria-labelledby="title"
		tabindex="0"
	>
		<div
			role="alert"
			aria-atomic="true"
		>
			<div
				id="title"
				slot="title"
			>
				Toast is done!
			</div>
		</div>
	</div>
</div>
```

Which as we can see is slightly different than the Sonner implementation. Mainly that no section is used, but the div is marked a `region`. It also uses the role `alertdialog` .

## Did we solve it?

Just looking at two implementations shows the problem with toasts - because they aren’t standardized into HTML, every implementation looks slightly different. In the end, that means that if we care about accessibility, we are mainly working around the constraints of HTML to provide a semantic and understandable toast component. And, even if we do implement a toast that is good enough, we still have to worry about the user experience of interacting with a toast.

The two implementations also didn’t answer some of the main UX concerns when using toasts: did the user even see the toast? Did it disappear before they finished reading it? Did the user even understand the message, let alone which action caused it?

There are plenty of sites that use toasts though. My early example was Gmail, and that is used by millions of people around the world. Even Apple uses toasts. What is a notification on the Mac desktop if not a toast? We also have mobile notifications on Android and iOS devices that are basically toasts for different apps to get your attention.

Toasts have their place, but they require considerably more thought than their simple UI suggests. The next time you reach for one, ask your team: is there a better way to convey the same information?

EDIT:

This continues to be a hot-topic among UX professionals. [Calm UI](https://maxschmitt.me/posts/calm) is a great article that explores the use of toasts and other UI patterns to create a more calm and user-friendly experience.

Toasts Are Harder Than They Look

"use strict";
const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];
function _createMdxContent(props) {
  const _components = {
    a: "a",
    code: "code",
    em: "em",
    h2: "h2",
    li: "li",
    p: "p",
    ul: "ul",
    ...props.components
  };
  return _jsxs(_Fragment, {
    children: [_jsx(_components.p, {
      children: "This post was originally on a blog I started for creating web applications. This post goes into accessibility of web applications."
    }), "\n", _jsx(_components.h2, {
      children: "Is your site accessible via screen readers?"
    }), "\n", _jsx(_components.p, {
      children: "Check to make sure your website is navigable from screen readers."
    }), "\n", _jsxs(_components.p, {
      children: ["If you are using ", _jsx(_components.a, {
        href: "http://getbootstrap.com/",
        children: "Twitter Bootstrap"
      }), ", look into the ", _jsx(_components.a, {
        href: "http://paypal.github.io/bootstrap-accessibility-plugin/",
        children: "Bootstrap accessibility plugin"
      }), "."]
    }), "\n", _jsxs(_components.p, {
      children: ["If you are using ", _jsx(_components.a, {
        href: "http://foundation.zurb.com/",
        children: "Foundation"
      }), ", look into how ", _jsx(_components.a, {
        href: "http://zurb.com/article/1337/foundation-now-helps-you-build-accessible",
        children: "Foundation is built around accessibility"
      }), "."]
    }), "\n", _jsx(_components.h2, {
      children: "Do your Positive, Negative, and Neutral Buttons look different?"
    }), "\n", _jsxs(_components.p, {
      children: ["Image from ", _jsx(_components.a, {
        href: "http://uxmovement.com/buttons/how-button-color-contrast-guides-users-to-action/",
        children: "UX Movement"
      }), "."]
    }), "\n", _jsx(_components.p, {
      children: "Have your Positive Action buttons and your Neutral and Negative Action buttons look distinctly different.  Notice that in the above example, not only are the colors different, but one is bordered and ther other is filled in, making it accessible to those with color-blindness."
    }), "\n", _jsx(_components.h2, {
      children: "HTML Tags"
    }), "\n", _jsxs(_components.ul, {
      children: ["\n", _jsxs(_components.li, {
        children: [_jsx(_components.code, {
          children: "<i>"
        }), " - ", _jsx(_components.em, {
          children: "\"alternate voice\""
        }), "; transliterated foreign words, technical terms, and typographically italicized text."]
      }), "\n", _jsxs(_components.li, {
        children: [_jsx(_components.code, {
          children: "<em>"
        }), " - ", _jsx(_components.em, {
          children: "\"stress emphasis\""
        }), "; something you'd pronounce differently."]
      }), "\n", _jsxs(_components.li, {
        children: [_jsx(_components.code, {
          children: "<b>"
        }), " - ", _jsx(_components.em, {
          children: "\"stylistically offset\""
        }), "; keywords and typographically emboldened text."]
      }), "\n", _jsxs(_components.li, {
        children: [_jsx(_components.code, {
          children: "<strong>"
        }), " - ", _jsx(_components.em, {
          children: "\"strong importance\""
        }), ";"]
      }), "\n"]
    }), "\n", _jsxs(_components.p, {
      children: ["See ", _jsx(_components.a, {
        href: "http://html5doctor.com/i-b-em-strong-element/",
        children: "this HTML5 Doctor post"
      }), " for more information."]
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = props.components || ({});
  return MDXLayout ? _jsx(MDXLayout, {
    ...props,
    children: _jsx(_createMdxContent, {
      ...props
    })
  }) : _createMdxContent(props);
}
return {
  default: MDXContent
};


<p>This post was originally on a blog I started for creating web applications. This post goes into accessibility of web applications.</p>
<h2>Is your site accessible via screen readers?</h2>
<p>Check to make sure your website is navigable from screen readers.</p>
<p>If you are using <a href="http://getbootstrap.com/">Twitter Bootstrap</a>, look into the <a href="http://paypal.github.io/bootstrap-accessibility-plugin/">Bootstrap accessibility plugin</a>.</p>
<p>If you are using <a href="http://foundation.zurb.com/">Foundation</a>, look into how <a href="http://zurb.com/article/1337/foundation-now-helps-you-build-accessible">Foundation is built around accessibility</a>.</p>
<h2>Do your Positive, Negative, and Neutral Buttons look different?</h2>
<p>Image from <a href="http://uxmovement.com/buttons/how-button-color-contrast-guides-users-to-action/">UX Movement</a>.</p>
<p>Have your Positive Action buttons and your Neutral and Negative Action buttons look distinctly different.  Notice that in the above example, not only are the colors different, but one is bordered and ther other is filled in, making it accessible to those with color-blindness.</p>
<h2>HTML Tags</h2>
<ul>
<li><code>&lt;i&gt;</code> - <em>&quot;alternate voice&quot;</em>; transliterated foreign words, technical terms, and typographically italicized text.</li>
<li><code>&lt;em&gt;</code> - <em>&quot;stress emphasis&quot;</em>; something you&#x27;d pronounce differently.</li>
<li><code>&lt;b&gt;</code> - <em>&quot;stylistically offset&quot;</em>; keywords and typographically emboldened text.</li>
<li><code>&lt;strong&gt;</code> - <em>&quot;strong importance&quot;</em>;</li>
</ul>
<p>See <a href="http://html5doctor.com/i-b-em-strong-element/">this HTML5 Doctor post</a> for more information.</p>


This post was originally on a blog I started for creating web applications. This post goes into accessibility of web applications.

## Is your site accessible via screen readers?

Check to make sure your website is navigable from screen readers.

If you are using [Twitter Bootstrap](http://getbootstrap.com/), look into the [Bootstrap accessibility plugin](http://paypal.github.io/bootstrap-accessibility-plugin/).

If you are using [Foundation](http://foundation.zurb.com/), look into how [Foundation is built around accessibility](http://zurb.com/article/1337/foundation-now-helps-you-build-accessible).

## Do your Positive, Negative, and Neutral Buttons look different?

Image from [UX Movement](http://uxmovement.com/buttons/how-button-color-contrast-guides-users-to-action/).

Have your Positive Action buttons and your Neutral and Negative Action buttons look distinctly different.  Notice that in the above example, not only are the colors different, but one is bordered and ther other is filled in, making it accessible to those with color-blindness.

## HTML Tags

* `<i>` - *"alternate voice"*; transliterated foreign words, technical terms, and typographically italicized text.
* `<em>` - *"stress emphasis"*; something you'd pronounce differently.
* `<b>` - *"stylistically offset"*; keywords and typographically emboldened text.
* `<strong>` - *"strong importance"*;

See [this HTML5 Doctor post](http://html5doctor.com/i-b-em-strong-element/) for more information.
