Enabling People to Work on Computers

Computers. Wow, have they changed my life! Thanks to computers, I’m making my niche in a career that lets me develop a skill with minimal barriers. And I’m not the only one. Others are able to overcome their own individual barriers thanks to various types of technological devices.

But what are some barriers that many people face when using computers to connect or work? And how can we remove those barriers? Read on as I share what I learned in Week 2 of the Digital Accessibility MOOC offered by the University of Southampton.

Access via Input and Output

When designing applications we must not presume that input will only be via keyboard and mouse or that output will just be to a screen. We must allow for the fact that users may require alternative input and output mechanisms.

There are many of us who are accustomed to using the keyboard and/or mouse during our interaction with a desktop or laptop. But not everyone interacts with computers that way. Likewise, not all people use screens and speakers for output, though many people do.

Here are examples of alternative means of computer input and output:

• Input: speech recognition, eye-gaze technology, switch access via hand, foot, mouth, eyelid, or skin)
• Output: speech output, braille output

Layers of Access

My focus on accessibility has been purely web development. However, this course reminded me that there are a lot of things going on when a user accesses a website. Not only are they encountering an online document (content), but rather they are using a browser to get to the desired content (application), and a using a system on the computer that supports that browser (operating system).

So many things to think about:

• Device
• OS
• Applications
• Content

And my list doesn’t even include the Internet connection nor the environment that the person is surrounded by while accessing the Internet!

Document and Content Access

Document accessibility, most recently, has become a big deal to me. What good is dropping a bunch of useful content on the web if it’s not usable?

Mostly, I’m talking about Word documents, PDFs, and Excel spreadsheets. Though Web pages (sometimes considered documents, too) can be developed with many of the same principles, I will not be touching on that until a later post.

Key principles to consider when striving to develop accessible documents and content:

• create structure and hierarchy that make sense (title, headings, list); keep presentation separate from style
• give alternatives when providing images, audio, and video
• identify language, descriptive metadata, and link anchors with meaningful text

These are only a few ideas to ponder. Learn more about the principles of document accessibility in more detail.

Automated Accessibility Checking Tools

Word Processing, Spreadsheets, and Slides

• built in Accessibility Checker tool (Microsoft Office)

PDFs

• Adobe Accessibility Checker (for Acrobat Pro)
• PDF Accessibility Checker PAC (freeware)

More on Alternative Text

Images must have text alternatives that describe the information, reflect the role, specify the function, indicate the target of the link or, in the case of charts, convey the data represented by the images. Description shouldn’t be redundant of text.

There are three types of images:

• decorative: for layout or visual aesthetics; leave alt text empty
• functional: represent the function of the link (i.e. alt=”Print” or alt=”Company Home Page”)
• informative: graphically represents concepts and information, such as:
  • Pictures, photos and illustrations
  • Images of text
  • Complex images such as graphs and diagrams
  • Image maps

Final Thoughts

This was a short week in the MOOC, but I found several tips to be helpful. The principles that make a document accessible and clarification of proper use of alternative text were the most helpful tips for me.

Keep Reading

If you haven’t already seen these, check out W3C’s and Adobe’s resources on making content more accessible:

• Web Content Accessibility Guidelines
• Adobe Portable Document Format Accessibility Overview

Enabling People through Digital Accessibility

I’m halfway through my 100 Days of Accessibility journey! In concert with this achievement, I’ve recently completed the University of Southampton’s free online course about Digital Accessibility and am ready to review what I’ve learned over the 5-week online course. Below are my highlights of emphasized points, ideas new to me, and a-ha moments as a web designer/developer.

Why should we care?

It is important to think about digital accessibility as having the potential to be helpful to us all at any time in our lives.

In my own personal journey in this thing called life, I haven’t had to be convinced to accept and be accommodating for people who are different from me. As one who has her own disability (and quirks), I’ve always felt that everyone is the same in one way or another. But in case you need convincing, here are three solid reasons why it’s important to offer equal access to all:

• Social: it’s good business and reaches a wider market
• Moral: it’s the right thing to do
• Legal: it’s the law

