Touch Screen Interfaces - a big 'Up Yours' to non-sighted users. Photo by Steven Rhodes

The iPad will hopefully be bundled with Apple’s Shining Knight of Accessibility dubbed VoiceOver; which should belay some fears of it being truly inaccessible, but I can’t help but think that visually impaired users are getting the shaft once again. Sure, you could plug in an external keyboard, and use the headphones to hear your way through the system, but that detracts from the portability and practicality of a device such as the iPad.

Accessibility and Responsibility

This weekend also saw the introduction of a Technology-based Bill of Rights for the Blind in the United States. Such a bill would put some limits on what devices government-run institutions can purchase, tending towards devices that can be used by every member of society.

The iPad is more than just a portable information consuming device, it is a powerful application platform. These apps, will they be accessible to visually-impaired users? Will there, or should there be guidelines towards creating accessible applications?
Creating hardware that is accessible is relatively easy compared to enforcing policy or creating guidelines in software accessibility standards. It’s been done for the web through the WCAG, but will we see a SAAG emerge any time soon?

This problem of neglecting the needs of non-seeing users has its roots in the touch interface – it’s a flat, almost-non-tactile surface. You can feel it’s there, but you can’t feel where it begins, ends or is different.
As the hype machine accelerates to our material oblivion, we’ll see more touch-based devices enter the market – devices founded out of jealous and incompetent mimicry for the sole purpose of making money. Do you think these competing devices will be coupled with an Accessibility plugin? Highly doubtful.

So, what can we do about not leaving the visually-impaired behind in our gadget-driven pursuit? Well, for one, the visually-impaired will buy devices they can use effectively. For truly holistic user interfaces, what we really need here is a miracle, and I’m not necessarily talking about restoring sight to the blind.

Waiting for a miracle

The majority of possible solutions could be ones born in Sci-fi, such concepts as:

• Tactile display-surfaces,
• Retinal or Visual Cortex Implants,
• and the unholy-grail: The Neural Interface

Tactile display-surfaces

Imagine a molten-glass-like surface, cool to the touch, that could grow out of the surface towards the user as the visuals underneath it required these height differences. A height-map would accompany the visuals, describing the pits and mounds of such things as buttons and form input fields. When you focus on a text field, a keyboard would rise out of the display surface. You would be able to feel where the home-keys are.
Think of this surface as a mix between an LED display panel and an Refreshable Braille Display. Apple have shown their commitment to visually-impaired users by supporting Braille Displays and creating such wonderful software as VoiceOver: I wonder if they’ve filed a patent for a truly tactile display surface? I imagine it won’t be long before such a device is available to the general public.

Retinal or Visual Cortex Implants

It also won’t be long before ‘Visual Prosthesis’ becomes more than just a research term. Visually-impaired patients could have an electronic retina implanted, or instead opt for the Rolls Royce of artificial sight: a Visual Cortex Implant. By the time these implants become available, I reckon we would have grown out of our fad-like needs to use non-tactile touch screens, instead opting for the unholy grail of cyborgism: The Neural Interface.

The Neural Interface

No Sci-Fi attribution would be complete without a mention of Peter F. Hamilton’s epic:The Night’s Dawn Trilogy. In it, he described a neural implant dubbed a Sensevise – a full and recorded sensory experience was shareable to anyone else with the same implant. With such a device, gone are the needs of eyes and fingers if we can interface such experiences directly to the brain. Hamilton took the concept even further by describing a gene that would allow the bearer an ability called Affinity – a form of telepathy. As time has shown, it’s just a matter of discipline, imagination and believing the impossible possible before we ’see’ such advancements.

Back to Reality

In the meantime, let’s start getting realistic about including every member of society in these technology-driven times. If you create software or hardware, I implore you to consider those on the periphery of our ‘norms’ by creating holistic computing experiences. Accessible computing is good computing.

CSS Reset

Eric Meyer is one of the original Web Standards Gurus. His work is good, and pure, and great time savers for us minions. Case in point: Eric’s work on reset.css.

What reset.css essentially does is set a common foundation in all browsers by removing the browser’s default rendering of HTML elements.  This makes it easier to author a web document so that it can look very similar in each separate browser.

The problem

