The next three months were spent defending why our website was sub-par. Truthfully, the site was a mess so it was less defending and more like explaining.  I was exhausted and had reached a limit!  Much like the old song lyrics, “I didn’t start the fire,” but I knew I had to put it out.

Step one was developing an accessibility plan.  While I’m still working on the details of ours and will have more to write on the topic in the future, I thought I’d share some tips for other universities or corporations trying to begin the overwhelming process of developing an accessibility plan.

Here is the crash course I did to kick off our plan:

10 Tips to Begin Your Accessibility Plan

1.) Houston…we have a problem. Admit your site has a problem. Write up a list of accessibility issues you know of first hand, then compare this to your checklist of bugs to fix. You may instinctively know more then you realize about your website’s user interface, or lack there of.

2.) Get compassionate. Understand the problem. Don’t assume anything. I had many awful perceptions that have been corrected in this area  (like color-blindness is just not being able to see green and red—WRONG!).  Impairment Personas give descriptions of user needs while contextualizing it with user’s personal stories.  These personas bring your users to life and help you understand what obstacles to expect and what goals to set.  This will give you compassion and focus.  If you aren’t familiar with impairment personas, check out the W3C for an excellent descriptions of user needs.

http://www.w3.org/WAI/intro/people-use-web/

3.) Get passionate. Know the difference between 508 Complinance and WCAG A-AAA Priorities (Web Content Accessibility Guidelines). Read the the entire specification,  I know it seems daunting, but its worth it in the end. You don’t have to understand every intricate detail, but you should be able to explain the main specification in a nutshell. Remember, you will have to draft this for your team, so you should know it inside and out.

4.) Grab the ball. Don’t be intimidated by lawsuits others have been through, instead use these as leverage to get your executive or adminstartion’s support. The lawyers go after those without a plan, not those who are aware of the problem and trying to change. Get on the offensive, instead of being defensive.

5.) Join the pack. Attend an accessibility conference. I have attended several in the last couple of months, and each one has been very insightful. Not everything at these conferences has to exactly pertain to web.  Sign up for areas that are outside of your wheel-house, diverse sessions will make you have a well-rounded understanding of user needs.  After all, this is bigger than your website. If you can’t afford to go to a conference off-site, check out free webinars offered online. Many state and federal government(s) offer free webinars, these sessions are invaluable, plus they are fiscally prudent–something you’re boss will love.

6.) Ask for help! If you don’t understand how a motor impairment affects users with a disability on the web, email your Disability Services or Human Resources Director or ask to interview and/or watch someone with this impairment first-hand. If either of these options aren’t practical,  read the W3C Personas listed in step 2, they will give you a vivid picture.

7.) Location, location, location. Find users and experts in your office or institution. Ask your Office of Disability Services or Human Resources division who at your institution is passionate in this area. Get them on your team, illicit their help to solve this problem together.  These users will be honest and forthcoming on your implementation if it doesn’t make sense or doesn’t meet the need.

8.) Follow the little birdie. Follow some accessibility experts on Twitter. I have been following several who have been amazing to read, blog, and follow and helped me to digest the length documentation found on the W3C and WCAG.   Some good recommendations are:

• StandardsSherpa
• webaxe
• stcaccess

9.)  Take  a final inventory again. Grab your list from number one and your knowledge from steps 2-8 and make a final list of web accessibility issues on your campus\office.  In addition, evaluate institutional guidelines that may need to either come into compliance to meet these needs or, better yet, might help you further strengthen your case for an accessible website.  Now write up a formal inventory of all the areas you are failing at.  This should be an exhaustive list! Rate each problem area (pass or fail), including: how long its been in or out of compliance, what specification it violates (Institutional Guidelines, 508 Federal, WCAG-W3C), and how it impacts the current website. This will be very helpful in later later discussions and planning meetings.

10.) Just keep trekking’ The tricky part about all of this is that it is up to each institution to adopt practices to encourage and reward good accessibility standards. WCAG won’t give you the code to make a better website, there is no “One-Touch Accessibility” magic button. Careful communication with developers and designers, combined with user education are the key to on-going success in web accessibility.

Stay Tuned for PART II –  The Nuts and Bolts of Creating A Web Accessibility Plan.  I’ll discuss, how I actually designed, wrote, and delivered our Accessibility Matrix to the development team.

We are in the middle of rapidly developing and designing a new look for the university.  This has been a crash course for the team and me especially,  given the pace we are working at.  For those of you who don’t know what agile is –here’s agile in a nutshell– its  a software development methodology that’s main tenant is to set small incremental goals, increasing success, and limiting failures.

So as a designer, I could ask— is this agile or fragile development?   I haven’t gotten a strong read on the designer community on this, so I can’t speak for all designers, but its been a great and freeing experience for me.

Design in the web space often feels like writing the ten commandments in stone, the irony  of this statement is not lost given the less indelible marks the media intrinsically has.

But I will say it—I often feel more trapped by web design then freed by it!  Until now, that is.  Agile is a designer’s dream (I realize one might argue that this might be the ramblings of someone still on honeymoon with agile )–especially one that is constantly changing her mind, upping her game, and pushing boundaries in her designs. But I will say it I <3 agile.

10 reasons why this designer loves agile:

