Just recently, Colorado became the first state in the US to pass a bill that requires state and local government websites to meet accessibility standards. This is huge news in our industry and something we’ll definitely be keeping an eye on.

Even if you are not a government organization, or there are no laws requiring this in your city or state now, the time is coming. Much like GDPR, this will spread and eventually become the norm. It’s worth taking the time up front to ensure that your website meets accessibility standards now so that you are creating a solid foundation for the future.

What are accessibility standards?

We won’t get into every specific detail, but we can point you in the right direction. The newest version of the Website Content Accessibility Guidelines, created by the World Wide Web Consortium (W3C), the main international standards organization for the World Wide Web, is version 2.2. However, at the time of writing this article, 2.1 is what the majority of website agencies and developers are working towards.

In the abstract from the 2.2 version of the guidelines, W3C breaks down website accessibility standards like this:

“Web Content Accessibility Guidelines (WCAG) 2.2 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content more accessible to a wider range of people with disabilities, including accommodations for blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and combinations of these, and some accommodation for learning disabilities and cognitive limitations; but will not address every user need for people with these disabilities. These guidelines address accessibility of web content on desktops, laptops, tablets, and mobile devices. Following these guidelines will also often make Web content more usable to users in general.”

As you can see, the intention is to make web content more accessible to all users, but there are some more specific considerations. For example, listed early in that abstract is blindness and low vision. Typically these are the driving force behind these guidelines and a great place to start.

Why are accessibility standards important for your website?

If you have never paid any attention to this before, your website might be riddled with issues that make it hard for these specific types of users to actually get to the important information on your website and something you should begin to consider.

Let’s start with what we recommend not doing. There are some ‘plug and play’ types of tools out there that claim to be a simple solution to meeting accessibility standards, but more often than not they will cause more problems for the user than you would find by building your website and it’s content out thoughtfully in the first place.

For example, if you are using WordPress as the platform for your website, you can find some plugins that will allow your users to make changes to the front end of your website on their own (i.e., change font sizes, switch between light and dark modes, etc.). I highly recommend staying away from the one size fits all type of approach to accessibility and, instead, really put some time into making foundational changes that will ensure it’s done correctly.

Now let’s talk about a couple of things that you can do or focus on.

• Accessibility statement
• Navigation menu
• Images
• Links
• Styling

Accessibility Statement

An easy first step is to put up an accessibility statement. To be honest, this does absolutely nothing to immediately benefit your users in any way. It’s simply a statement and commitment that you are keeping accessibility standards top of mind and are making an effort in that direction. It’s easy and, if nothing else, will be a way to hold you, the website owner, accountable for keeping your word.

Navigation Menu

When you tried the screen reader, were you able to successfully tab through your navigation menu? If you look at the code for your menu, is it simple to read or is it a jumbled mess of unnecessary classes and animation features? W3C provides a simple breakdown of recommendations for navigation on the Menu Structure page of their web accessibility tutorials.

Using the WordPress menu system, it’s easy to organize your navigation menu in a thoughtful way and change it up as needed. Your theme could have an impact on how it’s presented so just double check this area and see if any simple changes can be made now. Otherwise, make sure this is a priority as you rebuild in the future.

Images

One of the key areas of focus for meeting accessibility standards is how you treat images in your page content. As you can imagine, a blind or low vision user isn’t going to be able to process much about an image. It’s important then to ensure that you are using the available HTML tags to add a description to those images.

This will communicate a description of what the image is instead of showing the image itself. “Making Images Accessible,” an article from the University of Washington, lays out a few helpful examples.

Links

Similar to images, there are some simple steps you can take to update your existing links in your page copy. These steps will ensure that a screen reader can give a little more context to the user.

First, consider the styling of your links. If a person with limited vision is still reading your text, you’ll want to ensure a high contrast between the text itself and the background. As well, you may be familiar with website style where there is no underline under a link. While this may look good to someone with full visibility, someone without might not notice that it’s a link.

Next consider the context of your links. Here is a quote from an article by Yale:

“While screen readers can read a full page to a user, screen reader users may prefer to instead listen to a list of links. In that case, a screen reader may only read the link text and not the surrounding text.”

As you can imagine, simply hearing the text of a link might not be informative enough for the user to know what it means. The idea here is to ensure that your links are contextual words or phrases.

The text “click here” as a link doesn’t tell the user very much, but “you can find our contact form here” as a link tells the user plenty of information.

You should also consider ARIA techniques, which allow you to add additional context specifically for screen readers. This would allow you to keep a “click here” link text while including “you can find our contact form here” context specifically for the screen reader.

Styling

One of the most simple updates you can do to your current website now is make style updates. Style updates would apply to things like colors and fonts. In regards to accessibility, it’s important that fonts are an appropriate size and that colors meet specific contrast ratios.

For users with visibility issues but not using screen readers, larger font sizes are helpful. There is not a specific size that they should be, but the recommendation is that it is not smaller than 9pt or 12px. Lately, our designs have been using a body font size of 18px.

In regard to colors, contrast ratio is the key. To meet accessibility standards, the contrast ratio between text and the background must be at least 4.5:1. Unless your designer specifically spent time to ensure this is the case, it’s likely that you have areas of your website that do not meet this requirement.

An easy way to test is using a contrast ratio check application like WebAIM contrast checker. You can also find specific color combinations that work together from your existing branding guidelines is by using the Accessible Color Palette Builder.

What happens if you do not meet accessibility standards?

At this time, if you do not live in Colorado, nothing happens. However, as time goes on, this will become law in more states and across the globe.

Using GDPR again as a reference, we will likely see government organizations tagged first, then public organizations like schools and universities. It will eventually trickle down to any for and non profit organizations.

That said, you have users right now that have trouble using your website. This isn’t something that you should be doing because the law says you should; it’s something that should be a priority as part of the user experience of your website.

What can you do to understand website accessibility standards better?

My first recommendation would be to step into the world of screen readers. These are the tools that users with blindness or limited vision use to navigate websites.

For example, while the Screen Reader Chrome extension is no longer supported, you can still install it and try it on your own website. I encourage you to try to navigate through your website with this tool to get a better understanding of how a user with limited or no vision has to navigate.

