The thing about Web Development is…

It is always changing. This is good but sometimes it can be a bit overwhelming. For example, ever since ES6 came out and the industry started moving more and more toward using the new specifications. I have started feeling like I don’t know javascript.

I have been writing in javascript for about five years now. The vast majority of it was in jQuery. Some of it has been with front end frameworks like Vue.js and Angular. I worked for about 6 months with meteor.js and node.js at my first development job. I can still drop some jQuery like no body’s business. I have built whole component libraries using jQuery, Scss, and HTML that are fully accessible and easy to implement. Yet when I see code that uses destructuring in complex ways, I am like ‘what the heck is that?’

It is javascript – the new javascript. There are quite a few parts that take some getting used to.

Arrow functions are another example. They are easy to understand and simple to implement. The syntax is simple and straight forward. But I could easily and quickly read and understand code that nested functions before that arrow came along. Now, I frequently see things that I have to take a moment to translate. Here is a fun, and simple example from the MDN docs:


setTimeout( () => {
console.log('I happen sooner');
setTimeout( () => {
// deeper code
console.log('I happen later');
}, 1);
}, 1);


This one is nice because it is fairly obvious what it does. But imagine if it wasn’t so obvious. I didn’t realize how much the word ‘function’ was serving as a visual queue for me until it started disappearing.

When you are learning, arrow functions are simple and straightforward. The syntax is a clear improvement for a simple function.

 

//New version
const cubeThis1 = (a) => a**3;


cubeThis1(3);
// 27


//old version
const cubeThis2 = function (a) {
return a**3;
}


cubeThis2(3);
// 27


When you are working with someone else’s code, they haven’t named their functions and variables so well, and the functions are not so simple, then you might find yourself stopping to translate. Every now and then I rewrite the code in comments or in my own notes with the explicit ‘function’ syntax to make sure I understand what is going on. The implicit ‘return’ of the arrow function throws me off sometimes.

Destructuring can also get very confusing very fast, especially if the writer of the code does not adhere to clean coding principles. The syntax feels backwards to me like I learned to write “The fox will run” and now I am being asked to write “Run the fox will.”

So I am practicing writing code far more than I used too, or than I previously felt was necessary. I have returned to some of the code kata’s and code challenges that I used as a new developer to try those same exercises in ES6. I sometimes refactor my code with more ES6 syntax to see if improvements can be made, and I always think about how my code communicates with other developers.

In spite of all this, I still frequently feel like I don’t know the language well, or rather that I know it less well than I did just a few years ago. It is the programming language that I am primarily writing in, and have plenty of experience with.

But then, in my career I have also had to learn PHP, Python, Ruby, mongo, SQL, HTML, CSS/SCSS, and a half dozen frameworks with their own syntax. And that list could go on because there are the API’s you work with, the libraries, the modules, the automation tools, the testing tools, and the browser dev tools which are perpetually getting new updates. Somehow, the ground is always shifting in web development.

It is so easy to feel like somehow you are back at square one, in spite of the 5 years or more that you have been climbing the web development mountain range. I feel that way. The other day I wrote some code for a small expanding panel with all the needed aria-attributes for screen reader friendliness, for another developer. I knocked it out in a matter of minutes, and then refactored it in another 10. That is when I found myself thinking – “Oh yeah. I do know how to write javascript.”

New syntaxes, and the complexity of incorporating new skills into your existing methods can feel awkward and fill you with doubt. This is a note for my future self the next time I am learning the big new thing that scrambles the syntaxes that I am comfortable with: You are not alone, and you don’t suck at this, so keep moving forward. 

Advertisements

How Web Developers Feel About Print Designers Venturing into ‘Web Stuff’

Save Us From the Print Designers

Imagine you are a design agency who has been making amazing, trendy print and marketing designs for years. You can knock out a well crafted logo, billboard, or brochure with an exquisite awareness of the market you are targeting, and the needs of your client in a matter of weeks. Your clients love your work and they return to you again and again for every pixel perfect brochure and poster.

Then one day they ask you to take charge of their new website design. Why not? You already understand digital branding and social media strategies, so why not take the plunge into this fertile uncharted territory?

Wait. Hold up. Please. I just need a few minutes of your time, for the sake of my sanity and the sanity of web developers everywhere.

Should you take that plunge? YES, of course you should, but not without the very clear awareness that web design is drastically different from anything you have ever done. You just left the world of static pixels, perfectly positioned letters, and layouts that always stay rigidly the same. You are walking into an interactive medium, a multi-device/screen width medium, and a multi-user medium.

You are no longer working in a space where you can assume you have one kind of end user, one size of canvas, or static images that simply hang out on a static screen. You may have to consider how the content of the site will change over time, how easy your design will be to manage and update, and you will have to know a thing or two about web accessibility.

You will also want to know if users actually interact with the the interactive elements of your site, and what to do if that amazing carousel you designed turns out to be a complete dud at actually marketing anything.

Still want to move ahead? Good. The web is a powerful medium and as a digital design firm, you should want to be a part of it. But it is incredibly important that you know what you are getting into. You might also want to know why you are getting that weird look from your developers when you surprise them with the fact that you don’t know what a hover state is. But maybe I can help with that.

