We did it!

After months of blueprinting, information architecture, stakeholder interviews, design, front end, and development work and countless hours of revision based on internal testing and client user feedback, we released the redesign of Envision's main website, envisionus.com. A huge thank you and congratulations go out to everyone involved in the process.

Constantly learning

In every project, there's plenty to learn and build upon. A wise developer once said (often said, actually!) that if you don't look back at your code from 6 months ago and cringe, you're not growing. We have a feeling that this project will be one of those that causes us to cringe at our code from previous projects.

Envision serves individuals who are blind or visually impaired (B/VI), so there was a huge learning curve for us during this project. We all had and idea of the basics involved in writing markup with accessibility concerns in mind, but no other project to date has it been a part of the user expectations in such a meaningful way. Section 508 and WCAG compliance were of the utmost importance. Yet, as we developed we learned that those compliance checklists were really just the tip of the iceberg and that a truly accessible user experience for all types of users would take a lot more effort, research, and trial and error. We gleaned as much as we could from the requirements and specs of 508 and WCAG and leaned heavily upon a11yproject.com and webaim.org to drive our development.

Windows High Contrast Themes

If you are not blind or visually impaired, you have probably never noticed that Windows has some high contrast themes for B/VI users. If you have, gold stars for you. If not, you can find it in Control Panel > Personalization, then under "Basic and High Contrast Themes," select High Contrast #1 or #2. Additionaly, you can toggle the mode with alt+shift+print. You'll immediately notice some very drastic differences to your Windows experience and you'll also notice that when using Internet Explorer or Firefox, websites follow suit (High Contrast mode doesn't seem to affect Chrome, but it does have extensions that simulate the experience). Most notably, all backgrounds are converted to black and text and border colors are bright yellow and bright blue. This can (obviously!) do some really funky things to your site, but if you know what to expect, you can plan for most issues that will crop up.

Background images
As if we needed more persuasion to make the switch from background images to inline SVGs for logos and icons! You see background images used for logos all over the place, including many of the sites we have developed—it's a trend that has persisted with good reason due to its compatability with high pixel density devices. Actually this Codepen site illustrates well the same issue we ran into. At the time of this write-up, the CodePen logo is a background SVG image, whereas the icon in the "New Pen" button is an inline SVG. In High Contrast Mode, the logo is not visible; the icon is visible.

Absolutely- or fixed-positioned elements
Our header element is positioned absolutely, above all elements, with a transparent-to-grey gradient background image. When not in High Contrast Mode, this adds a nice, subtle touch to the images and banners that it normally covers. The gradient also prevents the white text and borders from getting washed out if the image below the header is a light color. BUT, when using High Contrast Mode, the background is set to black and the header covers all images and text. This would be the case even if no background image were set, as the inherent definition would be a transparent background. This kills readability and usability completely. Fail!

Fixes for the above issues
You didn't think we would just talk about all the pitfalls with no solutions, did you? We've got your back—hopefully you'll save some time learning from our mistakes and we'll build a better internet together. This pen illustrates both the JS needed to detect High Contrast Mode and the most crucial CSS rules to fix the above issues. Click the toggle button in order to simulate High Contrast Mode.

Normally, High contrast mode can be targeted by the media query -ms-high-contrast:active, but as you might guess, this only works on IE high contrast mode. Because Firefox respects High Contrast Mode, so something else is necessary. When High Contrast Mode is active, both IE and Firefox set background-image:none;. So, this script checks to see if background images have been set to none, and if so, then injects into the <head> a CSS file with styles specific to High Contrast Mode.

The CSS overwrites logos and icons that use background images so that the text is readable again and resets width & height to auto. It also keeps header from overlapping images or text.

Beyond these basic resets for High Contrast Mode, you might consider making other stylistic changes to massage the look of the site. In the pen, you'll see that we increased the font-size for the main logo and removed the border from the social icons.