Unless you’ve taken specific steps already to ensure that this process is smooth, it’s likely going to be difficult. Additionally, we recommend spending time going through the actual guidelines themselves listed on the W3C website. Here are a few links to get you started.

• Guidelines Overview
• 2.1 Standards
• Quick Reference

Work with a team that knows accessibility matters.

As you design or redesign your website, consider enlisting help from a team of accessibility experts. Contact WebDevStudios. We know accessibility matters and work hard to ensure your website project meets accessibility standards.

The post Website Tips for Meeting Accessibility Standards appeared first on WebDevStudios.

Think about that for a minute. How do you know that? Whether or not your visitors have a disability is not a metric tracked by your favourite analytic software. I guarantee you the opposite is true. Your website absolutely does have visitors who have disabilities.

How can I be so sure? The answer is simpler than you might think: we have all experienced some form of disability, and we will again.

What’s a Disability?

Often the image of a person with a disability is someone who is blind or deaf. These are permanent disabilities. However, there are also temporary and situational disabilities that exist, too.

To put these into context, consider your dominant arm. If it were amputated, that would be a permanent disability. If it were broken, that would be a temporary disability. If you were holding a bag of groceries, that might be a situational disability. All of these scenarios would prevent you from using that arm for a period of time. So you can imagine how having a mobile version of your website that is easy to navigate with only one hand would benefit more than just people who only have one hand.

There are lots of other examples of temporary and situational, as well as permanent, disabilities that people experience which impact how they use a website. Improving the accessibility of your website will ensure all your visitors have the best experience possible. Let’s look at how an accessible website benefits everyone and what the potential barriers to a successful site visit might be, as well as some conditions that might be affected.

Neurological Scenario

Imagine: You get home from work and have to feed your kids. You have a migraine. The kids are excited and loud, adding to the brain fog from your migraine. You decide to order delivery from a website.

Potential Barriers

As you visit the restaurant’s website, you want to place your order and pay as easily and quickly as possible. Navigation, buttons and links should be easy to find and their purpose should make sense, otherwise you could get confused and frustrated. Too many calls-to-action fighting for your attention are distracting at the best of times, but when you can barely concentrate on the task at hand, they can also cause confusion.

Fast-moving animations can make your headache worse and might even make it hard for you to look at the screen. And if you make it to the checkout page, there are a variety of form issues that can make it hard to complete your order, like disappearing placeholder text or not being able to click into a particular field. Encountering any of these issues could result in you giving up and taking your business elsewhere.

Migraines fall under the neurological category of accessibility, which includes ADHD, epilepsy, and autism as permanent disabilities. Other disabilities and related situations include:

• Brain fog
• Lack of sleep
• Flu/cold
• Anxiety
• Depression
• Stress
• Distracting environment

Audio Scenario

Imagine: You decide to remote work from the local coffee shop. Stuck on a problem, you search for a tutorial and find the perfect video embedded on its own webpage. But darn it… you forgot your headphones at home!

Potential Barriers

Without your headphones, you won’t really be able to hear the sound on the video without disturbing everyone in the shop. If there are no subtitles or closed captioning, you can’t put the video on mute and follow along. If the person didn’t include a transcript, summary, or other written form of the content, and your only way to get the information is to watch the video, you are out of luck.

Another issue that isn’t a barrier, but can cause issues, is when videos (and audios) are set to autoplay. I can’t tell you the number of times I’ve jumped out of my seat being startled by autoplaying videos, even on sites that I visit every week! These situations all fall under the audio category of website accessibility, which includes people who have some form of permanent hearing loss. Other disabilities and related situations include:

• Tinnitus
• Plugged ear
• Skimming text to find a quick answer
• Learning a new language
• Loud environments

Keyboard Scenario

You are a WordPress developer who never takes your hands off the keyboard. There is not a mouse to be found anywhere in your office and you know all the keyboard shortcuts. You decide to register in an online course for the latest and greatest headless platform.

Potential Barriers

As you start tabbing through the page, there are several potential frustrations you might encounter. If there is no “Skip to Content” option, you’ll have to tab through every menu item in the main navigation. And speaking of that navigation, hopefully it’s set up correctly so you can easily avoid all of the sub-menu items, otherwise you’ll start to wonder if you’ll ever get out of the header area.

Some sites have removed any focus indications on links and buttons, so you’ll have no idea t where you have tabbed. Others have implemented a tab flow that doesn’t seem to have any rhyme or reason to it, taking you from the top of the page to a form at the bottom of the page, then to the middle left and maybe over to the top left then down to the middle right… are you confused yet? Me, too.

By the time you get through to the registration form, you might get stuck in “keyboard traps,” like not being able to return to a field once you’ve move on to the next one, or being unable to leave the form any way other than hitting the submit button. These frustrations are in the physical category of website accessibility; and in this case, specifically those who require a keyboard or other button-based device to navigate the web. Other disabilities and related situations include:

• Broken arm/wrist/finger
• Carpal Tunnel Syndrome
• Mouse battery died
• Sleeping baby or pet on your lap (they’re too cute to move!)

Visual Scenario

You live in California and work online from home. It’s a hot summer day and you don’t have an air conditioner, so your windows are open. Wildfires break out nearby, causing poor air quality that irritates your eyes and blurs your vision. Utilities are affected and your wifi signal has become weaker than normal.

Potential Barriers

Your poor eyes are having a hard enough time staring at the screen all day. Visit a website with small text, in a thin condensed font, and you’ll feel like you’re trying to read the last row on an eye exam chart. Sure, you can try to zoom in and make the text bigger, but there’s the possibility the layout isn’t well-suited to resizing either.

If there isn’t enough contrast between the color of the font and the background, maybe it’s a light grey on off-white, and it might seem like you are looking at a blank page. What if the only difference between linked text and regular text is navy blue instead of black? There is a good chance you won’t realize that you can click on that navy blue text. Remember that weak wifi signal? It could prevent images from loading, and if there isn’t appropriate alt text set up, you could be missing important information.

These scenarios all fall into the visual category of website accessibility, affecting people who have colour blindness or reduced vision. Other disabilities and related situations include:

• Eye injury
• Dilated eyes from eye exam
• Aural migraine
• Bright sun shining in eyes or on screen
• Allergies
• Forgotten reading glasses