So here is a non-exhaustive list of things you should know if you want to design for the web, and also a few things that will keep you from driving your developers crazy.

You are Designing Something that Other Humans will Interact with

This is so basic that it is hard to know where to start. You are no longer designing just to catch someone’s eye, make your audience feel a certain way, or to make a product or company seem more friendly. You are now designing elements that you want users to recognize as interactive, and then proceed to interact with those elements. So buttons need to look like something a user might want to tap on or press. Somehow you have to indicate to your users that this is an interactive element. The same goes for links.

There are plenty of well established design patterns for this. Menu icons, button styles, and even standardized link styles will help in conveying that information to your users, but you also need to give some feedback that an interaction is occurring or that it has been successful. This is where hover states, active states, and focus states come in. You will frustrate your users if you give them buttons and links that don’t respond with they interact with them.

Interactivity is about responding to user input. Learn about the different states that you might add to a button, and don’t go crazy designing these states. Less is more when it comes to button and link effects, especially if you have quite a few of these on your website.

Content and navigation have to play well together

So now that you have realized that something needs to happen when your user presses that menu button, have you thought about content?

Let me guess. The client is providing their own content? That’s great, but I bet you are designing their navigation, and that navigation needs to have some relationship to the content… right?

So you are going to spend some time working with your client’s proposed site map. This is where your digital marketing prowess will come in handy, because you are going to tell them that submenus inside of submenus inside of submenus might not be a great idea, or that top level menu items probably need to be short and sweet and definitely under three words long.

You are going to realize when you start mocking up these menus based off of the site map, that their site map is implying some things that might not work so well. So have an idea of how you want to guide them.

If you think simpler menus are better for their design, then that main navigation might need to be slimmed down, and remember that the menu is generally for the end user not your client. It may look cool to have images, videos, and multiple columns of menu items in your dropdown menus but that may not actually be the best design choice for the site. Think about what your end users are actually going to look at and click on.

Welcome to the Mobile Web

Speaking of which, now is a good time to think about how that giant menu is going to work on mobile devices if you haven’t already. You can start with mobile rather than desktop, some designers really like to start with mobile, but you don’t have to. Just remember that on mobile most of those ‘click’s’ will turn into a ‘touch’ or ‘tap.’ ‘Hover’ isn’t a thing, and ‘swipe’ decidedly is.

Design with touch interactions in mind. All of those mobile menu icons and buttons are big enough for an adult human finger to touch them without touching other links or buttons at the same time, right?

You are also carefully designing with super small screen real estate in mind for all of those tiny iPhone 5 screens that are still out there.

I’m sure that you have already done a little bit of market research and figured out the range of devices that you would like your design to fare well on, and maybe even negotiated a little with your client on the edge of those ranges.

Hopefully, you have also talked to your developers about what they think is reasonable to support. Your clients will want to support everything imaginable. You will discover a growing expense that directly correlates with the age of the devices and browsers that you try and support. Supporting older devices and browsers are much more development intensive.

Sooner or later, you will have a client who owns a very decrepit Samsung tablet from back when no one knew Samsung even made a tablet, and they are going to want to know if their new fancy website is going to look good in landscape mode on that 8+ year old tablet that their kids are still using. The answer will be ‘no’ but you will need to find a diplomatic way to deal with the situation and similar ones that arise.

Did I mention landscape mode earlier? You will need designers and developers that have a good grasp of responsive website design and development because you do not want to try and design for every possible range of device width and device orientation out there. That is to say that it is much better to have a website that reorganizes itself properly for different screen widths rather than worrying about hundreds or even thousands of different possible canvas sizes and orientations.

Three designs should cover most of your needs: i.e. a small mobile layout for small devices in portrait mode, a medium layout for tablet devices, and a large layout for desktop. There are plenty of well established breakpoints out there for responsive web design and development. Use those if possible, and try not to veer into making too many unique ones of your own. Every new design variation equals more development time, which will add up to a much larger expense. If your client is footing the bill for all of that development time you will need to keep that in mind and err on the side of frugality where possible.

Web layouts are dynamic

I mentioned it above, but it is worth mentioning again, you cannot control or design for every possible device size and orientation. There are just too many of them, and guess what? Each of those devices has multiple browsers that run on them that might also impact how your design renders. So you need to develop an understanding of how HTML and styling can respond to different device sizes and orientations.

For example: text wraps. That’s why putting five words in a menu button is a bad idea. it’s going to wrap on mobile, and suddenly one mobile button is going to be much bigger than all the others. The same way you have limited usable design space on a business card, you have limited space in a menu item, and this is especially important when considering if your clients might want to add more menu items in the future.

Text wrapping is one of those very necessary parts of the web that endlessly baffles print designers and clients who are accustomed to the pixel perfect arrangement of a well crafted brochure. Text has to wrap. Do not try to perfectly design where a line of text breaks across every screen width.