Personally, I’m on the moral bandwagon, and really hate pointing out other motivators like “it’s good business” and “it’s the law”. However, coming from someone who needs some accommodation now and then, I guess I’d feel that way. I understand that if you don’t or haven’t had some variation of a physical or mental barrier, it could be hard for you to understand.

First steps

When I first started 100 Days of Accessibility, I wasn’t quite sure where to start. I made a tentative plan on what I hoped to gain during those 100 days. After 50 days, it didn’t seem quite so intimidating.  Yet at the beginning,  I just wasn’t really sure where to start!

The MOOC I took offered these suggestions on getting started:

• Find someone to champion the effort (a designated worker, buy-in stakeholders, or contracted executive sponsor).
• Accept it as business-as-usual (add it as a part of workflow).

As David Caldwell, an accessibility champion, phrased it, “You could boil the ocean when you think about accessibility!” He’s right. I think you could really get discouraged by how big a task it can be.

As for me, I started my own challenge to educate myself and learn how to apply it to my web work.

Accessibility vs. Usability vs. User Experience

“A strict focus on accessibility as a scorecard item doesn’t help users with disabilities. To help these users accomplish critical tasks, you must adopt a usability perspective.” –Nielsen Norman Group

I don’t know about you, but before this class I had my own assumptions about what accessibility, usability, and user experience are. I’m a web designer. Of course, I have opinions!

This MOOC defined these things as separate, yet related:

• Accessible: a user’s ability to use technology; can be enforced by legislation
• Usability: a product is created for a target group (e.g. can be used by the mouse, but not by the keyboard)
• User experience: the overall experience that a user has when using/accessing a product

Developing with all of these things in mind benefits all users, and would ensure good inclusive design.

Barriers to Users

Whether it be physical, mental, temporary, or permanent, disabilities present barriers for people to live their lives.

Visual Stress and Dyslexia

Low-contrast text may be trendy, but it is also illegible, undiscoverable, and inaccessible. Instead, consider more usable alternatives. –Nielsen Norman Group

This is where I fall. Not only does my limited vision cause barriers, but my own experience with visual stress concerning light and colors creates additional barriers for me. But designing for me isn’t enough! There are so many others encountering visual barriers that are unlike my own.

Some visual barriers may include:

• low vision
• blindness
• dyslexia
• irlen syndrome
• color blindness

[ Summary of Visual Stress Strategies ]

These are my takeaways to consider when designing for the spectrum of visual stress and dyslexia:

• Black on white can be good for those with a visual impairment, yet it may be difficult to read for those who experience visual distress.
• Make options available for users to customize their font and color. ATbar and other plug-ins are one solution.
• Be mindful of text positioning:
  • avoid clutter; use whitespace to help bring focus to important content and sections
  • align text on the left; justified text can give uneven spacing between words
  • recommended width of a reading column: 60-70 characters
  • increase letter spacing; Arial or Verdana automatically offer helpful spacing between letters

I could write a whole series on all the types of visual impairments and how to design for them. Instead, I recommend you dig deeper on this subject yourself.

Hearing Impairment and Tools to Overcome A/V Barriers

Hearing impairments are not new to many of us. I know several people who are hard of hearing. However, it is harder for me to truly relate to this barrier since I rely more heavily on my hearing than many. And my design barrier for the hearing impaired often comes down to time and money. Unlike some easy code that I can add into my workflow for those with visual impairments, I often don’t take the time to fret over captions, transcripts, or other alternatives, like sign language. I wasn’t even sure about the differences of all these alternatives!

In case you’re in the same boat I was, here are helpful alternatives to offer when using video and audio online:

• TV captioning: overcomes auditory barriers; 2 lines of text displayed over the video; words and sounds are included in text
• Web captioning: overcomes auditory barriers; several lines of text are displayed beside the video; highlighting is possible as the person speaks those words
• Foreign language subtitles: overcomes language barriers; translated text of a specified language is displayed over the video; a word for word translation
• Sign language: overcomes auditory barriers; a second video with a sign language interpret or is displayed next to the main video
• Transcripts: text offered as a separate file or web page in lieu of watching a video
• Audio description: overcomes visual barriers; actions are described in real time with the video

One neat thing about using captioning and transcripts: it benefits so many more people than just those who are hard of hearing or deaf. It can benefit those watching a video in a loud (or quiet) room. And it makes that content more searchable!

