A Baker’s Dozen Quick and Easy First Steps. Accessible techniques sometimes save development time

By quick and easy, I am referring to web content that experienced developers can implement with their existing skillsets and not have to beg for deadline extensions.

Use Real Headings

A real heading is much more than just a row of large, bold words. It is an informative summary of the content to come and resides in a heading tag.

Extra effort should go into making the main heading useful, even when it introduces a widget instead of an article. This helps all users, not just those with disabilities.

The main heading should be one of the first elements of the main section and should be an<h1>.

The lower-level headings (<h2> to <h6>) should be used� to reflect the sub-sections. Sub-sections of equal importance should use <h2>s. Any subsections of those divisions should use <h3>s . Never skip a heading level just to get a different font. In such a situation, use a style to format it as needed.

Please do not put heading tags� throughout the page just to give screen reader users more places where they can quickly jump. You can create the impression that the page has an organization that does not exist. By implication, all headings should really be followed by related content.

I have occasionally seen sites where well-intentioned but misinformed� developers put every clickable element in a heading tag. Presumably, they knew screen reader users can use the �h� key to jump from one heading to the next. Whatever the reason, the result was disastrous. Navigating the pages� took forever, and I was thoroughly distracted from the content.

My bugaboo. I think headings should be reserved for the main content of a page, not banners or footers.

See: <h1> to <h6>: The HTML Section Heading elements: mozilla.org)

Use Landmarks as, well, Landmarks

Landmarks are HTML elements that identify significant divisions of pages, providing important information on where the screen reader user is in the page.

I have seen a few websites where every detail seemed to be in its own landmark. The result was screen reader pollution. Every time I pressed an arrow key I was hearing �section this� and �section that.� I could hardly keep track of my reading.

A well-designed page may have only four or five landmarks.

Use <header> for the banner. This might include a <nav> element for the page�s main navigation links.

Use <main> for the primary content of the page. A simple page might not need any additional� landmarks within this area. However, you may want to use <article> and <section> to delineate text and widget areas.

Use landmarks that are appropriate for their content. I have seen a site that used <article> as the container for an interactive form. That was confusing and unnecessary. The <form> element provides good accessibility.

See: Webaim.org on semantic structure

Watch Your Font Sizes

Think twice about using body text that is smaller than 16 pixels. No Web standard defines such a threshold. I just think this is a good level to trigger a review� of how your body text will be consumed by users with poor eyesight or cognitive disabilities.

Size is one of several font factors to consider.
See: WebAIM: Typefaces and Fonts

Build Data Tables with real Table Structures

A real table uses the <table> element and reserves the <th> element only for column or row headers. The data cells only use <td> elements.

A basic table like this is fully accessible without enhancements and adds nothing to the overall development workload.

Unfortunately, table imitations often are cobbled together� in what might as well be black holes for me. I have seen a Wordpress site where what appeared to be a six-row table was actually six tables floated together. I know of a major financial site that displays mutual fund research in a table that appears to have 14 columns. �This actually is two tables positioned side-by-side, one with 3 columns of data, then another table with the remaining columns. When I navigate to the third cell of a row, I hear JAWS say �end of row.� I have not figured out whether I can read the remaining columns.

See: MDN on table advanced features and accessibility

Set the Focus in Any Popup

Setting focus in a popup, such as a menu, typically involves one or two lines of JavaScript. That is why I am including this in my list of easy� steps.

I have experienced numerous sites that initially seemed nicely accessible. Then a popup appeared, and I was at a roadblock because I could not navigate into the item.

I realize that this topic touches� on the issue of interactive widgets, which is far too involved for this �list. But I am frustrated that setting focus is so easy ��yet often ignored.

Support Users who Need to Magnify Page Text

Including buttons that enlarge text is very nice but not essential. Far more important is designing your page content to adjust appropriately when the consumer uses the browser to do this. Some low-vision users run Firefox specifically to get its Enlarge Text feature. Enlarging text has a significant advantage over the more common zoom features that make the web page wider than the monitor.

Note: I realize that there may be nothing quick and easy about this task when updating an existing site. On the other hand, I think making these adjustments on a new site should be easy.

The challenge is that magnifying can cause contents to overlap or become hidden. There are several ways to prevent this from occurring.

Using relative units of measure (such as REM or %) instead of fixed sizes like pixels. is a good first step. Use relative measures for sizing fonts and elements that contain the page contents.

�Try to avoid setting explicit sizes for both the height and width of containers. �Be cautious about turning off word wrap and the default display� of overflowed text.

Show Keyboard Users where They have Tabbed

This is the easiest step in this list. Uh, well, easiest if you are willing to use the right techniques.

And the easiest way to satisfy this step is to leave the outline property alone. By default, browsers show the outline on any button or link that has focus. Some developers think the page looks cleaner if they turn off the outline. That is a big problem for keyboard users. They quickly lose track of where they have navigated.

Fortunately, developers have alternatives if they really want to turn off the outline. They can show focus by changing the background color, changing or showing a border or displaying a marker at the left of the element.

Ensure that the Page‘s Tab Order makes Sense�

Imagine this scenario:

A page has a button labeled Get started, which is followed by a button labeled Final steps. A screen reader user navigates the page by pressing the Tab key The screen reader announces a series of buttons and links at the top of the page. Then, it says final steps, button. The user mulls this and presses Tab again, and the screen reader says get started, button.

Clearly, the user will wonder why things are finishing before they are starting.

This has happened because the HTML source code lists the buttons in the reverse order of how they appear in the browser. The developer used modern formatting techniques to control the displayed button order. To a mouse user, this is no problem. To a keyboard user, it is.

The solution is simple: fix the HTML source code.

The problem can be easily spotted by just tabbing through every finished web page.

Name the Site Owner in the Banner

Do not assume users can quickly scan the body text or footer to find this information.

If you do not want a long name cluttering the banner, just add it as alt text to the main logo.

Properly Flag Required Form Fields

Form controls with the required attribute enabled often are marked with a color such as red.

Color-blind users may struggle with such forms.

Enhance these controls with text or symbols that show the required status.

Rethink Your Click Here Links

Links that only contain the words click here are maddening and confusing to screen reader users.

The solution is simple: Just include a whole thought in the link. For example:
To order today‘s special, click here.

Watch your language

Declare the page default language on the opening <html> tag

This is becoming fairly common, in part because it is easy to do. In most web pages, this is all that is needed. Modern screen readers will adjust their output accordingly.

Sometimes, however, the work has just begun. All words or sentences in a different language must be marked up. This no doubt will be tasks for the web developer.

In my opinion, the content authors need to take responsibility for some decisions. When working on an English-language page, they need to decide whether a foreign word has become Americanized and should not be flagged. Many culinary terms fall into this category. In addition, they need to be alert for the rare words that, even if Americanized, need non-English letters. I ran in to this situation recently when JAWS spoke what sounded like KRU dite. A few sentences later, the author corrected himself and JAWS spoke kru de TAY. The correct word was crudité. The ending é was all that JAWS needed to speak the word correctly. No language label is neded here.

Test your Pages with a Utility such as WAVE

Many tools for testing Web accessibility have popped up in recent years. One is WAVE®. See WAVe.Webaim.org

Postscript

Two final suggestions for anyone ready to learn more:

First,concentrate initially on learning about ARIA that is related to document structure. That should go fairly quickly. The widget-related roles and attributes are trickier, partly because they are more likely to impact how you use JavaScript.

Second, consider using free, open-source widgets that implement accessibility techniques.
See: Whatsock.com

Published: 10/05/2022