Normalize Accessible Websites

All of the scenarios were based on real examples, many that I have personally experienced. Maybe you can relate to many of them, too. If not, I’m sure you have experienced some of the other disabilities and related situations listed at the end of each scenario. I challenge you to come up with your own examples, which you can share with others, helping make website accessibility considerations become more commonplace. At the very least, I hope I have convinced you that owning, maintaining, and making an accessible website benefits everyone.

The post Accessible Websites Benefit Everyone appeared first on WebDevStudios.

Gutenberg default blocks were built with accessibility in mind. With every release, more accessibility improvements are being added. The WordPress Gutenberg, Design, and Accessibility teams spend a lot of time and effort toward improving user experience. WordPress, at its core, has always been committed to being as inclusive and accessible as possible; and every single new release brings in new accessibility improvements.

Because of this, every new additional feature to WordPress, be it a custom theme or a custom block, needs to follow the accessibility guidelines. But how do we make sure that our custom blocks are accessible? How do we test it?

How to Make Custom Blocks Accessible

Creating a new block is fairly easy. The Block Editor Handbook has an easy-to-follow tutorial to hep you get started named Writing Your First Bock Type. Below are a few things you need to include in your custom block:

1. Assign appropriate ARIA landmark roles to each area of your custom block. These will allow screen reader users to know exactly what your block is and where they are inside your custom block.
2. Use Semantic HTML. Semantic HTML is standards-based and stable. It will be parsed and elements will be styled and communicated properly to end users by screen readers and other assistive technologies. In short: IT JUST MAKES SENSE.
3. Make use of the `.screen-reader-text` CSS Class. The .screen-reader-text class was introduced in 2009 and each theme and/or custom block should have this style class added by default. This class is used to visually hide text meant for screen readers and for `skip links` to make sure that it is visible when focused for those who use keyboard navigation.
4. Pay attention to heading structure. Add headings to meaningfully describe the content of your block where necessary.
5. Be mindful of links. Screen readers call a list of links to quickly navigate a site. You must make sure that all links are structured correctly and meaningful. Below are some things to avoid:
   1. Multiple/duplicate links to the same location
   2. Meaningless link texts
   3. Too many tab stops

If you want to know more about making WordPress accessible, you can head on to the Accessibility Handbook.

How to Test Accessibility

There are many ways to test accessibility of a website. Below are some tools that you can use:

1. WordPress  Accessibility Best Practices
2. WordPress Accessibility Front End Code Test
3. The A11Y Project Checklist
4. WP Accessibility Plugin
5. Accessibility Insights

I hope this blog post will help you make your custom blocks accessible. If you like this article and want to learn more about accessibility, read the WebDevStudios blog for more information on this important subject.

The post How to Make Your Custom Block Accessible appeared first on WebDevStudios.

An accessible website means it is properly designed and coded in such a way that all users can access the same resources regardless of abilities. Simply put, an accessible website means that all users regardless of background have equal and fair access to all your site’s content and resources. Sadly, even in our new decade, a majority of the internet remains inaccessible to millions of people. If you operate any online resource blog, eCommerce shop, web application, etc., ignoring this portion of the population not only reduces the number of customers you can serve but also presents legal risks, as well. It is my intentions to serve as a starting point in your journey to making your online services more accessible to others, although I make no illusions to this being a comprehensive list. However, by putting into practice these steps you will be well on your way to making your WordPress a more fair and accessible place.

Monetary Benefits

It’s estimated 19.4 % of all United States residents have some form of disability. This represents over 48.9 million people just in the U.S. alone. The total after-tax disposable discretionary income for working-age people with disabilities is $21 billion! From a conversion perspective, why would you not want to serve value customers? In a survey by Click-Away in 2016 71% of disabled customers will abandon a site that isn’t accessible and will never return.

Legal Reasons

In 1998, the US Congress amended the Rehabilitation Act to require Federal agencies to make their electronic and information technology accessible to people with disabilities[1] . The reason behind this decision was to provide equal access to all information technology for people with disabilities.

Fast forward to today, and still, a large part of the public web remains inaccessible to those with some form of disability. This inaction of the collective web has resulted in the need for legal action to force website owners to bring their sites into compliance with local state and federal laws. Since 2017, there has been significant growth in the number of federally-filled website accessibility cases nearly doubling every year.

Recent examples include the Supreme Court ruling that the Domino’s website and mobile-app must be screen-reading capable, which supported a lower court ruling in the case known as Domino’s Pizza v. Guillermo Robles, No. 18-1539. Further examples include federal district court cases in Florida and New York which ruled that websites failing to meet Web Content Accessibility Guidelines (WCAG) guidelines are violating Title III of the ADA code.

It’s unfortunate that it takes legal action to encourage website owners to be more accessible, but I felt it best to include this section to drive home the significance of applying good accessibility practices. I’m not a lawyer and make no attempts to say that by applying the following steps in this article you will have done enough to avoid legal action. It is simply my hope this will better prepare you to take your first steps to make the your WordPress site and the web more accessible to others. For more information, I would highly recommend looking up additional details about section 508 and Title III of ADA guidelines and how they apply to private organizations.

Use Accessibility Tools to Make Your WordPress Site More Accessible?

Before we begin making any changes to our website, it helps to get an understanding of how it currently stands in regards to accessibility. A great first place to start is using the free Accessibility Insights tool developed Microsoft. Using Accessibility Insights tool in our case the chrome extension we can run their FastPass test to see quick things we can fix in our site.

Note: The Accessibility Insights tool will identify a lot of elements that can be potentially wrong with your site from color contrast, images missing alternative text, forms missing labels, and so much more. With all the issues it might identify for your domain, it can be easy to become overwhelmed by the results. It’s always best to make changes to your website in phases. There is nothing wrong with taking it slow.  Now that we are aware of some issues with our website, we can begin applying our first steps to making our WordPress site more accessible.

Alternative Accessibility UI Tool: Wave Accessibility Tool

First Steps to an Accessible Website

1. High Contrast Colors

