Forem: Christine Golden

Upping My Accessibility Skills

Christine Golden — Thu, 20 May 2021 13:01:42 +0000

In acknowledgement of Global Accessibility Awareness Day (GAAD), I've finally done something I've been meaning to do since I started coding 10 years ago. I listened to my website with a screen reader.

Using my portfolio site, I recorded a bit of the Screen Reader Audio

At first it was overwhelming. All those extra words made it sound like gibberish. There are lots of settings, with differences between OS updates, and I still don't know how to get it to just slow down, pause or go back. A handicapped person would certainly need knowledgeable help to get a working system set up.

According to the CDC, 1 in 4 adults in the US have serious difficulty doing the things I take for granted. Difficulties that would make it hard to work a keyboard, see, hear and understanding web content. The pandemic would have only made things worse for many of these people.

Fortunately, according to Mozilla's Accessibility Learning Area, HTML used correctly is a strong starting point. There's also a fair amount of overlap with good SEO practices and Accessibility.

Besides compassion, there are other reasons to up one's game in this aspect of front-end development. For one, handicapped people buy stuff, too, so that's motivation for business owners. For another reason, it's the law. Enforcement comes about through someone sueing the web owner, so my advice is to not aggravate and confuse your site visitor!

Web Content Accessibility Guideline (WCAG)

The World Wide Web Consortium (W3C) develops standards for the web. It's official accessibility guidelines are spelled out in the WCAG, the Web Content Accessibility Guideline.

I tried, I really did try to read the WCAG documentation - even made a spreadsheet. Finally, I gave up. It's probably good to have such a comprehensive gathering of info somewhere... but in practical terms, everyday web devs who are struggling to keep up with the latest tech, so they can make a living, will be too discouraged to follow through with that set of docs. :}

Thank Goodness for The A11y Project!

The A11Y Project is a community-driven effort to make digital accessibility easier.

A11y is a symbol for the word 'Accessibility'. 'A' followed by 11 characters, then 'y'

They have a Checklist, written in language I can understand with linked references to the official Guidelines.

There are 15 main categories and several sub-categories that each deserve enough study to produce their own article. I can see why the industry of accessibility testing is going strong! It's a specialty.

Initially, I intended go through each one of the items and make sure I had them included in my website boilerplate and thought process. But that's going to take more time than I have right now.

So, this article is going to be more of a planning exercise. I'll look at each category and see what I'm already doing and what I still need to learn, with some references for study.

I know this will help me learn. I hope it will give you some tips and perspective, too.

The Checklist

Content

Simple, direct, easy to read content is important for everyone who comes to a website.

📋 Button, anchor and label content needs to stand alone with respect to its meaning. Good for SEO, too. It takes a little extra creative effort.

Global Content

Responsive code design and standards-compliant HTML takes care of a lot of these items.

📋 Semantic HTML provides good info for screen readers except for the generic div, section and form elements. I need to learn more about ARIA (Accessible Rich Internet Applications) attributes, especially now that I'm learning how to build web apps with JavaScript.

Keyboard

Tab through the website and see if the focus order makes sense.

📋 I hate the default outline style that browsers apply to active links. CSS-Tricks has a few modern articles on creating my own styles for those :focus elements.

Images

Make sure all images have the alt text attribute, even if they're purely decorative, then the alt should be null, as in no-space.

📋 I need to experiment with null alt attributes to see how they sound. I've been adding a space character all this time and the screen reader says, "unlabelled image" which sounds irresponsible to me. :\

📋 There are a lot of recommendations for best use of alt text. WordPress users, did you notice the link to An alt Decision Tree that core provided sometime in the last few years?

Headings

Headings are for grouping written content in meaningful ways (not for decoration). Well-organized use of h1, h2, h3, etc. tags are helpful to everyone, disabled or not. It's also good SEO.

There should only be one h1 on a page for accessibility. This means the site title needs to use a different element.

Lists

Use the right list elements for lists.

Controls

Lots of good, common sense guidance in this section. Use anchor elements for links, the button element for buttons.

📋 None of the links in this article automatically open to a new tab/window, but if they did one needs to notify the site visitor it's going to happen. I wish we had a universal ASCII symbol for links that open in a new tab. I'll need to test if/how screen readers pick up the target attribute.

📋 I recently started using 'skip-links' in my websites, but need to review them for updates. Again, a CSS-Tricks' article How to Create a “Skip to Content” Link looks like a good starting point.

Tables

Semantics, again. Use table elements for tabulated info. The Guidelines ask that th and caption elements be used as well. I haven't been using those regularly.

📋 I'm going to have to look up the scope attribute, which the Guidelines ask for.

Forms

Make sure forms are well-organized and labelled.

📋 Learn best practices for styling error and other status messages.

Media, including Video and Audio

Don't auto-play and make sure controls are available. The Guidelines on providing readable text applies; use captions and transcripts.

📋 This means I should have prepared a transcript of the audio I've included above. Have you ever typed up your own transcript? It takes a good amount of effort and time, and a helpful transcription app, that my clients would probably not pay for.

Appearance

Using a simple, straightforward layout is good for all users, and is forced upon us when thinking in 'mobile-first' mode.

