Pen Settings



CSS Base

Vendor Prefixing

Add External Stylesheets/Pens

Any URL's added here will be added as <link>s in order, and before the CSS in the editor. You can use the CSS from another Pen by using it's URL and the proper URL extention.

+ add another resource


Babel includes JSX processing.

Add External Scripts/Pens

Any URL's added here will be added as <script>s in order, and run before the JavaScript in the editor. You can use the URL of any other Pen and it will include the JavaScript from that Pen.

+ add another resource


Add Packages

Search for and use JavaScript packages from npm here. By selecting a package, an import statement will be added to the top of the JavaScript editor for this package.


Save Automatically?

If active, Pens will autosave every 30 seconds after being saved once.

Auto-Updating Preview

If enabled, the preview panel updates automatically as you code. If disabled, use the "Run" button to update.

Format on Save

If enabled, your code will be formatted when you actively save your Pen. Note: your code becomes un-folded during formatting.

Editor Settings

Code Indentation

Want to change your Syntax Highlighting theme, Fonts and more?

Visit your global Editor Settings.


  <h1>Accessible Web</h1>
<aside aria-hidden="true">👉 Please disable CSS to view this webpage.</aside>
<main class="visuallyhidden">
  <p aria-hidden="true">Whew! That's better. So guess what?</p>
  <h2 id="content">The web is inherently accessible</h2>
    "Your weekly reminder that the web is accessible by default and it's our design decisions that stop it being accessible"
    <cite>&mdash; <a href="">Kevin Mar-Molinero on Twitter</a>, 7 December 2020</cite>
  <p>Why did you have to disable CSS to view this website? No reason other than a <em>design choice</em> that excludes sighted people.</p>
  <p><strong>Did you know?</strong> This is how many visitors "view" webpages already:</p>
    <li>Search engines</li>
    <li>Site crawlers</li>
    <li>Blind people</li>
  <p>This page is fully accessible to people with <a href="">screen readers</a> and Braille displays. But many websites have low accessibility due to poor design choices that exclude some people.</p>
  <h2>What is web accessibility?</h2>
  <p>When a page is <strong>accessible</strong>, it was developed with the intention of working for as many people with disabilities as possible. A good place to start learning is the W3C's <a href="">Introduction to Web Accessibility</a>. Find out the different ways people with disabilities interact with the web.</p>
  <h3>Web Content Accessibility Guidelines (WCAG)</h3>
  <p>WCAG is a set of success criteria for determining if a page is accessible, led by four guiding principles:</p>
    <dd>Information and user interface components must be presentable to users in ways they can perceive.</dd>
    <dd>User interface components and navigation must be operable.</dd>
    <dd>Information and the operation of the user interface must be understandable.</dd>
    <dd>Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.</dd>
  <p>These contain guidelines and a hierarchy of success criteria from Level A to Level AAA. Many accessibility laws, and current best practice, point to WCAG 2.1 Level AA compliance. There are 50 discrete success criteria to evaluate, though many are not applicable to all pages. For example, if a page doesn't contain video, you don't have to evaluate against success criteria for captions or audio descriptions.</p>
  <p><a href="">See the full list of success criteria</a></p>
  <p><strong>Did you know?</strong> The WCAG guidelines were first published in 1999. Web accessibility is not a new concept but a lot of people are learning about it only now.</p>
  <p>So what's the point? The point is to develop accessible pages from the bottom up, starting with <strong>semantic HTML</strong>. A whole lot of developers think they know HTML but are actually pretty sloppy about it. Many don't think it matters if they use a link or a button, but it does. Every semantic mistake introduces accessibility issues into your code. If you've never really "learned" HTML, check out this <a href="">beginner's guide to writing good HTML</a>.</p>
  <p>By far, CSS color contrast issues are the most frequent accessibility issues I see, but the HTML ones are problematic too. Outlined below are the top HTML-related accessibility issues I encounter.</p>

  <p>If you visually scan this page, you can quickly see how it is broken up into sections. That's due to using headings or the <code>h1-h6</code> elements. It's important that every page have at least one <code>h1</code> element that identifies the topic of the page to people and search engines. From there, cascade down to <code>h2</code>, <code>h3</code>, and so on.</p>
  <p><strong>Did you know?</strong> People using screen readers can navigate by headings in much the same way that sighted people can visually scan the page for items of importance.</p>

  <h3>Form labels</h3>
  <p>Every input needs a label. It's really that simple. And best practice is to make that label visible. This helps people remember what information they've entered. Programatically link each pair using the <code>for</code> attribute on the label matching the <code>id</code> attribute on the input.</p>
  <p>This enables a couple things:</p>
    <li>People can now click or tap on the label to give focus to the input. This is especially useful for checkboxes and radio buttons that often have small target areas.</li>
    <li>People using screen readers will now hear the label announced when the input is in focus.</li>
      <legend>Cat's colors - select at least one option</legend>
      <p><label for="black"> <input type="checkbox" id="black">Black</label></p>
      <p><label for="white"> <input type="checkbox" id="white">White</label></p>
      <p><label for="brown"> <input type="checkbox" id="brown">Brown</label></p>
      <p><label for="orange"> <input type="checkbox" id="orange">Orange</label></p>
      <p><label for="gray"> <input type="checkbox" id="gray">Gray</label></p>

      <legend>Is your cat altered?</legend>
      <label for="yes"> <input name="altered" type="radio" id="yes" checked>Yes</label>
      <label for="no"> <input name="altered" type="radio" id="no">No</label>

    <p>Many modern browsers do cursory form field validation with the <code>required</code> attribute though error messages are not always accessible.</p>

    <p><label for="markings">Cat's markings<span aria-hidden="true"> *</span></label>
      <select name="markings" id="markings" required>
        <option value=""> select an option </option>
        <option value="solid">Solid</option>
        <option value="bi">Bi-color</option>
        <option value="calico">Calico</option>
        <option value="tabby">Tabby</option>
        <option value="torbie">Torbie</option>
        <option value="tortoiseshell">Tortoiseshell</option>
        <option value="tuxedo">Tuxedo</option>

    <p>The <code>aria-required="true"</code> attribute has better support for assistive technology. Use it along with the <code>aria-invalid="true"</code> attribute to indicate when a field has invalid input. Programmatically associate error messages with the <code>aria-describedby</code> attribute.</p>

    <p><label for="email">Email<span aria-hidden="true"> *</span></label>
      <input type="email" id="email" aria-required="true" aria-invalid="true" autocomplete="email" aria-describedby="email-error">
    <p id="email-error"><span aria-hidden="true">⨂</span> Email format <em></em></p>
    <button type="submit">Send</button>

  <h3>Buttons and links</h3>
  <p>Buttons and links seem very similar to some developers but they have very different semantic uses. <strong>Buttons</strong> are used for controls on a page, such as a form submit or toggle, while <strong>links</strong> are used for navigation, literally for <a href="">linking to another page</a>. If you use them interchangeably, people can get confused about what a button or link is going to do when activated.</p>
  <p>Some people try to make their own custom buttons instead of using the <button aria-label=" ">Button</button> element, which is already accessible:</p>
    <li>Keyboard focusable</li>
    <li>Activated with <kbd>enter</kbd> and <kbd>space</kbd> keys</li>

  <p>There are many legitimate uses for tables on the web but they are often coded incorrectly. Much as an input needs its label, a table data cell needs its <strong>table header</strong>. This allows the applicable table header to be read by a screen reader before the table data cell contents. Additionally, tables need captions to provide a description of the table to people using screen readers.</p>
    <caption>About My Cats</caption>
      <td>orange, black, brown</td>
      <td>black and white</td>
      <td>brown, black</td>
      <td>black and white</td>

  <p>The one thing about accessibility most people know is that images need alt text. This may seem straightforward but let's look at three examples.</p>
      <h4>Alt text matters</h4>
      <p>Semantically speaking, every image needs an <code>alt=""</code> attribute. This alone will pass an automated accessibility checker. If an image is purely decorative, you can even leave the alt value empty.</p>
      <p>But if an image provides context to the content, the alt text must acurately describe the content of the image for people who cannot see it. The alt text for the image below is <em>two cats on an easy chair under a blanket</em>.</p>
      <p><img src="" width="400" alt="two cats on an easy chair under a blanket"></p>

      <p>SVG doesn't support the <code>alt</code> attribute. Instead, add a <code>title</code> element with a unique ID inside the <code>svg</code> element. Add the <code>aria-labelledby="uniqueID"</code> attribute to the <code>svg</code> element to label it. Include the <code>role="img"</code> attribute for assistive technology.</p>
      <svg role="img" xmlns="" version="1.1" width="500" height="160" xmlns:xlink="" aria-labelledby="svg-title">
        <title id="svg-title">Purple Hexagon</title>
        <polygon class="shape" points="150,75 112.5,140 37.5,140 0,75 37.5,10 112.5,10" fill="#93029c"></polygon>

      <h4>Charts and maps</h4>
      <p>Any time you display complicated information, provide a robust description of the key points of the map or chart. All people will benefit from this for reference.</p>
      <p>No matter how you mark this up&#8212;using figcaption or just a p element&#8212;give that description a unique ID. On the map image, add the attribute <code>aria-describedby="uniqueID"</code>. This programatically connects the image with the description for assistive technologies.</p>
        <img src="" alt="a cat lieing on a bed that is divided up into areas" aria-describedby="cat-map">
        <figcaption id="cat-map">Cat bed, never used. Pillows show wake for food here and purring zone. Other areas on the bed are listed as grooming salon, sleeping area, launch pad to the bedside table, parlor, heaving spot, napping quarters, meditation area, stretching area, yoga studio, and foot attack zone. A black cat sits happily in the middle of the bed.</figcaption>
<footer class="visuallyhidden">
  <p>You can catch me on <a href="">Twitter @racheleditullio</a></p>


                body {
  background-color: #333;
aside {
  margin: 1em auto;
  max-width: 1000px;
h1 {
  border-bottom: 25px solid #93029c;
  padding: 0 1em;
  font-size: 5em;
  text-align: center;
  outline: 2px solid #93029c;
  color: #93029c;
  background-color: #fff;
aside {
  font-size: 3em;
  color: #fff;
main {
  padding: 1em;
  max-width: 1000px;
.visuallyhidden {
  border: 0 !important;
  clip: rect(0 0 0 0) !important;
  height: 1px !important;
  margin: -1px !important;
  overflow: hidden !important;
  padding: 0 !important;
  position: absolute !important;
  width: 1px !important;