This is one area that I need to make a greater effort at adding to my web workflow.

Speech Impairment and Mobility Difficulties

Speech and mobility barriers, like auditory barriers, have also been a little harder for me to relate to. I’ve worked at a couple of nursing homes, so I understand them. But it’s hard for me to visualize the types of barriers I would encounter on a daily basis caused by:

• poor dexterity
• cerebral palsy
• multiple sclerosis
• aphasia
• dementia
• Parkinson’s
• and the list goes on!

One set of tools that I learned about which can ease communication barriers:

• Augmentative and Alternative Communication (AAC) systems: these types of devices offer users the chance to communicate with the use of symbols or pictures as a way to express needs and wants, along with emotions and self-determination

The cool thing about coupling symbols and images with our content? It benefits so many more people than just those encounter communication barriers!

Concerning mobility issues, I admit that I need to read more about the barriers presented and ways to compensate for those barriers. It wasn’t thoroughly covered in this week’s learning.

My Final Thought(s)

Accessibility can be achieved through a process of inclusive design or universal design. Inclusive design is not a specific design methodology; it is more like a philosophy that is applied to the design and development of products, systems, services, and environments in a people-centered way.

After fifty days of trying to understand what accessibility means and how to make websites more accessible, this is what I’ve learned, so far:

• Accessibility is universal design. It’s a philosophy of inclusion rather than a checklist of design items.
• Throw away the checklist. It’s not a scorecard of what you accomplish; it’s an effort to find ways to make your content equally available to all.
• Include as many people as you can, rather than designing for specific users.
• Keeping code simple can solve a lot of common web accessibility problems. Semantic code is beautiful, usable, and accessible.

Go Further

Below are different ways to learn more about web accessibility and people who struggle with barriers every day. Most of these resources are what I picked up from Week 1 of this MOOC, but a few are personal recommendations, as well.

Read More…

• Designing with Web Standards by Jeffrey Zeldman (I read it early on in my challenge, and would high recommend it to all web devs who haven’t yet read it; he’s a loud advocate for simple, semantic, and standardized code)
• Ghost Boy by Martin Pistorius (this is my own recommendation, but I was reminded of this amazing story as I read through my coursework)
• It Is Not Yet Dark by Simon Fitzmaurice
• Accessibility is Not Enough by Jakob Nielsen
• Usability 101: Introduction to Usability by Jakob Nielsen
• ISO 9241-210:2010 (International Organization for Standardization): human centered design
• Dyslexia Style Guide by British Dyslexia Association
• Which Font and Line Length is More Readable on the Screen? by Jacob Palme
• Layout Guidelines for Web Text and Web Service to Improve Accessibility for Dyslexics by Luis Rello, Gaurang Kanvinde, and Ricardo Baeza-Yates
• AACknowledge Research Base
• Glossary of terms from Southampton course
• How Screen Readers Read Content by WebAIM

Get Involved…

• International Association of Accessibility Professionals
• find others on Twitter who tweet #a11y or use that hashtag yourself as you find/learn new things

Use Tools…

• ATbar: an open-source, cross-browser toolbar to help users customize the way they view and interact with web pages

“To design is much more than simply to assemble, to order, or even to edit; it is to add value and meaning, to illuminate, to simplify, to clarify, to modify, to dignify, to dramatize, to persuade, and perhaps even to amuse.”

Paul Rand

Keyboard-Only for a Day #GAAD

In honor of #GAAD (Globally Accessibility Awareness Day), I committed to using my keyboard throughout my day at work. (Some cheating was involved, so I didn’t get in trouble for being unproductive due to keyboard adjustment mode.) The Minnesota IT department initiated a No Mouse Challenge that encouraged people to use their keyboard-only for 15 minutes. I started out doing 15 minutes — which was a challenge in itself — and decided to carry on throughout the day just to see how accessible my own Windows applications and Internet sites were.

Starting Out

Thanks to MNIT, I was able to wean off my mouse addiction right away with their handy cheatsheet of Windows and Office keyboard shortcuts. Alt + Tab became my new friend to switch between program panes, as did F6 for switching between panes within a window. So much use of arrow keys! I’m a pro with the scroll wheel on my mouse, so that was a hard habit to work against.