I’ve been happily using reset.css on many projects, never noticing along the way the time I’ve spent on redefining margins on <ul> and <p> elements – time that could have been saved by defining a ‘Sensible Default‘.

Here’s an example…

ul {margin:0; padding:0; list-style:none; /*etc*/}

Reset.css would set all Unordered-Lists (<ul>) to have no margins, and no list-style.  This was great for defining semantic menus in the navigation and footer blocks, but…
the rule would cascade! (DUH!) and each time I wanted to have default rendering of a <ul> I’d have to define it explicitly. This situation would be exacerbated for each case when an <ul> needed to be displayed as expected, e.g. in a sidebar:

#sidebar ul {margin:1em 0 1em 2em; list-style:disc;}

The situation

I started working with Christo on a Django web-app, where I basically had to handle the templates, HTML and CSS + Supporting Images. I was using reset.css as normal.
Christo started voicing his frustrations with having to rely on me to define each and every case where a paragraph was needing margins, or an unordered-list was missing its bullets. It came down to a point where he asked me to remove reset.css. My Standards Zeal kicked in and I refused it, saying I’d have to create more exceptions than the rule by not using reset.css.
It ended up in a stalemate, so I thought I’d open up the dialogue to the StackOverflow audience. I put together a quick question and waited 24 hours for the answers to roll in.

Enter: Sensible Defaults

It turns out that the practice of defining Sensible Defaults is a common Programming tip. (This just goes to show my lack of formal programming experience!) Defaults can save a lot of headaches, and this situation of mine was no different.

The solution

Christo and I met half way by overriding the Reset rules just for the content area.

#content ul {margin:1em 0 1em 2em; list-style:disc;}
#content p {margin:1em 0;}
/* etc */

This way I could rely on Reset.css to ease the styling of header and footer elements, and then reset the reset by providing default styling to any content items such as paragraphs and unordered-lists.

TLDR? A warning as a conclusion

So, if you want to use reset.css then please, do The Right Thing™:

• Don’t be an idiot and implement something without understanding it
• Define sensible defaults for where they’re needed.

That is all.

I’m not going to go into detail about it’s function, but what I will do is give a review, highlight its pros and cons and maybe even offer some mixins you can use.

Setting up

Installing LESS.app was a breeze, and being familiar with installing Ruby Gems, the command-line app LESSCSS was also swiftly installed.
My initial reasons for using LESS was to use the Mixin functionality, and create a library of common mixins I tend to use on each project. I was hoping that I could store this ‘common library’ in a central place and reference it from all my projects – this was not the case, as all LESS imports have to be sourced from the same folder.

Pros and Cons

In these 2 weeks of using LESS, I’ve noticed a few limitations – they’re not deal-breakers, but then I haven’t used LESS in a team-environment yet.

Pros:

• LESS Syntax is very similar to CSS, which makes it easier to use than SASS.
• Storing your common mixins in a separate file speeds up development on subsequent projects
• Non-invasive file monitoring means your LESS files are compiled as you save them.  No need for compiling manually.

Cons:

• No support as yet for some dynamic mixins that use proprietary properties such as Microsoft’s alpha(opacity) property
• Multiple comma-separated ancestral selectors are converted into multiple selectors, dropping the comma in the selector and repeating the rule each time over.
• Larger, more numerous imports and more complex LESS files take longer to compile.  I find I’m often refreshing my browser twice because I refreshed before the CSS was compiled.

Talking of a team-environment… everyone who touches the CSS would have to use LESS, else there’ll be some crazy merging going on when someone updates the CSS and not the source LESS files.

All that said, I’d recommend using LESS to anyone who’s working on their CSS independently.

Further exploration

The compiling side of LESS CSS must  surely be able to minify the output!  At the moment it dumps each property on a new line, leading to horrendously long CSS files with lots of whitespace.  (I’m a big fan of multiple properties per line for each selector)  I’ll see what I can find in terms of lessc options, but for now it’s not a big issue.

Momentum

After I subscribed to the LESSCSS Google Group and read through a few of the discussions, I noticed that there seems to be some momentum in the project, but not a lot.  There are plenty of new users asking questions, but not a lot of active developer feedback. (Probably because cloudhead is working on LESS.js at the moment)  Maybe that’s a call for more community involvement in the app.  If you’ve done work on Ruby gems before, why not get involved with LESS on GitHub?