If you’ve never used tabbing to navigate a webpage, you may be in for some unfortunate surprises. With hamburger menus and other expandable menus that rely on a click or touch to activate, the possibility of navigating sites page with tabbing has become increasingly more difficult. We needed our site navigation to not only be usable with tabbing, but also give the users visual cues as to where they are on the page as they tab—something normally shown with a thin blue outline.

The solution to these issues was to rely on tabindex & the :focus selector, but first we had to ensure that the user would tab into the menu first. So, we set tabindex 1-10 on the menu items making them always the first things tabbed through on the page. Next, by using jQuery’s .focus() event handler we were able to trigger the same JS as when the menu is clicked or touched. Finally, we made the menu close when the focus leaves the menu, or in our case targets the logo.

But what about knowing where we are on the page? Outlines weren’t visible enough and in some cases looked bad on parts of the page. Our solution? We added :focus to all of our hover events. This allows users to tab through the pages and exerience all of the same user-experience additions that :hover provides—the site can be quickly and easily navigated without ever touching a mouse!

Building a Pattern Library in CodePen

Because this site began development a few months before our CodePen Pro Team account was created, the Pattern Library can currently be found here.

We've done several pattern libraries in the past and they've been both integral to our success and increasingly important to our design and development process. They even assist in client buy-in and function as showpieces for possible new work. Until now, though, they have stayed in our normal development environment. This site represents the first time that we've developed pattern libraries in CodePen. This has come with several added benefits as well as some pain points. Now, we're fairly new to CodePen, so if anyone has suggestions to help us with these issues, please bring 'em on!


Markup always apparent and obvious. The beauty of CodePen is in each Pen's ability to be shared and the transparency in what's under the hood of each Pen. That is, anyone that can read HTML, CSS, and JS can walk up and immediately see what's happening. In order to achieve that in our other pattern libraries, there was a lot of overhead to maintain the correct structure. CodePen just does it.

Hand-off to Back End Developers is painless. Because the markup is so easy to access, there is never a question as to what should be used and when. Developers can easily see what they need and get it. For this project, specifically, we were integrating into the CMS Kentico, which employs the idea of "web parts." Now, this is a subject for a whole other post, but suffice it to say that having each pen as its own, separately contained group was a huge advantage when converting markup into reusable web parts.

Contributing to the community. This goes without saying, but I'm going to say it anyhow. The other best thing (is that possible?) about CodePen is that everyone's work is shared—unless it's private—and therefor when one person succeeds, we can all succeed. That's the whole reason we're even spending the time to write this post. Well, that and show off our ability to make awesome Front End memes.

Pain Points

Big page load. Averaging around 30 seconds for all iframes to finish loading. This includes writing the blog post - preview pane loads after every change, so it slows editing to a crawl after every keystroke.

We have to include same lines in HTML Settings for every pen. If we want the Webfonts, Stylesheets, and Meta tags to stay consistent within the project, we have to copy-paste them into Settings every time. This is definitely different than our normal development environment where every page inherits from the same Master Page, which contains all of the necessary calls for JS, CSS, and meta tags.

Suggestions for Chris and Team

Folders for organization. In an attempt to mirror a normal development environment, it would be nice if both Pens and the Asset Manager had folders so users could organize their projects. This might not be as useful for the "one-off" pens or the "testing behavior" pens, but even those could be grouped into folders if need be. In my experience with the platform, it's hard to keep things organized once I've created a bunch of pens. This is especially true in Team Context, as others can be adding new pens at any point, which can hairball very quickly.

Pens made from a certain "template". When I'm making pens that all share the same global stylesheet - as in the case of creating a Pattern Library or just multiple pens for the same project/client - I'm constantly copy-pasting the same "Stuff for <head>" and LESS includes. If I could create a base template off of which to create multiple pens, this would cut down on repetitive tasks as well as the error caused by missing one here and there.

Consider adding the option to turn off "Preview" when writing a new post. It's fine when it's text and a few embedded pens, but when a bunch of pens are used on the post, editing becomes a grind.

More to come

We are still developing a few Envision subdomain sites, which will be released later this year. We look forward to using what we've learned on these sites and making them even better and easier to use for all users.

3,994 7 13