Firefox

There isn’t enough time in my world to test all the major browsers, so I went with my go-to browser Firefox. Here are some of the shortcuts I found to be the most useful throughout my day:

• Ctrl + Tab: moved me between my open tabs
• Alt + F (or other key): to open a specific browser menu
• Ctrl + W: close a tab

Frustration: trying to figure out how to save a PDF file that was opened in my browser. Hint: It’s not Ctrl + S.

Keyboard shortcuts for common tasks in Firefox.

WordPress

To write this post with just my keyboard turned out to be more of a challenge than I expected. Not only did I have a hard time finding my focus on where I was on the page in order to start a new blog post and position my cursor within the editor window, I also realize I didn’t know most of the shortcuts for formatting my text (like list items and headings).

Fortunately, a Google search was just a Ctrl + T away: WP keyboard shortcuts. Further reading showed that markdown is an available option, too.

I filled my knowledge gap with these shortcuts to format this post:

• Ctrl + Shift + Arrow key: select text
• Ctrl + k: add hyperlink to text
• Alt + Shift + u: make unordered list item(s)
• Alt + Shift + 2: change to a Heading 2 level

Frustrations I was left with:

1. navigating back to the editor pane if I switched browser tabs to look up additional information for this post;
2. focus of my screen. (I discovered as I added more text or keyed down within the editor to select content, the focus would not push the content up, but rather my text/selection would go off-screen. That could be frustrating for someone who does a lot of blog posts with just the use of their keyboard!)

Adobe InDesign

This application was a doozy! I’m not sure if anyone could actually work solely from a keyboard in InDesign, but — for today’s productivity’s sake — I didn’t spend a lot of time searching for answers. And all I needed to do was make some edits to business cards already made.

I did find shortcut keys on Adobe’s help site, which led to the inadvertent discovery of it as a keyboard inaccessible page. At least I couldn’t figure out how to tab away from their search box, which was the predetermined focus of the page.

My other biggest complaint was scrolling through my document without relying on Page Up and Page Down, which broke up my view of the page I intended to focus on.

Adobe Dreamweaver

Also, another visual and mouse-friendly application. Due to my time crunch, I used my mouse a LOT here. I fumbled around too long trying to switch between panes to select my directory and scroll through files. Ctrl + W worked for closing the file after I was done with it. I guess that’s progress.

Spiceworks

This being our work order ticket system, it was one web application I was not going to spend loads of time trying to figure out. I had work to do and tickets to close.

Frustration with their stark inaccessibility: I couldn’t tab through my options or easily navigate between a ticket and its description, which required me to click on “More.” Once I was focused in the My Tickets section, I was able to keydown through my list.

Toggl

I often use this timer application to keep track some of my work orders since I am splitting my time between my regular work and performing interim work for another division. I only had to use my mouse to stop a timer because I couldn’t find any indication of focus on tabbing. Fumbling with the Enter or Spacebar only had undesired results.

Overall Frustrations

• Where is my focus??? As someone who has a visual impairment, I need help with obvious indicators of where I’m at on my page or in my application. The keyboard left me a bit disoriented because my mouse gives me a little better idea about where I am and instance results from where I intend to go.
• I couldn’t always reach an important piece of content or interactive feature. I’m fortunate to be able to fall back on the mouse. Not everyone can do so.
• Scanning a page was more time consuming without the convenience of a mouse to instantly click on what I saw.

Perks of this Experiment

• My mouse hand got a breather today.
• I learned new keyboard shortcuts that actually made my workflow a little better.
• Discovered some sore points on our own division pages that are now on my list of improvement so they can be accessed via keyboard.
• I flexed my short-term memory muscles so I didn’t have to keep (inconveniently) switching between tabs, panes, and windows when I would forget something.
• This exercise corralled some of my multi-tasking tendencies in order to improve my memory ability and decrease tedious switches between applications.
• I feel like I have a deeper awareness of how keyboard users function on a day-to-day basis, and understand the frustrations some may encounter throughout their day.
• This awareness has given me some ideas to add to my testing toolkit.

 