When designing elements for your website, such as graphics, menu links, and buttons, ensure that the colors combined in your design have high enough contrast in order to be visible. In order to be WCAG 2 AA compliant, there must be at least a contrast of 4.5:1 between your color choices. It’s okay if you don’t know how to choose the proper contrast. There are great online tools such as Monsido Color Contrast Checker that allows you to combine color combinations online and see their calculated contrast differences.

The following are examples showing how by simply changing at least one color in a combination, we can enhance the visibility of our elements.

2. Use ALT Text

When using images anywhere in your blog, you should always ensure that there is alternative (ALT) text included with the image. ALT text refers to the invisible description of images that are read aloud to visually impaired users with the assistance of screen readers. Adding ALT text allows you to include images, while still providing the content of the image in an alternative text-based format.

It’s not important to just provide ALT text; it must be useful within the context of the content. You do not have to describe every detail of the image, and you are able to skip over purely decorative images, but images containing crucial information need to have ALT text used. An easy way to come up with descriptions is to think about how you would relay the information over the phone.

For example consider a graphic at an online store that states which credit cards are accepted. What is the more appropriate ALT text?

1. ALT=”Credit Card Logos” (Which credit cards?)

2. ALT=”MasterCard, Visa, American Express, and Discover accepted.” (This specifies which credit cards.)

Get more information about ALT Text from Penn State.

3. Use Headings Properly

H1, H2, H3, H4, H5, H6… oh, my.

Headings can be tricky when making your WordPress site more accessible. Naturally, if you’re like me, your default habit when publishing a blog post is to probably use headings to format your posts and documents to be easier to read.

The purpose of headings are really to serve as an outline or skeleton of the page’s content. Although sighted readers can easily identify headings by visually scanning pages for larger text, visually impaired readers rely on screen reading software and are unable to see these visual cues. So, increasing the font size won’t assist. It is important that you nest your heading elements properly in a semantic-based approach, not how they look visually.

Note: If the visual style of how headings look is preventing you from using them properly for the page’s content, you can always update them for sighted readers with simple modifications with CSS. Or, if you are using a page builder tools, often you can increase the size of text regardless of what header type was selected.

Video Resource: Why headings and landmarks are so important — A11ycasts #18

4. Using Proper Links

When you are including text within an article, it’s important to help users understand the destination of where the link is taking them. A good rule of thumb is to write links that still make sense out of context using descriptive title text about what the content is, not “click here” or “read more.”

The following are bad examples of links in the text:

• Click here to see examples of our previous work.
• For a full list of our services, or to see a list of all our published books, click here or here.

The following shows the same links in a more usable form:

• Examples of our work are available on our website.
• Learn more about our services or check out all our published books.

Additional Tips for Good Links

1. Make sure that text links are (not a link) underlined and in a different color than the rest of the page’s content to help colorblind users find links easier.
2. Avoid links opening up a new window or tab if you are able to. New windows have a different window history disabling the Back button for users and the new windows are harder for those with screen readers to navigate to.
3. When using an image to serve as a link make sure to include the link in the ALT tag.

5. Use Plugins to Enhance Accessibility

Finally, once you have fixed all your images, headings, and links you might consider checking out adding One Click Accessibility Plugin to your WordPress site. While installing this plugin won’t replace good content writing habits, in just a few seconds you can provide your readers with an easy-to-use tool to self-service your site’s content in a way that is best for them.

Features Included

• Resize font (increase/decrease)
• Grayscale
• Negative Contrast
• High Contrast
• Light Background
• Links Underline
• Readable Font
• Link to Sitemap / Feedback / Help pages
• Enable skip to content
• Add outline focus for focusable elements
• Remove the target attribute from links
• Add landmark roles to all links
• Customizer for style adjustment

Not the End

That’s it. That’s all I got!

I hope you found this post informative and hopefully you learned a thing or two on how to make your WordPress site more accessible for others. This post was never intended to be comprehensive instead focusing on simple features that you can apply immediately to your posts and pages. Don’t stop here and remember to continue your learning. An accessible website is not a race; it’s a marathon. Start slowly and improve as you go. If you have any questions, feel free to ask below and I’ll try to do my best to respond.

Additional Resources and References

• Accessibility.io
• WordPress Accessibility Guidelines
• How Thinking About Accessibility Can Lead to Success
• 4 Ways to Make Your WordPress Site More Accessible
• When Good Sites Go Bad: The Growing Risk of Website Accessibility Litigation
• Video: Accessibility Tools & Resources for WordPress
• Accessibility Department of Penn State <— This was one of my personal favorites.

The post 5 Ways to Make Your WordPress Site More Accessible appeared first on WebDevStudios.

Since then, WebDevStudios has kept that promise. When we ship a website to a client, it passes all sorts of accessibility tests, as well as HTML and CSS validation. When a potential client asks us to provide examples of accessible websites that we have built, it’s easy to oblige. More often than not, that leads to a sale.

While impressing clients and acquiring a new project are good reasons to build an accessible website, the reality is that over 285 million people worldwide have visual impairments… which is almost the population of the United States! Thinking about accessibility is just the right thing to do.

Four Basic Principles

Make no mistake, accessibility is hard. So where should you start? To keep from getting overwhelmed, take a cue from Foundation by Zurb and follow four basic principles:

1) Structure your document properly

Modern web browsers can do a lot of the heavy lifting… if you write semantic HTML.

1. Use <button> instead of making <a>, <div> and <spans> look like buttons.
2. Use headings <h1> – <h6> to help provide both structure and context to screen readers.
3. Steer clear of “enhanced” form field plugins. Ask yourself, “Is it really worth having a pretty dropdown, when it is completely unusable by 285 million people?”
4. Use WAI-ARIA to help provide additional semantics to describe role, state, and properties.
5. Read more about “How Writing Semantic HTML Can Help Accessibility” by Jeffrey de Wit.

2) <label> everything

For 285 million people, a screen reader is the only way to “view” a website. When it’s read back to them… does your website makes sense?

1. Make sure form fields have a <label>. It is OK to hide labels with CSS: <label class="sr-only">
2. Using <fieldset> and <legend> to group related form elements.
3. Provide descriptive alt attributes on images: <img alt="A hen Mallard landing on a pond"> vs <img alt="mallard_duck-1.jpg">
4. Read more about “Labeling Controls” from w3.org.