I already test my websites in all the modern, popular browser and the mobile devices I have at my disposal. The WCAG Guidelines also asks us to test in specialized browsing modes, such as Windows High Contrast or Inverted Colors. For freelancers this will add costs to a project that clients may not want to pay.

📋 I'll need to learn the different specialized browsing modes on Window and Mac OS and test which styles are broken by those modes.

📋 I've never done it before, but increasing text to 200% would be a good test.

📋 Another design pattern I've never considered can be evaluated by what's called The Straw Test. It's always a good principle to not spread content over too wide an area.

Animation

Content that moves can be problematic to some people. Here are the items to check for.

Ensure animations are subtle and do not flash too much.
Provide a mechanism to pause background video.
Make sure all animation obeys the 'prefers-reduced-motion' media query.

Color Contrast

📋 Normal and large-sized text, and icons all have specific contrast ratios. Here's a tool for calculating color contrast ratios. I didn't even know it could be calculated!

As always, make sure text over graphics are clear.

📋 There is a CSS pseudo-element I wasn't familiar with, although I've enjoyed its use on some websites. It's the ::selection pseudo-element and it adds style to text that the user has highlighted. As you can imagine, make sure the reader can still read the text.

Mobile and Touch

The sub-categories of this one are all the same as good, mobile-first, responsive styling. Make sure the site can be rotated, check the distance between links and buttons.

📋 I've been seeing horizontal scrolling lately. The Guidelines say not to do it, but it looks useful in some cases. More research is needed on this.

Okay, so that's the list I'm going to be working with. There's no such thing as 100% Accessible. We can only keep striving to improve.

Let me and anyone reading know of additional tips, references or experiences you have. Best!

There's a New VS Code Sass Compiler in Town

Christine Golden — Fri, 30 Apr 2021 02:55:03 +0000

Sass has been a part of my workflow for years. The fact that it allows me to write nested CSS is sufficient enough reason for me to install it, although I use it for more than that.

Back when I first started with Sass, CSS variables weren't a thing, so I used SCSS for that too.

At the time, I used a combination of CodeKit, a well-maintained app that also includes up-to-date vendor prefixing. However, that meant opening two apps ( CodeKit and SublimeText ) for every coding session.

Now that I'm learning JavaScript and React, I see that 'everyone' is using VS Code. For a while, I resisted and started using SublimeText 4 (beta). I'm a little embarrassed by my disloyalty, but I have finally succumbed to the new-geek-toy pressure and have made the switch to VS Code.

While exploring SASS compiler options for VS Code, the articles and videos I found kept leading me to Live Sass Compiler by Ritwick Dey. This compiler also installs an extension called Live Server. The installation went smoothly and I set up my .scss files.

I use partials to organize my CSS. Partials, which hold smaller segments of the CSS, are stored in files that begin with an underscore. For example, _global.scss or _header.scss. They are grouped together in a file using an @ rule, which is then compiled into the CSS file.

Until this morning, I thought I was to use the @import rule that I've always used, and which compiled to CSS just fine using the extension.

While reviewing Sass's docs, however, I came to find out that they are now offering a proprietory rule called @use instead of @import. It has to do with a relatively new feature called modules... which is a topic for another article.

@use 'typography';
@use 'global';
@use 'layout';
@use 'header';
@use 'nav';
@use 'page';
@use 'footer';

When I tried using the @rule, though, the compiler just copied it straight into the .css file. It did not compile.

Sending out the posse

Support FAQs for Live Sass Compiler are kept in the Issues section of its GitHub repository. Searching for help was greatly hindered by the fact that most of the issues were titled "Extension Issue!" This must be a default title in the GitHub system and is an excellent example of how not to write support issue titles!

I persisted, and by searching and scrolling, finally found an issue called "THIS EXTENSION IS NO LONGER MAINTAINED."

At the time of this writing, only a few weeks have passed since Glenn Marks posted that Issue. He is actively maintaining his own version on the marketplace.

The extension's GitHub repository and FAQs are at https://github.com/glenn2223/vscode-live-sass-compiler. I can see that Ritwick Dey is a Contributor so I'm assuming this newer version has his blessing.

I uninstalled both Live Sass Compiler and Live Server without incident. Then I followed Glenn's instruction to install his version by opening the Quick Open palette in VS Code ( cmd+P on a Mac ) and typing

ext install glenn2223.live-sass

I happen to be learning the static site generator Hugo right now so I already have a live server environment. Glenn's new version says it comes with a live browser reload feature. Was this going to cause a conflict? With bated breath, I compiled my existing .scss files using the @use rule... and it worked! I've since added more partials and styles and it's still working.

The Bottom Line: Live SASS Compiler by Ritwick Dey is no longer
being maintained. Use the extension by Glenn Marks, who is
maintaining a fork of the original ~~with Ritwick Dey's support~~. See update in the comments.

I feel gratified to know I can use the latest Sass features and look forward to continuing with my project tomorrow.

Kudos, Glenn! Thank you.

Miscellaneous

SublimeText is still an awesome code editor. For now, I'm using it as my text editor. It feels like it opens so much easier than others.

I still need to check into vendor prefixing, but I'm not too concerned as most of my client work does not need cutting-edge CSS.

Now is a good time to be catching up with the CSS I've let slide, though. For example, I'm using CSS variables now instead of SCSS variables.