The CodeMash fun continues...

After the workshops from yesterday, I was looking forward to another hands-on session. I enjoyed having personal attention from people in specific fields as well as the side conversations from the other attendees as we worked through exercises. Today, I went to a workshop on accessibility. I also attended the lightning talks session.

What does accessibility entail and why is it important?

In his talk, titled "Accessibility: A Walk in Someone Else's Shoes", Nathan Loding walked us through these questions and demonstrated how to make the web accessible.

He started with an overview of the different impairments (i.e. various forms of color blindness, low vision, cognitive, epilepsy, auditory, ADHD, physical, etc.). He briefly discussed the purpose of the Web Content Accessibility Guidelines (WCAG) and its requirements. We completed several exercises which included navigating a website from different disability perspectives, using screen readers, blindfolds, and accessibility tools provided by Chrome. After each exercise, we used the WCAG 2.0 to make the website more accessible.

Just in the US, 1 in 5 people live with a disability -- that fact alone makes accessibility important. Fortunately, the WCAG has had our backs for a decade now. The guidelines were established in 2008 by individuals and organizations that wanted a content accessibility standard. On the WCAG site, you'll find techniques and sample scenarios to make your web/mobile sites accessible. Before going through the exercises, we discussed the main criteria points to meet the guideline requirements known as POUR, which stands for percievable, operable, understandable, and robust:

• Percievable: Information and user interface components must be presentable to users in ways they can perceive. (Screen readers should be able to read all of the text).
• Operable: User interface components and navigation must be operable. (Make all functionality available from a keyboard).
• Undertandable: Information and the operation of user interface must be understandable. (Set a language on page. Make content readable and understandable).
• Robust: Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. (Coding for W3 standards for HTML? Standard Semantic HTML? Following all other criteria?)
  
  For each criteria point, Nathan provided HTML examples that had violated the guidelines and how to either add ARIA tags or semantic structure to meet requirements. These adjustments were simple and seemed valuable for both the user and developer.
  
  For the first exercise, Nathan gave us blindfolds and we had to navigate a website with help from a screen reader. A screen reader is technology that verbally translates visual information. I had previously heard about screen readers, but I had yet to have any experience with them. For the blindfold exercise, we used ChromeVox, a Chrome extension, as our screen reader. I started tabbing through the site. Along with text, I heard different sounds for button presses and browser tab changes, but navigating the website was still a huge pain. After tabbing down the page, sometimes the only thing I would hear was, "Button, button, button, button". It was terrible. I could barely make sense of the information on the page. I couldn't identify forms or links. At one point, I realized I was tabbing through the same three buttons in one section of the page. Then we made some adjustments to the HTML. Adding a few ARIA labels and alt tags made a huge difference. For our next exercises, we used ChromeLens, another Chrome extension, to add various color blindness filters. This made us consider the font sizes and color choices. For example, a red button alone would not be able to universally provide the same message.
  
  These types of exercises could never replace user research from those who actually have disabilities. However, the workshop made me think about web apps that I've created and who would be unable to interact with them. Accessibility guidelines make you consider audiences and their particular needs, regardless of your product delivery intentions. The real take away for me was that when you develop anything for marginalized populations, that product can be used by everyone. This approach is not exclusive to the tech field.
  
  Other tools that I learned about:
• AXE by DEQUE
• Photosensitive Epilepsy Analysis Tool (PEAT)
• WAVE
• Khan Academy's Tota11y Visualization Toolkit
• Tenon
• Pa11y

• ReactJS plugin
  
  

  Lightning Talks

There were over 20 speakers for the lightning talks session. I really appreciated how Brian Prince encouraged anyone and everyone to speak, especially first timers. Each speaker had 6 minutes to talk about anything, tech related or not. There was a wide range of topics: how to make sourdough bread; the upcoming eSports trends; knowing that you're awesome; how to give back to the developer community. Here is the full list. My favorite talks were:

• Sarah Withee - I Built My Own Artificial Pancreas
• Peter Zukerman - Foreign Languages for Humans and Computers
• Jon Skeet - Listen and amplify

Overall

I'm so happy that I was able to attend the talk on accessibility and discover new tools. It was definitely my favorite talk. The lightning speakers also inspired to me think about giving a lightning talk. I don't know what the topic would be, but 6 minutes would be a breeze.