Millions of dollars, possibly more, is wasted every year by print designers and not-so-web-savvy clients trying to get their developers to write custom code and styling to keep lines of text from breaking in inconvenient places. This will come up often. So remember, you are not designing a poster or a billboard.

Text is going to wrap based upon the space that it has to work with, and a skilled developer’s job is to make sure that the layout responds correctly.

Did you notice how all that extra text didn’t leak out of the button, it didn’t disappear or get cut off, and it didn’t end up jumping on top of anything else? Did you notice how that callout box managed to contain all of your extra text and expand as the paragraph got taller and narrower on different screens? Your developer did that. Your welcome.

Background images — it is a remarkably similar problem to text wrapping. When aspect ratios change, which they will for different screen width, how the background image covers the area will change. That means a focal area or area of interest in an image might shift or even get cut off.

Honestly, I’ve had to explain it to more than a few print designers. Why does this image position differently in a panoramic space — lets say 300px height and 1600px width, than it does in a mobile space that is 200px by 400px… Because it does.

Developers have a little bit of leeway in tweaking this but frequently we end up with clients that want the focus point on one image in a standardized layout to be on the left, but on another page it will be on the right, and can we shift that when we get to small screens? Can we customize it across all 50+ pages of our website for each layout (mobile/tablet/desktop)? This can get hairy and time consuming very quickly. So pick good images for the space that they are designed for and maintain some consistency across similarly designed pages.

Also, you should consider just having different images for mobile that are already optimized for the space they are in. It is often substantially easier to just give the developer the correctly sized and cropped image for that small screen than trying to get them to spend hours tweaking how a large image responds to a smaller canvas.

Website content changes

If I had a nickel for every time I worked with a designer who designed a page layout without considering how it would look if the content was entirely changed, I would have quite a few nickels.

So what happens to that carefully designed callout box if it suddenly had a three line heading instead of a three word heading? What would happen if your client put an image there, or a bulleted list? Sometimes your custom layout may need some content restrictions, and you may need to work with your developer to figure out the best way to make that happen. You will also need to communicate these issues with your client who I promise will imagine that they can add whatever they like to whatever space that you have designed for them.

Digital Content and Services should be adaptable to a wide range of users

This is the hard part but also the best part of working on the web.

Your website shouldn’t be a brick!

What do I mean? I mean back when most content was delivered via printed pages in a book or newspaper, you could safely assume that your users were going to navigate with their eyes and fingers right? Content came in a very static form, like a brick. It didn’t change and you could reasonably expect your users to figure out how to work with what you were presenting them. If they couldn’t work with what you were giving them then they just got left out.

Likewise, on the web today, many designers and developers assume that their users will navigate their website with a mouse, well functioning eyesight, perfect lighting conditions, and a never-dimmed backlit screen.

Don’t assume anything is consistent about your users, and more importantly remember that digital content is not brick-like. Digital content is infinitely adaptable and that is why you should be trying to serve the widest range of users that you possibly can. That means supporting users that want to navigate via mouse, keyboard, touch, screen reader, and even voice interfaces.

Digital content can easily be resized, recolored, shifted, relocated, downloaded, repurposed, or even read out-loud by end users devices. This can be challenging to stay aware of and work with, but it is also what makes the web such an incredible medium to be a part of.

You can get started with accessibility by just being aware of a few important things:

Contrast matters — find a good contrast checker and aim for 4.5:1 or higher for all of your standard text content. Larger text (24px and larger) can use a 3:1 contrast ratio, and be be aware of how readable text is when sitting on top of a background image.

Don’t disable zoom — ever.

Avoid autoplaying content.

Leave your focus outlines on — keyboard users use these for navigation. You can improve the design of them if you like, but please don’t get rid of them.

Use HTML and styling instead of text images where ever and whenever possible.

Respect heading order — document structure should be logical and not based on styling preferences.

Test your forms and workflows with a screen reader! Trust me. You have one built into that Mac you are using for your design work. I promise you have one. “Command F5” — try it out.

There is much more to accessibility but that will get you started.

Check out this article on how to get involved in global accessibility awareness day: http://globalaccessibilityawarenessday.org/participate.html.

A few other things that you can say that will make your developer laugh (or groan) at you

“Did you know that fonts render slightly differently across different browsers?”

Dev: Yes. Its actually a much bigger problem across operating systems.

“Why can’t we just let the responsive HTML to do it’s thing?”

Dev: You know HTML doesn’t magically become responsive on its own? Right?

“How come this giant square image doesn’t look right in this narrow space designed for a panoramic image?”

Dev: We gave you image dimensions, could you possibly use those?

“Why does this image load so slowly? It’s only 10mb.”

Dev: That image file size is 100 times bigger than it needs to be.

“We need images appropriately sized for the web? Can you optimize my 200+ images for me and then re-upload them to our site?”

Dev: Let me google ‘3rd party image optimization’ for you.

“Embedded 3rd party content doesn’t need to be accessible… does it?”

Dev: “It does in fact need to be accessible.”

“I’m working on my meta-keywords.”

Dev: Your SEO techniques are about 10 years out of date.

“Can you turn off that weird blue line around my buttons?”

