Usability Journal Entry 6

This week in my journey through usability studies I was assigned the task of adding accessibility features to this site. My first step was using the WAVE browser extension to run a report and determine if there were any errors in my code. Click here to see an accessibility report of my first post.

Much to my surprise after running the WAVE test there was only one “error.” This however, is misleading, because after further research into coding for accessibility I found a few more errors that my plugin was unable to detect - leading me to the conclusion that a chrome plugin would not help me solve all of my accessibility errors.

Implementing the accessibility improvements

Empty link error

After running the WAVE test I was alerted that I had an “empty link.” An empty link is simply a link without text – so essentially a link without a description for what it’s linking to.

In the footer section of my page I have a link to my Github page. Like most web pages I’m only using the icon without text as my link, which most web users will understand is a link to a social media page, as the footer is a typical place to put social logos as links. However, images as links can be confusing for people who use screen readers because links without text are not given a description when focused on and the screen reader simply says “link” without any additional information. To fix this issue I went to starbucks.com to take a deeper look at a possible solution, since they have outstanding accessibility features and have been an excellent resource for me this quarter. For their social icon links in the footer they use an aria-label, which worked great on their site when I used a screen reader to test it. I used the exact same method to fix the error on my site and when I used a screen reader to test it, the voice said “github” instead of simply saying “link.”

I also realized while looking at this section of my code that I had an unnecessary unordered list. I had one item (the github icon) in the list, which I thought might be confusing to someone browsing with a screen reader. For instance, the screen reader would announce they are entering the list and expecting a list the user would only find one item. To fix this I deleted the list so it would be clearer that there is only one link present.

See below for my code example.

HTML

//Original Github icon link code

<ul class="list-inline text-center">
  <li class="list-inline-item">
    <a href="https://github.com/apdonaghy">
      <span class="fa-stack fa-lg">
        <i class="fab fa-github fa-stack-1x fa-inverse"></i>
      </span>
    </a>
  </li>
</ul>

 //Edited Github icon link code

<a aria-label="Git-hub" href="https://github.com/apdonaghy">
  <span class="fa-stack fa-lg centered">
    <i class="fas fa-circle fa-stack-2x"></i>
    <i class="fab fa-github fa-stack-1x fa-inverse"></i>
  </span>
</a>

Adding skip to main content link

While researching accessibility I was interested to see what reputable companies were doing on their sites. To test, I tabbed through the focusable elements and turned on my “voice over” feature (on my Mac) and browsed a few pages from starbucks.com and alaskaair.com. Both of these sites have a feature that allows the user to skip the navigation in order to get to the main content of the page more quickly. This addition can make browsing more efficient for someone using a screen reader, as the navigational elements can get repetitive if they no longer need to hear them.

In order to add this feature to my site I found this excellent resource at css-tricks.com, which essentially uses the css transform property to bring the skip link into view only when focused on – so mouse users would never see this hidden link unless using a keyboard to navigate. My code is below for how I added this feature to my site.

HTML

  
    <a class="skip-to-content-link" href="#main">
      Skip to main content
    </a>
    

CSS

      
  .skip-to-content-link {
    background: #00657b;
    color:white;        
    height: 4  0px;
    left: 50%;
    padding: 8px;
    position: absolute;
    //renders skip to main content link out of foucs
    transform: translateY(-150%);
    //animates transition of link
    transition: transform 0.3s;
  }
  .skip-to-content-link:focus {
    //animates skip to main content link in focus
    transform: translateY(0%);
  }
      

Writing semantic code

From what I’ve read, including this article from MDN the best place to start with accessibility is by writing logical, semantic code. For instance while writing code if the developer fails to indicate the <nav> or the <footer>, it will be difficult for someone using a screen reader to know where they are in the context of the page, since a screen reader will announce which section of the page the user is in while they’re navigating.

I noticed in my code that I failed to use the <main> tag, which alerts screen reader users that they’ve entered the main content of the page and are outside of the header and footer. Although not ideal, a person using a screen reader may still be able to navigate a page without any semantic markup, but in my experience with screen readers, additional contextual descriptions make navigating more efficient.

Below is a code block that shows the transformation I made to my code to make it semantically accurate.

HTML

//original code 
   
  <article>
    <div class="container">
      <div class="row">
        <div class="col-lg-8 col-md-10 mx-auto">
        ...
        </div>
      </div>
    </div>
  </article>

//semantic code
  
  <main id="main" class="container">
    <article class="row">
      <div class="col-lg-8 col-md-10 mx-auto">
      ...
      </div>
    </article>
  </main>

Thoughts on bootstrap and accessibility

There are really no drawbacks to using bootstrap together with accessibility features. In their documentation they use mostly divs to explain the functions of their framework code, but it’s easy to replace them with semantic tags when implementing on your own.

The most obvious issue with bootstrap and accessibility are the default colors and text sizes, which can be overridden, by both the user (in the computer’s accessibility settings) or by the developer (by adjusting the css). There will always be tension between what designers think looks good and what accessibility experts think is acceptable – ideally the designers pay attention to the science behind what works for most people, which would make the web more functional for every user.