SMS is primary social tool in Sub Sahara Africa – only data the infrastructure will support.

Problems: When there’s no way to skip repetitive content, no text equivilents for images when the sites are super image heavy, when you can’t identify inputs and controls – the rush makes accessibility fall by the wayside!

Problems arise when users who don’t know about accessibility can create content without the tools available for accessibility information. 15 year olds on YouTube don’t know about captions on their home movies – how to handle the user-generated content question?

How to make Web content accessible to peopele with disabilities. Education is key!

Text alternatives are important to image heavy sites: Thumbnails in discussion threads, avatars in forums, images in user galleries.

CAPTCHA: The questionable best way to handle bots. Turing Test Alternatives are better “Is fire hot or cold?”. What about audio files? They are, by definition, hard to hear! Look at Blogger’s audio CAPTCHA.

Don’t make it harder for your users to sign up than it is for bots and phishers! This should make you think long and hard about access barriers.

LABEL YOUR FORMS! The and attributes are important for those hitting your form in JAWS form mode.

Facebook Mobile: m.facebook.com, simpler, easier and faster loading. Much easier for screen reader use. beware – login and other forms still not labeled!

Twitter: “what are you doing?” is labeled correctly, most images have alt text. Skip nav is enabled. Use greasemonkey scripts to enhance accessibility. There is a third party accessible alternative.

WordPress: problems are two fold: admin interface and published interface. Templating on the front end works great for the 6 files (wrap your content in an accessible package). With admin panel – edits are lost on upgrade! Look at /wp-admin/ folder to see the admin template files. Login form in properly labeled for accessibility. Admin section has problems, but know issues are getting better. Alt+Z drops right to content editor! Those need to be told to users!

Developers know things can be better. WAI-ARIA used to send info back to blind twitterers about how many characters were left in their tweets (TPG Notifier).

“Great kid, now don’t get cocky” – There is a need to get content from developers about what does and doesn’t work. Open source can help with all this. Rather than feel overwhelmed, try to submit patches, find the accessibility hooks, share findings, communicate! WordPress IRC is always open, Facebook loves feedback!

INFORMATION ARCHITECTURE

Why do we fuss and preen over this stuff? Because it works. A recent A List Apart article by Keith LaFerriere details why we need to educate the client on IA, it’s place in the construction of their Web project, and what it does for them down the road. Bringing the client in at this stage allows them to see what the shape and functions of the site will be ahead of time.

This doesn’t mean we sacrifice flexibility of the project – we all know change is good – but it allows the flexibility to be controlled: the sitemap needs to be changed and re-signed every time a change is encountered, navigation schema is signed off on once taxonomy and site map are decided, etc. We use this framework to teach the client why it’s important. One of my favorite Creative Directors put it this way: “You don’t do design without a plan. It won’t matter how pretty, how amazing and flashy your site is; without a clear navigation and structure to your content (one that your users will enjoy using and find intuitive) your site will always fail.” I like that way of thinking, it puts the client in a frame of mind that A comes before B comes before C, even if all they understand is C.

DESIGN CHANGES

Let’s face it – design changes suck. Knowing that, these are most common, but often easiest to quench. Because every client’s a junior designer, they all want little tweaks. It’s important as a designer and developer that the client understand that every comp and wireframe is its own entity: every piece of that comp works with every other piece of that comp to make a working model. I know tons of creatives and they all say the same thing: don’t change the design, don’t tweak anything. Tell them what the root problem is and they’ll find the best solution. Often times clients want to make changes because things present deeper problems. Why did the client change the color? If it was hard to read, then there might be a better solution than the awful crap they did.

Because changes will and do happen, what is to be done? If the changes are page level, sure (barring a design destroying idea) it’s not too bad. A template level change is much worse – we’re looking at much larger, time consuming changes. Education, again, is the best medicine. Ask why a client likes or does not like an element. Explain why you made the design choices you did. It’s a shame that many designers must justify their designs, but there are a lot more people who don’t get it than do.

INTERNAL ISSUES

This is what the clients never see. This is the changes that get made in house. These are many times beneficial to making a great product go live, but often times the team cannot get a party line, cannot get with the whole program. In these times it’s best to follow workflow protocol. When good workflows are put in place this step rarely gets bogged down. Being as buttoned-down as possible internally with reflect on the work you do for the client as well as the perception of the group in the marketplace. Keep a consistent workflow and procedure in place and this will be the least of your worries when it comes time to change.