3) Don’t rely on purely visual cues

If a page is being read to a user by a screen reader, it may not be obvious what the user is supposed to do next.

1. Make sure call to actions have labels that can be read by a screen reader.
2. Do call to actions meet a minimum contrast ratio? Meaning, can this person actually see/read it? Make sure the contrast ratio (on everything from text to buttons) is at least 1:4.5 for normal text and 3:1 for headings.

4) Make everything usable on a keyboard, mouse, and touch screen

1. Make sure you can use the tab, spacebar, and arrow keys to navigate a web page.
2. Give users the option to skip around a page.
3. Complex components such as sliders or modals should be tested with arrow and esc keys.

Tools Can Help

These accessibility testing tools can help, by pointing out areas of your web page that need work.

• Tenon.io – Will check your website against Section 508 and WCAG 2.0, and provide recommended fixes.
• WAVE – Similarly, WAVE can test your website against accessibility standards and even display contrast issues.
• Total Validator – Available for Windows and MacOS, this tool can test entire websites against a wide range of validation tests.

Conclusion

By thinking about and ultimately acting on these principles during the entire life cycle of a project, from scoping to design, development, and QA, not only will you be making your website usable by those with disabilities, you will be doing the right thing. This will come with many other benefits including: long-term maintainable code, SEO juice, and that feeling deep down when you do something nice for someone else. In my book, it doesn’t get more successful than that.

Further Reading

• MDN – Learning accessibility
• WebAIM – Training, assistance, certification, and testing
• WordPress Accessibility Code Standards – The WordPress A11y Team
• Accessibility APIs – A key to web accessibility

The post How Thinking About Accessibility Can Lead to Success appeared first on WebDevStudios.

A majority of a site’s visitors will be able to use their sight to help them understand what things are and what they might do. For them, it’s largely irrelevant that the thing that looks like a button isn’t built with a <button> element. As long as it functions in a way that matches their goals and expectations, they will be happy (maybe even delighted if it does exceptionally well).

But what if you couldn’t see the page for yourself and you need assistive technology to help you? Suddenly, all the inherent semantic information that HTML elements carry becomes infinitely more relevant.

This post will describe three examples where semantics matter and how they may influence a user’s experience on the website.

Anchors, and buttons, and spans, oh my.

It’s entirely possible to add a span or a div to a page, slap some CSS and JS on it, and call it a button. Maybe you’d do it because it’s “easier” to make it look like the design that way. Or, maybe you have a different reason for doing this. However, you’d only be doing yourself a disservice by reinventing the wheel and making a bunch of extra work for yourself.

You see, it may look like a button. It may even act like a button when you click it. What it most likely won’t do is get added to the page’s list of focusable elements. This means that people navigating your site with a keyboard will never be able to reach it, let alone interact with it.

And, I can almost guarantee that it won’t identify as a button either. This is an important detail to those that use assistive technologies to tell them what something is. If I don’t even know it’s a button, then how can I be expected to know that I can interact with it?

Both of these shortcomings can be fixed to some extent, but why would you? The browser will take care of all of these things for you when you use the appropriate element, and it will do that much better than you can emulate them. As a bonus, you’ll be supporting older browsers without even trying!

In addition, both the anchor and button element have a number of additional attributes that are simply not valid to use with a div or a span – attributes with which you can give more information, or with which you can instruct the browser how to handle it.

For example, if I were to add the download attribute to a link, I can basically tell your browser to download the file I’m linking to instead of trying to open it. I can also add more information about the page I’m linking to through attributes like rel or hreflang.

Or, you can use the disabled attribute on a button element, which will allow you to easily disable it completely. A button that is disabled this way cannot get focus anymore, nor can it be activated anymore. For all intents and purposes, it does not exist anymore. Simply removing this state attribute will completely restore the button’s function again.

The subtle difference between anchors and buttons

A more common occurrence is anchor tags acting like buttons. While this isn’t necessarily as bad, you’d still be using an element whose primary function is relating documents (or sections of the same document) together to do something it wasn’t meant to do.

So how can you easily recognize when to use an anchor and when to use a button? If you are using a valid href attribute to link to a different page, or to a different section on the same page, then go right ahead and use an <a> tag.

Otherwise, every time you find yourself writing a toggle that is along the lines of one of the following, you may want to consider using a <button> instead:

<a href="#" id="click-this">Click Me, I do stuff</a>

<a href="javascript:toggleStuff();">No, click me. I do stuff too!</a>

Always remember, someone using a screen reader doesn’t really care what the thing looks like. All they will know is what their screen reader tells them about the thing, and that will come down to two simple words that carry a lot of implied meaning: “link” or “button.”

Headings, more than just text size

The headings (<h1>–<h6>) in your document provide for more than simply a way to increase the size of the text. It’s true that, visually, headings will stand out in most cases and do their job that way.

But remember, not everyone will be able to see your page. Headings have the added benefit of making an outline of your document available. They allow you to give a good overview of what the page is going to be about. Additionally, most screen readers allow their users to jump through the page from heading to heading. In this specific situation, your heading is now without any context and needs to convey what the section is going to be about by itself. And so, those sentences that are marked up with different heading levels become meaningless fractures.

For a good illustration of how navigating a page with headings works, have a look at this video:

Form elements

Forms, too, benefit from being structured semantically. Just like spans that were turned into buttons, your users will also stop liking you if you do not use form fields appropriately.

And like anchors and buttons, each form element (and especially more complicated ones, such as select boxes) come with inherent functionality based on the browser’s implementation. To stay on the select box example, this element lets you select an option with the arrow keys but will also allow you to select an option through typing. That is to say, typing “united s” in a list of countries will select “United States of America” for you. Screen readers will also read out every option as you navigate through the list with the arrow keys.

With all this in mind, it’s all the more heartbreaking to see form widgets that are aimed to replace these native elements for something that looks nicer or that has more functionality and do a poor job at it. It is really easy to forget about all the other things that these elements do for your users. And at the same time, it can be really complicated to get it to work well, too.

To illustrate, I’ve prepared a video straight from the demo page for one of these libraries that “enhances” form elements (it is irrelevant which one it is, really). It demonstrates how a regular select box element works in Chrome with NVDA running. As you’d expect, it reads out the options properly. The “enhanced” version, on the other hand, continuously reads out “blank,” at least until I try and filter the list by typing some letters, because then it starts repeating what I’ve typed instead.