Dev: That’s the focus state, and it is essential for keyboard navigation.

“What is a hover state? / What’s a style guide? / What’s a wire frame?”

Dev: What kind of design did you say you had experience in?

“Why can’t we customize where the text in this callout breaks across every page — all 50 of them, for all devices.”

Dev: If you went live without these perfectly customized text breaks, would you have a single website visitor ever notice or care? Seriously, if the answer is ‘no’ you might not want to spend developer time on this.

“We need motion on our site, can you add (insert random effect here).”

Dev: Motion, like any design element should be used with purpose and moderation. Please don’t just add motion because you think it will make your site more “modern.” Your site visitors will be impressed with well designed animations and effects that work cohesively with your site design and serve its overall strategy. This is the age of the smart phone, I promise no one is impressed with your perpetually moving ads and gratuitous parallax effects.

“We would like this to autoplay.”

Dev: I promise you do not have users that like autoplaying content! You don’t!

In conclusion

Obviously, there are more things to learn, but this should get you moving in the right direction and hopefully reduce the headache of the developers that end up working with you.

I know the web is a very familiar place for you, but there is a good chance that interactive and accessible design is very new territory. That doesn’t mean you shouldn’t be here. There is always room for better design on the web.

Do you remember what it was like get “access” to the web when you were young, and when the web was much younger? Remember when you used the word “access” to complain when you couldn’t load a page, download a video, or “access” your email? There are still users struggling to get access to many online sites and services out there and they would love to interact with your carefully crafted website. Keep those people in mind and build/design for the widest range of users that you can.

Resources

Auto-Forwarding Carousels, Accordions Annoy Users & Reduce Visibility
We recently ran a usability study in the U.K. where one user was attempting the following task: “Does Siemens have any…www.nngroup.com

CSS outline property – outline: none and outline: 0
The CSS outline property is an accessibility requirement, yet often abused by many web designers, why do they do it?www.outlinenone.com

WebAIM: Color Contrast Checker
You are here: Home > Resources > Color Contrast Checkerwebaim.org

Activating Interactive Element with Keyboard

element.click();

From Mozilla Developers Network

The HTMLElement.click() method simulates a mouse click on an element.