1.) I see the design evolve giving me more time to process and test the UX of my design.  I can be certain the design that ends up at launch has all the kinks worked out early on with plenty of user input along the way.

2.) Race against the creative clock. I have always hated deadlines.  I remember breaking out in a cold sweat during timed math times-table tests and getting so upset that I would literally pass out at my desk from nerves.  That being said, I have a love-hate relationship with deadlines, they push me and in the end to create a sense of urgency in my work, but they can also destroy creativity. Working to a clock can be very stressful, and limiting.   Everyone has been on projects that either seemed to drag on for months with no progress, or were so rapid that you couldn’t even think about good design because the deadline was too soon. But two-four weeks is manageable, it feels like there is an end in sight.

3.) Happy clients=a less stressed designer. Clients see progress and that means more opportunity to get things right. I have redesigned many sites in the mid-night hour, moments before launch while the client hovered anxiously behind me dictating last minute changes.  The stress off retro-design is far worse then the client telling me four weeks, or even four months into the project that they hate it. I have time to course correct and find a solution. Plus the opportunity to tell them “we will get this right in the next scrum”, is like a nice security blanket against failure.

4.) I feel happy. It just feels good to see progress. After 4 years of waiting to redesign this page–seeing my designs come to life is a very gratifying experience.

5.) I can fail! Yep, I can have a bad design day! I can hand something to my developer, and not have to worry about designer’s regret the morning after launch. Obviously, you don’t want to drive the Dev. team crazy with ridiculous changes all the time–but at the same time I can feel less stressed if the creative vibe doesn’t hit me as quickly as the deadline did.

6.) Speak nerdy to me. Agile fosters collaboration forcing creatives and techies to speak the same language. Development and design teams hash out issues, collaboratively. Design isn’t issuing a decree from on high to development, or development refusing to play nice with mock ups. The process forces compromise and discussion. This makes a strong team, and fosters mutual respect for vastly different disciples and personalities.

7.) Agile limits distractions, and sets clear deliverables and expectations.  Agile provides a clear road map and sets priorities for each project.  It doesn’t matter if it’s the client, developer, or myself I can set realistic goals in agile and then actually have the ability to stick to them. The project doesn’t become overwhelming or unattainable, because un-prioritized tasks don’t override current tasks.

8.)  Details become the star in agile. I’m more thoughtful on functionality for elements. I pay more attention to detailed elements on a page when the deadlines are in small cycles. For example, the element control or to the drop shadow of my menu font, is much more painfully obviously wrong while working in agile, then in mass website launches where the rotators or fonts get lost or overlooked. I am a much more careful designer in agile.

9.) Agile can be the bad guy. If you are like any other designer you are working on many projects at once, and dealing with countless interruptions while doing it. I can say to the client or my boss (respectfully of course), “Sorry that task isn’t in this scrum, but let’s tackle it in the next one.” It allows you to say no, without sacrificing the project to scope creep, or being accused of not being a “team-player”.

10.) It just makes sense. Atferall, its like the old adage says, “How do you eat an elephant?  One bite at a time. ” If the website is the elephant, agile is the spoon. So if you haven’t tried agile, take it from this designer, pick up a spoon and start eating now. Its so worth it.

However, I think I have really under estimated the search moguls lust for fresh content—specially for social media.

So awhile back a colleague and I wanted to test how quickly we could change our search ranking with Google. This was because we had many pages we were handling on University pages (750,000+) and redundancy was really hurting our search results and confounding our clients.  We have all gotten that frustrating phone call from a a client who is alarmed that their newly created site falls well below a very outdated page from years ago.  My colleague and I were simply attempting to unveil the Google code.

Well we found something alarming, WordPress, and Social Media content literally over night would bump you in the result.  The experiment went like this, he went home and blogged about his band on his newly created WP site.  We had checked his rankings the day before and they were dismal, however to our surprise after just one day he had moved up alarmingly fast by any Google standard I had seen.  We both were amazed but still assumed it was some freak Google algorithm and moved on with our day.

Skip many months forward.  I have a Google nemesis.  And I would guess I am not alone.  You know, the other person with your same name who seems to always rank higher then you.  Mine happened to be in the form of two people, a professional paintballer and a biologist from Virginia Tech.  I was beyond frustrated with this situation after it was a matter of pride I live, breathe web.  I wanted the favored position from Google. So I made it my life work to eclipse the other “Jessica Sparks” and place first on the rankings.  I struggled for months, changed my site,  and tried nearly all the SEO tips I could find, I am ashamed to admit I even consider ad words.  I eventually gave up and resigned myself to a sad state the Jessica Sparks of the internet would be forever buried by Google.

Then last night it happened!  My husband came home elated to tell me I was in the number three spot!  I immediately I ran to my computer and checked my results and true enough number three –LinkedIn considered me the “alpha” Jessica Sparks.  Then it hit me, I had been heavily using LinkedIn over the past two months.  I had made a point to make my   connections broader and reply to my network.  Was this the golden ticket?  I still don’t know but you can be sure that night I polished off my WordPress blog and started writing. I’m sure my position will wane but it was obvious to me the connections my colleague, Nick Kizirins and I had made over a year ago had some staying power.  Maybe this is long sense been news to the blogosphere, but to me it was a little piece of Goggle heaven.

This makes me ponder, is social media Google’s secret mistress, or has she been Google’s partner all along?