But my feature needs some control that doesn’t even exist!

By now I can hear you think: “That’s great and all, but my needs surpass what native elements can provide.”

Awesome! By all means, use whatever elements you think are appropriate for your cool feature. But, don’t forget that you’re now responsible for making it accessible, too.

So, make sure you have a clear vision of the following:

• What goal does it have and how does it do that better than other options?
• How should it operate with a mouse?
• How should it operate with a keyboard?
• How does it manage focus states (which is especially important for more complicated widgets, like calendars, for example)?
• What kind of feedback should it give the user?
• And finally, what does it actually do when a user decides to use it?

And then make sure to read into WAI-ARIA, because this is exactly what a use-case WAI-ARIA is for.

Further Reading

• Wikipedia article: Principle of least astonishment
• WAI-ARIA overview on w3.org
• Name, Role, Value: Understanding WCAG success criterion 4.1.2

The post Accessibility of Semantics: How Writing Semantic HTML Can Help Accessibility appeared first on WebDevStudios.

Accessibility is so broad and the usership is so diverse. When building a WordPress theme, I encourage you to think about the benefits of removing any potential barriers from someone being able to access information. (Yay usability and inclusion!) As a reminder, the WordPress Accessibility Handbook is an excellent resource, which outlines minimum requirements you’ll need to meet in order to make your theme “accessibility-ready”.

There are several tools and resources out there that can assist in this process. Since my default browser is Chrome, I’d like to dive a bit deeper into how you can use Accessibility Developer Tools (a free extension from Google) to help out.

Note: “Accessibility” is often referred to as “a11y” and will be used interchangeably throughout this overview.

Running an a11y Audit:

So, you’ve started to develop your WordPress theme and you want to check on how things are shaping up on the a11y side of things.

Once installed, you will want to select the “Audits” tab. In addition to the usual “Web Page Performance” and “Network Utilization”, there is now also an “Accessibility” option listed. By checking that option and running an audit (either for present state or on page reload, depending on preference), it will return a basic report from the current site.

The audit will (potentially) return a list from severe to passing of accessibility errors it calculated within your code. What is helpful about this is that it will show you the actual node in the DOM where this issue is taking place. It provides a link to the DevTools a11y wiki that relates to that issue, which in turn links you to the relevant area of the w3 spec.

So much of accessibility documentation can seem quite dense and overwhelming. I know that for me, this really helps to break it down and give me a better idea of what should be happening within my code AND how to fix it.

Debugging Existing accessibility:

What if you’re trying to debug issues that have already been implemented that aren’t translating properly into actual functionality? Follow me once more to a magical place called “Accessibility Properties” that lives within your DevTools in the Elements panel. Just a note, depending on how your DevTools is laid out, it could be listed under the right-pointing double angle quotation mark ».

Depending on which element you have selected, it will provide a list of properties that can help in validating ARIA roles/attributes and debugging colour issues, focus/visibility roles and text computation.

Focus and Visibility

This will list what is happening with tabindex and visibility. This is great to have consolidated in one place to double check properties. I’ve found it to be most helpful with elements like modals where something is focusable but behind other content and needs adjusting. Focus and visibility are two examples of things to be conscious when developing so people are able to navigate via keyboard. Again, remember to double check these and other WordPress standards as you’re developing your theme!

Colour Contrast

This will show you the current contrast ratio of your element. You will also see a suggested colour value pair to match the WCAG AA or AAA recommendation. WordPress aims to to maintain contrast at the WCAG AA level, which means a ratio of 4.5:1 for normal text and 3:1 for large text. And if you want to see what that would hypothetically look like, you can toggle to test it by clicking on the square icon to the right of the hex values.

Keep in mind that this also applies to a change of state (:focus or :hover) is there is no additional indicator like a text decoration change. Ideally, you’ll have worked out these things in the design phase but sometimes buttons or other smaller elements might fall under the radar. If you want to play with different shades, there are several contract checkers online (for example, here’s one by WebAIM).

ARIA Role and Attribute Validation

ARIA roles and attributes help screen readers understand the purpose of various sections of a web page by assigning certain regions. Certain landmarks should only be applied once per page.

Similar to what we see with styling properties, if it is invalid somehow or being overwritten, it will be struck out when inspected. This is useful to narrow down whether it’s a browser bug, a screenreader bug, or if the markup is just plain ol’ incorrect (as seen in the instance below for the aria-describedby attribute).

In my journey of learning more about accessibility, debugging has helped solidify how different components interact with attributes, which allows me to read up more and then use them more effectively in the future.

If you weren’t already familiar with these accessibility add-ons in Chrome, welcome to a whole new world! And if you were, is there anything I missed that is a total gem?

The post Accessibility in Chrome DevTools appeared first on WebDevStudios.

Here, I’ll discuss some of those, as well as why we all need to become more mindful of the web in which we are working and the web for which we are building our sites, so that they can be used by all people regardless of their capabilities. Let’s start at the very beginning. What is web accessibility? W3C defines web accessibility as such:

Web accessibility means that people with disabilities can use the Web. More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Web accessibility also benefits others, including older people with changing abilities due to aging.
– Introduction to Web Accessibility

This makes sense, right? We don’t want to limit the information on the web due to conditions beyond a person’s control. Instead, we should be ensuring that information is not only available and accessible to those with disabilities, but also presented seamlessly to those without disabilities. In essence, web accessibility should be invisible.

This, and the other passages in the book, resonated with me quite a bit. It helped to take me from a place of, “We need to make sure we check to make sure the site is accessible,” to, “We need to set higher accessibility standards in our framework.”

Too often, I think, accessibility does become an afterthought because those of us who are building a site may not have any personal experience with a disability or condition which precludes us from using the site to its full potential. For this reason, it is easy for accessibility to become an “out of sight, out of mind” (for lack of a better phrase) issue. That, combined with just assuming that the website will magically be accessible to all users, is where we as developers find our pitfalls.