When click() is used with supported elements (such as an <a style="text-decoration: none; color: #3f87a6; margin: 0; padding: 0; border: 0;" title="The HTML element is used to create interactive controls for web-based forms in order to accept data from the user.” href=”https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input”&gt;), it fires the element’s click event. This event then bubbles up to elements higher in the document tree (or event chain) and fires their click events.

The most important thing for you to remember when trying to make your site’s interactions work with a keyboard is that when navigating with a keyboard, “hover” is not a thing. When keyboard users want to interact with an element they expect to be able to hit enter/return to activate an element. Luckily, the keyboard return event syncs with the mouse “click” event.

Hence, if you know how to make something activate on a mouse click, then you should already be able to make it work with a keyboard. However, unlike the mouse where user navigation is more implicit, you will need to think about how the user navigates to the “clickable” element and whether or not they can visually see that they have arrived at the “clickable” element.

This is where visible focus states become especially important and I have an entire article dedicated to this topic.

Navigation and Interaction

This is where the keyboard interaction can get a little bit dicey. You may have carefully and cautiously made every interactive element on your site activate via keyboard, but this will not matter if the keyboard user cannot navigate to those elements, or are not able to see that they are on the interactive element when they want to activate it.

With a mouse, we don’t have to worry as much about how that navigation occurs. We can safely assume that the mouse user has some kind of arrow or cursor with which to see where they are on the site and to indicate which elements they are interacting with. In addition, most sites use changes on hover to give further visual cues to the mouse user that they are on an interactive element.

Unfortunately, it is not uncommon for some interactive elements to be completely in-accessible to keyboard users because they cannot navigate to them.

It is helpful to think through how your keyboard users navigate to, and interact with an element, in order to fully test whether or not your interactive elements are actually keyboard accessible.

Steps for keyboard interaction

For the sake of this example, we will pretend that we have an accordion element – a series of collapsible elements that expand or collapse by clicking on a bar or button.

Imagine that the keyboard user wants to navigate to and open the first item of an accordion element in order to view the content inside of it.

1. Step one – The user navigates to the element using their keyboard.
   • This is typically done by clicking on the “tab” key.
   • The tab key will immediately move keyboard focus to the next focusable element on the page.
   • The user will see the visible focus outline on that element and will continue clicking “tab” until they successfully arrive at the element that they want to access.
2. Step two – The user arrives at the element they want to interact with
   • The user knows they are on the correct place because the element with keyboard focus is clearly visible – this is typically shown via a blue outline or dotted line.
3. Step three – The user clicks “enter/return” to activate the element.
   • When a button element is used the user should also be able to use the spacebar key to activate it.
4. Step four – The element activates.
   • The accordion panel expands and the user should be able to navigate into the new expanded element if there are focusable items inside of it, or if they are using a screen reader.

Step 4 isn’t really a step – it is the outcome, but it is important to think about what we expect the user to be able to do once that element has been activated. Frequently, the element being activated is a menu or navigation list with links to additional content.

Activating the element, is often only part of the process. It is also important to verify that the user can interact in the expected way with whatever has changed on the page. In this case, it was a an accordion panel that expands. If that panel contained interactive content then it would also be important for the keyboard user to be able to navigate into the new panel and interact with the content inside of it.

A Process for Verifying Keyboard Usability of an Element

Here is a basic list of items that you can check to see if your keyboard interaction is working well. Please note: I am not listing techniques for accomplishing these items here as that would be a much longer article.

Before element activation

• The keyboard user can navigate to the element.
• The keyboard user can see that the element that they want to interact with has focus.
• The keyboard user can activate the element via a click of “enter/return” on the keyboard or with a spacebar click when a button element is used.

After element activation

• The keyboard user can immediately navigate into the activated element.
  • This is especially important for pop-up windows and drop down panels.
  • For example, the user should not have to navigate through the remainder of the page to get to a popup window or panel that just activated.
  • In the case of a pop-up window/modal that is sitting in front of the other content, you should immediately move the keyboard focus to the new element.
• The keyboard user can interact with the content inside of the activated element if there is interactive content. A screen reader should also be able to be aware of and read any content that has been displayed.
• The keyboard user can close or deactivate the content.
  • Deactivating the interactive elements is especially important when those elements block other content on the page. This is a common issue for dropdown menus and popup/modal content.
  • “Re-clicking” the focused interactive element that is open or active, is generally expected to close it again.
  • Connecting a “close” or “deactivating” event to the “Escape” key is also a common practice.
• The keyboard user can navigate away from the deactivated element.
• In cases where the activated element is overlaying or blocking other content, the activated element should close or deactivate if the user navigates away from it.

Consider User Expectations and Unplanned Behavior

Generally, the keyboard users expect to be able to re-click an element in order to deactivate it. However, it is not uncommon for developers to build in other shortcuts like closing an item on an “Escape” key press. It is a good practice to have a backup way to close a panel and “Escape” is the most common, however do not assume that your user knows that the backup or shortcut method is there. If your users expect to be able to re-click an element to deactivate it, and you do not have a good reason to not have that functionality, then you should probably build that in.

Also, think about what happens if the user fails to close the element.

Suppose you have a large video popup that takes over most of the screen. You would not want the user navigating behind this element, and trying to interact with elements behind the popup that are not visible when the video panel is open. In this case, and in cases where an activated element covers part or all of the content underneath, you should force the content to close or deactivate when the user navigates away from it. That way, content that is blocked does not continue to be obscured once the user is no longer interacting with the overlaying element.

Resources

• https://webaim.org/techniques/keyboard/
• http://accessibility.voxmedia.com/
• Visible Focus States

 

 

 

 

 

Alt Text in Context

Using ‘alt text’ on images and icons

One of the common mistakes that web content creators and developers make when trying to make their sites accessible is related to “alt text.” We are told somewhere in the web development classes, boot camps, and tutorials that “alt text” is how you make an image accessible. This is not entirely true.

“Alt text” is the text you add to an “alt” attribute on an image. If you have ever seen a broken image on a site that shows a description of the image, it is the alt text that provides that description. In HTML, it looks like this: <img src="example.jpg" alt="image description" />

A little clarification is overdue. First, if you are using an image via an img tag (as opposed to as a background image) then you need an “alt” attribute. This does not necessarily mean that you need “alt text.” The “alt text” is the literal description that you put into your “alt” attribute. So when do you need one?

When Text Descriptions on Your Image are Essential

Text descriptions are absolutely essential in specific cases. Here are the circumstances in which alt text is not only necessary but crucial for your site’s accessibility.

• The image is serving as an interactive element such as a link or button – screen readers will use the alt text to describe the link or button.
• The image conveys information that is not otherwise available in a text form such as in an infographic.
• The image includes text – please note – for accessibility purposes you should avoid using text in images whenever possible. However, in some cases such as for logos, text in an image is sometimes necessary. That text should be conveyed via the alt tag.

Also note, that if the same text is available near the image such as in a long text description or caption below the image, then the alt text may not be necessary.  The w3c has a nice decision tree for helping you determine when a text description is needed:

https://www.w3.org/WAI/tutorials/images/decision-tree/

When Not to Use Alternative Text

Imagine that you are a non-sighted user perusing the web site of a business that you are interested in and you here this: “Summer rates available for a limited time. Large yellow sunflower.”

That second sentence is the alternative text for the lovely sunflower image that the business uses across their site to accentuate their brand. The question for the business owner is: do you really need to tell your non-sighted users about the yellow sunflower –  everywhere that it occurs? More importantly, do you think that is what they want to know about?

For accessibility purposes, you should have an alt attribute on your images. However, in many cases you can use a null attribute. <img src="example.jpg" alt="" />

Notice the alt=”” in the code above. This is an empty or null alt attribute. Leaving the alt attribute empty tells screen readers that the image should be ignored.

Images that are only decorative in nature should get an empty alt attribute so that screen readers will know to ignore the image. You can still convey images that are intended to convey an emotional appeal by describing the image. Keep in mind that text descriptions of an image may have a bit of a different feel than the image itself.

Remember Cognitive Load

Before you fill your site with atmospheric images with descriptions like “Smiling happy couple,” and “Older couple, happily walking through a park,” think about what you really want to convey to your users. Too much information can negatively impact your intended message.

For screen reader users, cognitive overload from too much repeated information, or unneeded information is a frequent complaint. So make sure that that atmospheric image conveys useful information to your users before you add a text description to the alt attribute. Your users are generally on your site for a purpose, and unless you are a stock image site, they probably don’t want to know exactly how happy the images of the people you add to your product pages are. Instead, focus on the actual product, information, or message that you are hoping to convey.

Resources

• https://www.w3.org/WAI/tutorials/images/decision-tree/
• https://css-tricks.com/some-things-about-alt-text/
• https://developers.google.com/web/fundamentals/accessibility/

 

Web Accessibility Basics – Focus Outline

This is the second article on my web accessibility basics series. See Web Accessibility – Where to Start to find out more about contrast standards.

Visual Navigation

Have you ever been comfortably navigating your laptop or desktop computer when suddenly your mouse cursor disappears? Maybe it froze or got lost in some black hole off the screen. It is incredibly frustrating because your computer usage comes screeching to an immediate halt. You literally cannot interact with your computer without that little visual indicator of where you are on the screen.

The mouse arrow, pointer, or cursor provides a crucial component of your computer using experience. It is the visual indicator of where exactly you are working in the interface. In websites and applications it provides additional visual queues. The arrow may change to a pointer or finger icon when you are over an interactive element such as a link.

When you are visually navigating and interacting with a computer screen the visual queue provided by the mouse arrow, a blinking cursor, or a pointer makes the difference between a usable and not usable interface.

Visual Navigation Via Keyboard

Now that you know how very crucial it is to have a visual indicator of where you are on your computer screen, imagine that for some reason you are not using a mouse to navigate. There are number of reasons that this might be the case. You may need to use a keyboard to navigate due to a having a limited range of motion in your wrist, or because you have a child in one of your arms. You may be using a screen reader to read the contents of the screen to you and not using the visual interface at all.

In these cases, having functional keyboard navigation is incredibly important. The visible focus state is the keyboard user equivalent of the visible mouse cursor. Keyboard users can use the tab button to jump between links, buttons, inputs, and other interactive elements on the page. So how do they tell exactly what they are interacting with on the screen? They need a visible focus state.

Luckily browsers set visible focus states by default. If you have ever seen that bright blue outline around a link or button (typically a dashed line in internet explorer and firefox) then you are familiar with the visible focus states.

So Where is My Visible Focus State?

Unfortunately, these outlines are often disabled by developers due to design teams disliking them, and in some cases responsive frameworks like Foundation will disable them by default.

You can actually customize your focus outlines in css using the focus pseudo-class.
a:focus {
outline: 1px dashed red;
}
button:focus {
outline: 1px dashed #222;
}
input:focus {
outline: 2px auto blue;
}


The above code applies outlines to their respective html elements on a page.

Set Visible Focus States on All Interactive Elements

You should also have visible focus states on any interactive element on the page. By default focus states are applied to form inputs, buttons, and links (‘a’ tags). For example, if you have a slide out panel, or series of sliding panels like an accordion menu system, then you should have a visible focus state on the element that activates the hidden panel.

It is a good idea to use a button element anytime that you want to have an interactive panel on a page that toggles open and closed – e.g. drop-down panels, accordions, etc.

By default button elements are focusable. Another common method is to us an ‘a’ tag with the href attribute set to “#”. This will create a focusable element for the activating element of your panel.

It is important that interactive elements be focusable by keyboard users, and for the focus state to be visible. That gives your keyboard user a visible queue of what element they are on. Non-focusable elements may not be findable by the keyboard. In other words, your keyboard users may have no way of knowing that an element can be interacted with if you do not use a focusable element, and set a visible focus state to make it clear when that element gets focus.

Additional Resources

• Outline none
• https://css-tricks.com/almanac/properties/o/outline/

In the next article I will discuss how to make your interactive elements activate with the keyboard.

The Unfortunate State of Professional Web Accessibility

Cross posted from medium.

I see it happen on a regular basis, a client insists that their site is “fully accessible” or “fully WCAG 2.0 AA Compliant,” and it isn’t even close, and I don’t mean “they missed a spot,” or that there is some narrow area that I would have personally handled differently. I am referring to giant, obvious, even basic accessibility issues that still exist on the supposedly compliant site. Usually, the culprit is a web-related services company who added “accessibility remediation” to their service offerings without fully understanding what that meant or gaining the necessary expertise.

Let me be clear, any improvement in the accessibility of a site is good, even if the site is far from “fully accessible.” We do not want the perfect to be the enemy of the good. There are, however, a great many companies offering “complete compliance”, “certified compliance”, “certified ADA compliance,” and “certified WCAG 2.0 AA compliance,” that have in reality, chosen to pay attention to only a fraction of the standards that they are claiming to attain.

To state it in another way, if a company is certifying a website as “fully WCAG 2.0 AA compliant” then they should know every WCAG 2.0 AA success criteria inside and out. They should understand the best practices that are recommended by the W3c and by the web accessibility industry. They should be well aware of common failures for every success criteria and how to spot them. They should know the strength and weaknesses of automated testing and when manual testing and QA are needed (which will be something like 70-80% of the work that they do). They should know what it means to get as close as reasonably possible to that conformance level as a site can get. And they should absolutely be aware that while a high level of conformance is possible, perfect conformance is not.

Here are some of the major accessibility failures I see regularly on allegedly “WCAG 2.0 AA certified” websites.

Text Images

No, you may not just use text images wherever you feel like it. Text images are not accessible. They cannot be resized, or restyled for users that have vision or cognitive issues. That is why they are effectively prohibited where they can be recreated via css and actual text. There are a narrow range of exceptions to that rule for items like logos, and depictions of font families. I see this all the time on these supposedly remediated sites — dozens to hundreds of ads and banners that use images of text. Often the developers of these sites do not even attempt to include all of the text from the image in the alternative text attribute, which violates another success criteria.

Contrast

If you do not understand the color contrast requirements, then you are missing one of the most basic accessibility requirements. The problem is that there is a little bit of variation in the contrast requirements based upon the size of the text. Some “accessibility remediation” providers seem to have decided that a 3:1 ratio is all that is needed for all circumstances. Sorry, no. For fonts that are smaller than 24px and not bold the criteria is 4.5:1. If your font is bold that change happens at 18.66px — smaller than that and bold still needs the 4.5:1 ratio.

Pause moving content

Does your content move, rotate, animate, or update, for more than 5 seconds? Then you need a pause button. That means that unless it stops moving entirely and never moves again by the 5 second point, then you should have some sort of pause button that stops the movement. Your auto-rotating banner is entirely non-compliant without this. Your animated flash ad in the sidebar is non-compliant without a pause button. Where is it?

Forms need labels

Yes, there are some exceptions to this rule, but those exceptions are there for circumstances where a label would not provide a benefit, or might make the interface more confusing. You can’t just toss your form input labels because your design team thinks a form looks “cleaner” without them. This is such a basic requirement, that it amazes me how often I see sites that completely neglect this, or use some other technique to try and work around it. Placeholder text is not a replacement for labels or instructions, because placeholder text disappears when you type into its associated input.

Focus States

Have you ever tried to navigate your computer with a mouse after the cursor has disappeared. You can’t do anything, because you can’t figure out where you are on the screen. Focus states are the equivalent of the mouse cursor for keyboard users. If you have disabled focus states or overridden the defaults with something effectively invisible, then you have a site that is not navigable with a keyboard, and hence not accessible. Visible focus states are an explicit WCAG 2.0 AA requirement.

Hidden panels that are not properly hidden

So you are casually using your keyboard to navigate through a website when suddenly your focus state disappears, and then it reappears 40–50 tabs clicks later. It probably just disappeared into a hidden menu that was not fully hidden from the DOM. This happens when developers hide an element by using off screen positioning or some other similar technique rather than “display: none” or “visibility: hidden.” The result is that you just failed the keyboard operability requirement, the visible focus states requirement, and the focus order requirement. It’s like a three-for-one failure, and it really does create a terrible experience for keyboard users.

Look Ma, I beat the automated accessibility checker!

Automated accessibility testing tools are very important, however, they can give you false positive results, false negative results, and they really only cover a small fraction of the accessibility issues that need to be fixed. The vast majority of the issues (75–80%) can only be found via manual testing. But that doesn’t stop less-than-well-trained remediation companies from simply trying to beat a specific accessibility tool, rather than developing a full remediation plan. In the process, they often create problems worse than the ones they are trying to fix.

I have seen sites that put “display: none” on their form labels. This accomplishes nothing. It does not provide readable labels or useful instructions to any of your users. But it does fool some accessibility testing tools.

On another occasion, I saw a site in which the “accessibility remediation company” realized that that css icon fonts (Font Awesome in this case) needed some sort of text inside of a link. Screen readers cannot read css icon fonts, and so when they are used for a link, the developer needs to provide some sort of text to the assistive technology users. The developers at this firm solved the problem by using a span element with “display: none” on it, inside the link. The span had the proper text of the link — the names of the associated social media websites in this case. Unfortunately, assistive technology does not read elements that have “display none” on them. So what did this accomplish? It passed an automated accessibility tool, while not actually providing readable text or a functional link to assistive technology users.

Assistive Tech users are not the only users you are trying to reach

Don’t “screen-reader-only” your skip link. Seriously, don’t do it. Think of all the sighted people with mobility issues that really do not want to tab through all of your navigation. Think of them, please. And while you are at it, labeling inputs in a form actually helps everyone understand what your form is for. Please don’t “screen-reader-only” your labels on anything that is not a super simple, very small (like single input) form. I understand that sometimes you are trying to squeeze a little search box into a small area of a header somewhere, it is already obvious that it is a search box, and that a label could be redundant. But did you really just “screen-reader-only” all of the labels on your “contact us” form? Seriously, don’t do that. For those not familiar with the concept of “screen-reader-only,” there are multiple techniques for visibly hiding an element while making it still readable to screen readers. Sometimes, these techniques are both necessary and appropriate, but like any useful techniques they can be misused and misapplied. Remember to consider how those without assistive technology might be using your site. Users with mobility impairments, but not vision impairments are often forgotten in the push to make a site “screen reader friendly.”

Don’t Forget HTML validation

It’s actually really important that your HTML be parseable. Browsers are very forgiving when it comes to developers using poorly formed code, deprecated code, and even misusing their HTML. If you don’t ever try out the validator, you will never figure out that those <style></style> tags are really only supposed to go in the head of your document, not the body. You might never figure out that your CMS is injecting duplicate ID’s into your page. You might never notice that half the attributes you are using on your tables were deprecated a long time ago. Not every piece of software that attempts to read your page will be as forgiving as a browser, and all of your careful efforts to make your site accessible could be in vain, if it turns out to be non-parseable.

Headings have an order

That’s what the numbers are for. H1, H2, H3… They should go in order. They are not there to satisfy the styling plans of your designer. They should be used in a logical way. Your H1 should be closely related to the title of the page, or be a clone the title itself. Each subheading that is not nested inside of another heading will probably be an h2 at this point, subheadings nested inside of h2’s should be h3’s, etc. There are multiple requirements that relate to this, but the most relevant is likely that the structure of your page should be programmatically determinable. If you are using fake headings like bold font in the place of an actual h tag, or mis-ordering your headings, your page structure will not be understandable to assistive tech users.

Use roles and aria attributes correctly

Semantic HTML elements have implicit roles, you should know what those are. Both aria attributes and roles are meant to be used in specific ways, and have rules for how they are used. Some aria attributes are not allowed on specific html elements. Some areas of your page are considered landmarks, and should have appropriate roles associated with them. Sometimes, remediation firms completely muck this up, and even, on occasion, make up their own roles or aria attributes. Seriously, you can’t just make up your own “aria-stuff”.

The bigger picture

There are so many other issues that are necessary to address to make a website WCAG 2.0 AA compliant — i.e “fully accessible.” The things I listed above are actually the very basic requirements. And when a remediation company has misunderstood, or even completely failed at the basics, then I already presume that they are missing the much more complex issues.

If they can’t figure out contrast or form label requirements, I am going to presume they do not know how to support 200% zoom, or that they have not adequately screen reader tested their sites on IOS devices. They probably never noticed how very inaccessible their mobile menus or accordions are. I am also going to presume that they do not have a clue about how screen readers deal with form input validation, or if their forms are even usable with assistive technology.

Imagine, for example, if every single form on a site was completely unusable to non-sighted users, in spite of the fact that the site was “certified accessible,” because it was using an old inaccessible version of captcha. I have witnessed this on multiple sites, and it is tragic. The owner of the site sincerely believes that they are serving all of their users with a fully accessible site, while entirely failing in one of the most crucial areas.

As developers, we have been misusing and abusing our HTML for years. We have developed and propagated css techniques that fail to consider how both third party software, and assistive technology users will interact with our sites. We have almost entirely neglected the concept of keyboard navigation while designing our desktop sites around the interactive presumptions of mouse and trackpad use. And we have embedded widgets and tools into our sites that block some groups of users entirely from using the services offered by our sites. This is why a deep understanding of website accessibility is crucial to not just those developers that specialize in it, but to all developers who work with the web.

Web Accessibility – Where to Start

Many businesses, when faced with the prospect of making their websites accessible do not know where to start. This post is intended to help with that.

The easiest place to start for most web site designers and administrators is with color contrast. Color contrast refers to the level of contrast the text on your site should have to its background.

There are two primary levels that you should be aware of the 3:1 contrast level for large text, and 4.5:1 contrast for small text. Large text is text that is 24 pixels in height or larger.

A common error is to presume that the 3:1 ratio is good enough for all text across your site. Unfortunately, it is not. Because smaller text is more challenging to read it requires a higher level of contrast to be legible. Small text and this generally includes your standard body text, needs to have a 4.5:1 contrast ratio. In addition, you should never use text, even fine print text on your site that is smaller than 10 pixels.

If you are in doubt whether or not your text should have the 3:1 or 4.5:1 ratio, err on the side of caution and just use the 4.5:1 ratio.

Determining Contrast

There are a number of tools that will check your contrast levels for you. Developers typically use a tool like Webaim’s wave checker to determine the contrast ratios on their site. This comes in a convenient chrome extension. In addition, you can use Webaim’s color contrast checking tool to try out individual colors and backgrounds.

Why is Text Contrast Important?

For a number of years it became somewhat fashionable in website designs to use very faint text, particularly in form fields and in footers. This low contrast text causes major problems for site users who have low visibility. You do want your site visitors to be able to read your content, right? That is why you put the content on your website, right? So give it enough contrast to be legible to the widest range of users possible.