I work with so many desktop applications and websites throughout the week that this was just a scratch on the surface for me when it comes to understanding keyboard use. But I do hope to be diving in on a more regular basis — not all day — to keep the ideas fresh and gain a better understanding of our diverse users.

Did you acknowledge GAAD in some way today? If so, what did you learn from it?

Hyphen, En Dash, Em Dash

Yesterday I attended an all-day professional writing workshop presented by Jim Hale. Observing through the lens of a web designer/developer, I found several discussions among the group to be pertinent to writing and editing content on the web. The discussion about punctuation was very engaging. In particular, the definition and purpose of hyphens, en dashes, and em dashes struck a chord.

Below are my brief notes on this topic.

Hyphens

Best used for range of dates or hyphenated words.

En Dashes

Useless.

Outdated once the typewriter was replaced by the word processor. Use hyphen instead.

Em Dashes

Best used for parenthetical expressions. Especially useful for dramatic purposes.

What do you think?

Do you code a dash or hyphen? Or do you not escape this character at all?

How to Learn Web Accessibility

What does someone need to do to learn web accessibility? Take a first step forward with the desire to learn. The only way to achieve anything is to start doing something about it.

Now that I’ve committed to #100DaysOfA11y, where do I begin?? I want to make the most of my 100 days, so I’ll start with a loose learning plan to help me stay on track and tackle a topic that I’ve been meaning to investigate these past 3 years.

Goals:

• Complete Southampton’s Digital Accessibility course.
• Read Inclusive Design Patterns by Heydon Pickering.
• Read Designing with Progressive Enhancement by The Filament Group.
• Read Apps for All by Heydon Pickering.
• Work through the W3C’s accessibility tutorials.
• Traverse the WCAG 2.1 and WAI-ARIA rabbit hole to understand those nitty-gritty details.
• Understand CSS Grid and Accessibility.
• Update most of my coding projects to be accessible and follow a universal design pattern.
• Gain an in-depth understanding of U.S. law for people with disabilities and the 504 and 508 standards that were put into place.
• Set a plan in action for my own work place to become AA-compliant.
• Teach my co-workers about Digital Accessibility in less than an hour.

Plan of Action

• Week 1-5: Southampton Digital Accessibility course
• Week 6-7: Work through W3C’s guided tutorials and read through their references
• Week 8: Evaluate and update my own coding projects; start Apps for All
• Week 9-10: Read Inclusive Design Patterns
• Week 11-13: Read Progressive Enhancement
• Week 14: Start a11y audit plan of webpages at work
• Week 15: Develop a lesson plan for teaching co-workers and others about digital accessibility

As I learned from completing the 100 Days of Code challenge, a lot can be learned and accomplished in 100 days. My plans mentioned above are flexible with the intent of keeping me on track in hopes of accomplishing what I set out to do. I truly hope I run across other resources and get tips from accessibility professionals that will derail my own aforementioned goals, yet hone my learning path.

So, here I go. Let my next 100 day journey begin!

Adding Styling to Multiple Elements

The nice thing about not having an actual programmer’s job is that I can experiment and contribute coding at work without the pressure of immediate product. A recent enhancement I got to work on while editing content on a page: changing the style of several form options that did not reference a file.

function grayOptions(){
  const options = document.querySelectorAll('option[value=""]');
  options.forEach(option => option.classList.add('gray-out'))
}
document.addEventListener('DOMContentLoaded', grayOptions, false);

I was so proud of myself! Until Internet Explorer beat me down. Why, oh, why do only half of these things work in IE?!? I removed the fat arrow function, changed out ‘classList.add()’ with ‘className’, and changed up the forEach method a bit. All to accommodate IE’s partial or lack of support. Phew!

CSS-Tricks wrote a great article Loop Over querySelectorAll Matches to help me understand the forEach problem. My new solution that now works across all browsers:

function grayOut(){
        const options = document.querySelectorAll('option[value=""]'),
              optionsLen = options.length;
        let i;
        for(i = 0; i < optionsLen; ++i){
            options[i].className = 'gray-out';
            options[i].setAttribute('title','no file available');
        }
}
document.addEventListener('DOMContentLoaded', grayOut, false);

It’s these little coding wins that give me the encouragement I need to keep on digging deeper into the complex art of front-end development.