We can’t just assume that because a website looks good to and works well for us and the client that it is a flawless masterpiece, which works for all users. More often than not, this will likely not be the case. Perhaps we haven’t checked our color contrast levels, and there are some questionable light fonts on light backgrounds. Maybe some of the triggers on the site which should be buttons are actually spans or divs styled in such a way to act as buttons. It could even be as surface-level as heading tags not being used properly throughout a document, creating a confusing experience for a screen reader.

Whatever the case may be, these are all more than cases of code cleanup or QA. These are perfect cases for changing the way we look at the web, the way we think of the web, and the way we build the web.

Think about it like this: you are building a website for a service which, primarily, will be used by an audience who is very in-tune with the design and functionality trends of the day. You want a sleek design with sharp, modern fonts, which aren’t too in-your-face in regards to size and weight. Generally speaking, larger font sizes are associated with users who have a harder time reading smaller fonts. In fact, Barnes & Noble offer over 60,000 large print books to serve an audience who may have trouble reading the smaller print found in a standard book.

Ask yourself, if you are someone who doesn’t require a large print book to read comfortably, are you hindered in any way if you are, in fact, presented with a large print version of a novel, rather than a standard print version?

No, absolutely not.

Your experience is absolutely the same. You are reading the same words in the same language. The only difference is the size of the font being used.

This is the balance we need to strike with web accessibility. Should you design your site with smaller font sizes which sit on backgrounds whose contrast points are extremely low for the sole purpose of achieving a certain look or aesthetic? Or, could you take a few extra moments in the beginning of your design process to ensure that what you are designing is going to be large enough and displayed with enough color contrast to be easily read by all of your potential users?

In one of the above scenarios, you are limiting the number of users who can comfortably use your site. In the other, you aren’t placing limits on who can use your site. Or, at least, you are trying to ensure your site is presented without limitations to all users.

For me, beginning the journey into learning more about accessibility has been an interesting one, and one which is changing the way I look at, interpret, and develop. Accessibility does not, and should not, mean presenting a lower-quality or different experience to users due to a disability or condition. Instead, it should be that all users, regardless of their backgrounds or abilities, are able to experience the same content on the same web inclusively.

The post Thinking About Accessibility appeared first on WebDevStudios.

1. How can I break this?
2. Where’s Murphy hiding?
3. Who do I trust?
4. What’s dangerous?
5. What are the real limits?
6. Who is this for?

For example, what could go wrong with this example?

<?php _e( 'What could go wrong here?' ); ?>

Well, it turns out, a lot.

Have you ever tried breaking this by adding malicious scripts in language file? Turns out an innocent function, like this, opens a huge opportunity for people to break things. This was my own revelation a few weeks ago, and it dawned on me that I do not spend enough time trying to break things and learning the skills I need to detect these hidden opportunities in my code. The first step was simply realizing that with every new feature, comes new opportunities, but the following are a few steps I’ve been taking before I complete and turn in any new feature.

How can I break this? (Go break it)

During the drudge of daily tasks and code commits, we often can overlook the need to go in and actually break things we build. The definition of hacking isn’t necessarily malicious; it’s simply taking something and re-purposing it for a different reward. MacGyver was famous for this kind of hacking! That said, hacking is commonly used to break things, and that’s what we’re looking to fix, which is why we should try to break our own stuff.

It takes more than just trusting functions and methods to get the job done. You have to actually get in there and try and break what it is you just made. I feel we aren’t encouraged enough to go in there (and especially spend the time) and be a hacker. But I call all developers out! Become a hacker daily! Break your stuff! In doing so, you are going to build better products, serve your clients better, increase the reliability of your company, and, ultimately, become a better developer.

I also encourage CEOs, business owners, leads, and project managers to change the rhetoric behind security to go beyond just coding, but making the actual act of hacking your own solutions a part of the development process. Tell your developers to ask themselves, before turning in a task or pull request, “How can I break this?” And give developers permission to take the time to become a hacker.

Where’s Murphy hiding?

Anything that can go wrong, will go wrong. – Murphy’s Law

So we’re trying to hack our new feature, and we find a way that a user can pass a combination of query arguments, and somehow, logged in as a subscriber, could possibly run a server-intensive script we just built over and over. I feel (admittedly, through my own experience) we tell ourselves too much that they would never figure out how to do that, and we move on. But someone will!

I’ve just created a problem that will happen in the future. Thinking of these findings as problems that will undoubtedly happen, no matter how unlikely we think it is, will help us keep the internet and clients safe. It allows us to strategize.

Who do I trust?

Developers can be too trusting, and we shouldn’t be. Never trust anyone.

<?php _e( 'What could go wrong here?' ); ?>

In our example here, we might admit that the only one who could really cause a problem are the people who translate. Maybe they’re our own people, maybe they’re strangers, or maybe they’re future translators that a client hired six months down the road that know nothing about WordPress. Whoever it is, I say, they automatically get the “I don’t trust you” stamp of non-approval. It’s strange, but developers have to live in a very untrustworthy world, and we’re better developers for it! Having an skeptical approach will lead you to creating more secure code and features. Take your paranoia and make something rock solid.

What’s dangerous?

In the spirit of Murphy’s Law and trusting no one, you have to see information itself as a potential transmitters for viruses, illnesses, and things that cause bad things to happen and blow up the Internet. Data and information are dangerous! By shifting your view of information to something dangerous, and hiding some disease inside, we can be better devs.

An example.

$image = get_the_post_thumbnail();
echo $image;

In this example, we might view $image as completely innocent and trustworthy.

But it’s not.

Did you know that get_the_post_thumbnail() has a filter? Yeah, it’s post_thumbnail_html and anyone can filter the output and push out a harmful script! $image is dangerous; variables are dangerous! How do you know someone with server access didn’t inject a Must-Use plugin that filters that output?

If we put on our Hat Of Mistrust, we’ll be aware that leaving that variable alone is risky, and take action:

$image = get_the_post_thumbnail();
echo wp_kses_post( $image );

This should allow img tags that are allowed in the WordPress post editor, and if anyone tries to inject a harmful script, it won’t let them. We need to start seeing information as potentially dangerous, and ask ourselves if it is, because we don’t know all the filters or ways people can turn information against us. Using critical thinking and strategy in the ways we work helps us stay one step ahead of people who either don’t know or possess malintent.