As promised…

…some mixins I use already:

Cross-browser border-radius, still no IE support though

.border-radius (@radius:5px) {border-radius:@radius; -moz-border-radius:@radius; -webkit-border-radius:@radius;}
.border-radius-top-left (@radius:5px) {border-radius-top-left:@radius; -moz-border-radius-topleft:@radius; -webkit-border-top-left-radius:@radius; }
.border-radius-top-right (@radius:5px) {border-radius-top-right:@radius; -moz-border-radius-topright:@radius; -webkit-border-top-right-radius:@radius;}
.border-radius-bottom-left (@radius:5px) {border-radius-bottom-left:@radius; -moz-border-radius-bottomleft:@radius; -webkit-border-bottom-left-radius:@radius;}
.border-radius-bottom-right (@radius:5px) {border-radius-bottom-right:@radius; -moz-border-radius-bottomright:@radius; -webkit-border-bottom-right-radius:@radius;}

IE 6 & 7 hack to support min-height

.ie_min-height (@height:300px) {height:auto !important; height:@height;}

Malarkey Image Replacement

.mir () {text-indent:-1000em; letter-spacing:-1000em; overflow:hidden;}

‘Off-left’ screen-reader supporting layer hiding

.off_left () {display:block; position:absolute; top:0; left:-9999em;}

Cross-browser Opacity – Missing IE filters: not supported in LESS yet.

.opacity (@opacity_percent:50) {-moz-opacity:@opacity_percent / 100; opacity:@opacity_percent / 100;}

Self-clearing for Non-IE browsers: Apply to :after the float container

.self_clearing () {content:"."; display:block; clear:left; visibility:hidden; height:0; width:0;}

60 chairs were laid out at the Bandwidth Barn tonight, we had wine sponsored by the CITI and snacks + drinks available.  We were expecting less than 60, but in the end 75 UX-keen people showed up. This meant a dash for more space and seating,  somehow we just managed to squeeze everyone in.

Why all the interest?

Phil Barrett’s infectious charm has a lot to do with it. He managed to scoop up Professor Uli Weinberg (who was on an African holiday) for a talk on Design Thinking.  I didn’t get to see or hear much of the Professor’s talk, but the audience seemed well engaged for the ~45 minute talk on collaborative and innovative thinking.  [I did notice the Professor was using one of those complex annimated image-map-type slides for the visual part of his talk.  I'm not sure I like those, they're very distracting!]

The caterers were waiting patiently for us after the first talk which ended at 8:30pm.  A lot of folks were networking and the general mood was pleasant.

Jason Hobbs, one of the Johannesburg SA UX big-wigs, then gave a talk after the break on “The door, the wind, the bird and the valise.”.  What had that to do with anything?  Well, Jason likes his Academia, Information Architecture and the thinking behind the thinking.  His talk tied in well with Prof. Weinberg’s, in that it was exploring the periphery of our UX thinking and research methods.  Jason highlighted Practice-orientated or Practice-led Research as a way to help build knowledge bases, but also to help us understand our respective UX disciplines and therefore apply more academic methodologies to our work.

User Experience and its varied disciplines are very much in their infancy, when compared to established industries such as medical or financial ones.  There’s a growing need for solidifying and understanding our work as Web Designers, Information Architects and User Experience Consultants from an academic point of view.  We’re getting there, albeit slowly.  [I'd love to do a specialised and associated degree on the subject(s)!]

Back to the event itself, sound clarity wasn’t great, some folks couldn’t hear our two speakers very clearly, partly because the air-conditioners were working overtime, and not really accomplishing much – our venue was busting at the seams.

What next?

We’re taking notes and had a lot to learn from tonight.  In terms of the next event, we’ve got some talks offered already, it’s just a case of finding a venue and a date.  I think we’d actually like to run two types of events:

• A chin-wag, social event for a small crowd.  Food and drinks
• Small evening conferences such as tonights.

We’re always looking for initiative from the SA UX community, so if you’ve got a talk, know of a decent venue or would like to help organise the next event, stand up and be noticed!

Until the next time…