If we were really paranoid, we might write something like:

$image = get_the_post_thumbnail();
echo ( is_string( $image ) && stristr( $image, '<img' ) ) ? wp_kses_post( $image ) : '';

What are the real limits?

Another question I think developers rarely ask themselves are, “What are the real limits?”

Really thinking about this question can produce interesting answers.

For instance, what is the limit of get_posts? At first, you might think, well -1 (I did). Set that posts_per_page to -1 and we’ll get all the things, yeah baby! But, a smarter developer might find that…

• The server’s execution time is a limit
• The server’s memory is a limit
• 15, the limit is 15; there will always be 15

We should be thinking about real limits, not just limits in code, and what happens when these limits are reached. Like the server’s execution time or memory limits resulting in a 503. Or, getting fifteen posts–no harm there, right? Have you ever asked yourself how many posts_per_page actually result in a timeout or a 503 on your server? It’s a good question.

Our job as developers is to eliminate the harmful effects of reaching real limits and we need to be aware of what these limits are and make sure we’re not breaking them.

Who is this for?

The last question I pose developers to ask is,

“Who is this for?”

I think every feature should have a name associated with it. Is it all administrators, or all authors? Is it just Jane or Joe? Is it the United States? Are they English speakers or Spanish speakers? Who are these people!?

Knowing (or even guessing at) who will be using our features, by giving our features ownership, helps make sure we’re prepared to create features with privilege in mind.

Even if your answer is “everyone,” we probably should be looking hard at the detailed, real time answers. For instance, “everyone” includes many languages; how many Spanish speakers need to use your product? Do you have a plan to have your content translated? What about A11y? That includes everyone too! Thinking of your features as privileged and belonging to someone helps us take more responsibility with our features, who has access, and who shouldn’t. This also allows you expand your reach and make sure that people who might otherwise be excluded in a generic “everyone” can access what you made.

What about you?

Do you have any tactics that help you build more secure features? What are some ways you work secure features into your build?

The post The Six Questions Developers Need to Ask Before Turning in Tasks appeared first on WebDevStudios.

Today, I took a step back and decided to look through my notebook (yes, an actual notebook with paper and ink on it) and pull together a bunch of sites I’d come across in the last couple months that I thought were particularly interesting. These are the ones I found myself actually going back to check out (as opposed to those bookmarks that sometimes fall into the abyss).

Hiding Things with CSS

It’s hard as a front end dev not to constantly scope all the amazing things CSS-tricks has to offer, but sometimes I forget to check out the videos section. They’re obviously much more content and production heavy so they’re not nearly as frequent as the written post content. I found this one particularly on hiding things with CSS interesting because more often than not using display:none is my go-to when I need to hide something from the screen. However, it’s not always the best way to go about it (I’m fully aware), especially when it comes to assistive technology like screen readers for example.

I found this to be an informative and useful alternative for doing things better when it comes to showing and hiding certain content. There is a time and place for display:none, for sure, but not always. Chris Coyier details it all out in this video. Using opacity in combination with visibility is a useful alternative solution for hiding/showing elements, but as always, it depends on exactly what it is you’re trying to accomplish. Definitely worth checking out the video, as well as other articles mentioned in it.

Introducing the U.S. Web Design Standards

At the end of this past September, 18F and the U.S. Digital Service (USDS) released their collaborative effort the U.S. Web Design Standards. It’s a really well done site with lots of really good information. It will serve to help to keep things more consistent across the board, as well as reduce and simplify overly complex situations.

Again, this is a great resource because their are so many parts to account for when building a site and having something like this resource to reference for your own projects and team projects helps serve as both a guide and checklist to make sure you’re including all the important elements and techniques into any website, including accessibility items. I also really like the recommendations outlined here for choosing a front end framework (but that’s a discussion for next time!).

For more information (and to look through all the code!), check out the below to see it all in action:

• https://playbook.cio.gov/designstandards/getting-started/
• https://playbook.cio.gov/designstandards/

Bourbon, Neat, and Bitters

Last year when we began incorporating Bourbon/Neat into our wd_s theme, I wrote a getting up and running Bourbon Neat. While certainly still relevant, I stumbled upon this guide from the team over at Git-Tower that has a Bourbon, Neat, and Bitters tutorial. It’s pretty thorough and hands on, and it’san awesome refresher for seasoned developers. It’s also straightforward and easy to follow along for beginner devs as well.

If videos are more your style for learning or if you’d like an additional resource to accompany the one from Git-Tower, definitely checkout this YouTube playlist/code course by PHPAcademy where they go in depth and discuss a number of features. While it’s from last year, it’s still very relevant and worth checking out. It’s a six part series and only takes about forty-five minutes from beginning to end.

Using and Caching 3rd Party JSON with WordPress

This may not sound like a front end resource for some front-end developers, and depending on how you/your team works it may not be something you interact with often. That said, I’m always trying to push myself to learn more and get outside my comfort zone; it’s always frustrating when you get stuck, but when you see the light at the end of the tunnel it’s always rewarding and a cool feeling.

I thought this was a really good tutorial for getting started–at least for front-end developers who may not have come across this particular resource or haven’t interacted much with JSON in their day to day workflow. The video isn’t terribly long, but definitely worth a look:

What The FlexBox

I know I’ve added a lot of resources, tips, and tricks related to the Bourbon/Neat suite, so I wanted to mention one last item that I hope you find interesting and useful. As the web continues to evolve and supporting older browsers becomes less of a difficult task, I thought I’d mention this video series by Wes Bos and Flexbox. It’s twenty videos in all and a good primer for Flexbox–check it out.

Flexbox is already available as a mixin in Bourbon and there is some discussion about introducing it into Neat at some point as noted here. It will certainly be interesting to see what happens down the road.

Hopefully you’ve found one or more of these great resources already–or if you hadn’t, I hope you found them useful. This obviously isn’t a comprehensive list–just a few recent things I came across that I found myself going back to a few times (or more accurately, ones I’ve written down and not completely forgotten). I’m sure there are other great ones–if you have some to share, feel free to drop them in the comments!

The post Front-End Dev Resources, Tips, & Tricks You May Have Missed appeared first on WebDevStudios.