Leading a life with creative aspirations foremost in mind hasn’t always been the most productive or fruitful of endeavours. Meaning at times it can be quite frustrating. Add to that a level of technical detail I seem to need to keep my interest piqued merely adds complexities to a situation that, if anything, would benefit from less difficulty rather than more.

But it would seem this interest in type, and web fonts in particular, will be quite the challenge for me going forward. There’s no shortage of nerdy details to occupy my mind with for years to come. I’m actually quite looking forward to it.

And if that wasn’t enough there is also this thing I’ve recently been made aware of called font icons. “Font icons are awesome.” But more to the point of this post today, they are “accessible” (but they come with some things to watch out for, hence the quotes). And that really makes my dorky side drool. Details, details, details…

Some background on Font Icons

For some background on Font Icons read A List Apart’s March article The Era of Symbol Fonts. But, I should state before moving on, short of briefly poking around in Adobe Illustrator — a vector drawing program (vectors, or more accurately lines, make up nearly the entire basis of these Font Icon things) — and exporting that drawing to a Scalable Vector Graphic (SVG), then importing said drawing to IcoMoon to get my Font Icon so I could do this with them (the email icon located at the bottom of the linked to page), I have virtually no other useful experience with Font Icons. However, I was asked to review the resulting research the Fluid Project conducted concerning their use of Font Icons going forward to see how what they found translates. Here it goes. But I do recommend those interested in implementing Font Icons to read their research. It’s very (read: impressively) thorough.

This is a really complex issue. One that I’m not at all shamed to admit I don’t have a comfortable grasp on fully understanding at the moment. Which does speak to the learning curve involved in using Font Icons. It can be challenging to wrap one’s head around, at least it was for me. And I’m still learning.

You may wonder, like I did, why the Fluid Project would be interested in exploring something such as Font Icons. Aren’t they looking for solutions to problems they don’t really have? Why aren’t people content standing still?

It’s a bit of both

Seriously, as with almost anything else there isn’t a simple yes or no answer.

Yes, with respect they already have a working solution for this issue in place with User Interface Options (UIO) (the feature on the top of each page on this site, should you be reading this in a browser, that lets a user accommodate the interface to suit their needs/ preferences better) specifically. Via lots of tiny raster images — which brings to mind why they weren’t using sprites, I don’t know for sure, so I’ll avoid speculating (it really doesn’t matter any more, keep reading). However in terms of efficiency, even with sprites, there is still an amount of “waste” inherent in the process. I’m of course referring to all the various images in their different “states” that they would need to give a user even the most basic visual feedback. Fonts Icons could potentially better serve this end.

Point being Font Icons are essentially no different than any other text on a webpage. Aside from being “custom” bits of representational graphic information, which suffer from much the same problems images pose (where accessibility is concerned, more below), but they, unlike raster images, are “stylable” with CSS — everything you can do with CSS and text you can do to/ with Font Icons, “change opacity, rotation, add strokes, gradients, shadows, etc.” And while I bring it up, yes SVG images can be styled with CSS in certain circumstances, but for reasons outlined in the Fluid Project’s research concerning SVG specifically, Font Icons are preferable.

With UIOs theming feature alone (changing the interfaces colours for contrast perceptibility), instead of having to create and maintain images that reflect specific theme changes you can inject some simple CSS code into your style sheet to reflect theses alterations with the single Font Icon.

Font Icons are scalable

And like with regular text Font Icons are scalable. They are directly tied to the page’s font-size property. So as the text grows, these icons grow and remain every bit as “crisp” as any other letter form surrounding them. In an age of hi-DPI displays and laying out webpages with ems (essentially meaning Font Icons are directly related to a users specific browser’s text size preferences) a web author/ designer/ developer can’t possibly know how a user is consuming their content, this can theoretically be a welcomed addition to any web creators tool kit.

Towards accessibility, using images can be a little tricky. But with some care viable alternatives can be offered. Just like using the alt attribute in your mark-up for your images, to offer users a text alternative to viewing the image, you can use some Web Accessibility Initiative Accessible Rich Internet Application (WAI-ARIA) code for adding visually hidden descriptive text to a Font Icons through the use of;

<div aria-label="Descriptive text describing the Font Icon" role="img"></div>

This solution was fleshed out (hat tip to Heidi Valles) and tested on a variety of screen readers (another hat tip to Heidi and Justin Obara), Job Access with Speech (JAWS), Non-Visual Desktop Access (NVDA) and VoiceOver. And in various browsers (Firefox, Chrome and Internet Explorer 8, 9 and 10) for non-presentational Font Icons. Apparently Firefox with NVDA, I believe, had an issue not voicing the descriptive text with the role="img" missing. But it worked once it went in.

The use of ligatures

Which brings me to the use of ligatures. This aspect of Font Icons is what I’m having the most difficulty understanding. But ideally, in efforts toward “accessibility,” this would be most desirable. In the sense using ligatures with Font Icons, as I understand it, is theoretically the text will remain text “underneath” the visual rendering. Meaning in a web browser the combination of characters will cause those individual characters to be replaced by a custom glyph, or a Font Icon in this case. Why should we care? Screen readers will read ligatured text as text and not glyphs.

But of course in practice using ligatures to implement Font Icons is still somewhat limited. Browser support is still sort of problematic. As far as Internet Explorer is concerned, as of this writing, only the current version (version 10) supports ligatures. Multiple language support, or in the very least, ways to create and edit ligature metadata (the information ligatures need to even display) for multiple languages is limited. And ligatures alone may not be descriptive enough to portray the intent of the Font Icon. As you are only allowed a single “word,” in the sense no spaces are allowed, in a ligature. But, that said, ligatures are pretty cool, indeed.

And with all this ligature talk spoken both the Fluid Project and in my limited experience using Font Icons we’ve both come to the conclusion the easier and more reliable way to use/ inject Font Icons into a web design is to use CSS rather than through the use of ligatures.

Wrapping it up

So if you skipped directly to this, the not so drawn out point I was getting at is if the Fluid Project has use cases for simple, monotone (but should it be appropriate Font Icons are “stackable” for the sake of more complex styling) icons they have made a pretty strong case to use Font Icons, through CSS (not ligatures), going forward. I’ll be extremely excited to work with the Fluid Project and Font Icons as soon as their proposal is implemented into reality…

Originally posted at Abledaccess.com

Habit is powerful thing. I’ve spent virtually the entire time on my computer “fumbling” around with various input devices. Specialty mice (specifically programmable mice), not so special mice (the Apple hockey puck comes to mind), trackballs (I hated using a trackball), Wacom tablets and most recently an Apple Track Pad. All had their pro’s but each had a lot of con’s. Mainly in terms of my ability to use them. More often than not, the trackball especially, they were just awkward for me to use in any productive fashion.

The irony of it all is the most productive means of access was sitting right there in front of my face, the whole time. The keyboard. And as time lapsed I was gravitating my use increasingly away from those various input devices I was trying to use to the keyboard without realizing it. Not because it was more natural feeling, rather it was just easier for me.

And in an even greater twist of irony, it wasn’t until Apple released OSX (Operating System Ten) Lion when I started exploring the keyboard as my “sole” means of input. And I don’t mean with common keystrokes — like Command + Q to quit and Application, say — to speed up my interactions with a computer, but by customizing certain OS dedicated “Keyboard Shortcuts” in the OSX System Preferences “Keyboard” pane.

In the System Preferences > Keyboard pane (as far back as Snow Leopard) and under the “Keyboard Shortcuts” option you’ll see a list of Actions Categories, if you will, on the left side of the window. Then when you click on a “category” you’ll get a list of specific actions, and the key combinations that perform the actions they correspond to. For instance, in Mountain Lion in said Keyboard Shortcuts pane the “Launchpad & Dock”, the highlighted “category” once you open the Keyboard System Preference on the left of the open window, on the right you’ll see both “Turn Dock On/ Off” and “Show Launchpad” with their corresponding “shortcuts”.

Under “Mission Control” (and this will only apply to Lion and above as it deals with OSX “Spaces”) I changed the “Move left a space” from Control (⌃) + Left Arrow (←) to Option (⌥) + Left Arrow (←) and  ”Move right a space” from Control (⌃) + Right Arrow (→) to Option (⌥) + Right Arrow (→) by highlighting a specific action and pressing return so the action will allow you to record the key combinations I suggest (or a different  one of your choosing). This will give you the ability to switch “Spaces” a bit easier. Which essentially means “swiping” left or right between open Applications that happen to be in “Full screen mode”. I prefer  my key combinations simply for the reason I use the smaller Apple keyboard and the keys I cited are very close to each other. Again, it makes everything so much easier for me.

Next under “Keyboard & Text” change “Move focus to the menu bar” from Control (⌃) + F2 to Command & Option (⌘ & ⌥) + Left Arrow (←). This way when you press that key combination the Apple () menu on the top left corner of your screen will highlight, or receive focus. Then with the left and right arrow keys you have the option of moving the “focus” to any menu item on the left side of the menu bar across the top of your screen. And once you arrive at a desired menu item use the down arrow to open up that menu list and keep pressing the down arrow until you arrive at the desired menu item. To select it simply hit the space bar.

Same deal from “Move focus to status menus” (those are the items located adjacent, on the right side of the top of your screen, to the “menu bar”) change the “shortcut” from Control (⌃) + F8 to Command & Option (⌘ & ⌥) + Right Arrow (→).

But by far the most efficient “Keyboard Shortcut” I’ve altered is for “Move focus to the dock”. This likely cuts a rather significant chunk of my day I’d spend switching between Applications, open or closed. I changed the “shortcut” from Control (⌃) + F3 to Option (⌥) + Down Arrow (↓). That’s seriously the function I use most on my computer.

And that’s essentially it. 5 simple “shortcuts” I use to make my day a little more efficient. But keep in mind, what makes these key stroke combinations so efficient for me is, as I said, is their proximity to each other and I use sticky keys — which hold down the modifier keys I need to press specific key combinations.

A sort of caveat: these “shortcuts” don’t come free of charge. For instance any of the Option (⌥) + Arrow Key combinations cause conflicts which various Application functions. The Option (⌥) + Right Arrow (→) when editing text will jump the cursor ahead an entire word. Versus just a single character should you press an arrow key by itself, had you not changed the shortcut. In Photoshop using Option (⌥) + Down Arrow (↓) while using the move tool duplicates the active layer. And in iTunes using Option (⌥) + Left Arrow (←) jumps back to the beginning of the song that is currently playing.

The good thing is once you change these options in the “System Preferences” those changes will override any setting the OS or an Application has set to do anything. I haven’t tested this out with any other commonly reserved key combinations, but I believe these modifications are reasonable, and in the year and a bit I’ve been using them I haven’t come across any issues, more than  what I stated above. Point being you have to weigh these things out. What’s more important to you? Find, and experiment with, your preferences. And never sit still.

This post is much longer than I imagined it would be. And it’s a lot more technical than I’d intended. And these “tips” are fairly specific, seeing how they are Apple centric, but I promised I’d document what it was I did to help myself. And that’s precisely what this is. A document detailing how I personally attempt to better my computer access through keyboard access. There you have it.

One last thing, I’m very interested in how “accessible” the various symbols I used in this post are. With screen readers especially. I have some testing to do. However should you happen to be a screen reader user, might you be so kind to leave a comment below, detailing, however briefly, your experiences with them are? Thanks a ton…

Originally posted at Abledaccess.com

With the first half of this year fully involved with my volunteer gig at the Fluid Project, and building Fluid Studios specifically, I was pretty overwhelmed at times. That’s not necessarily a bad thing. Or looking back on it now, it wasn’t. I learned a few valuable lessons. Most important of which was how lacking my CSS skill set was, and in some cases still is, in terms of thoroughness. And testing specifically. Namely with the dreaded IE — precisely with versions 6 to 8.

Anyway, as I said, it wasn’t all bad — albeit very frustrating at times (which comes with the territory). But I really can’t complain. I received a new appreciation and a renewed interest in CSS. I’m all in. With everything. And my approach, especially. It’s all about Object-oriented CSS and writing efficient code now. Gone are the days of writing a selector, then all the rules that apply to that single selector. Make your CSS work for you, not the other way around. (Do me a favour? Don’t look at the CSS for Fluid Studios. Thanks.) I’m still learning but I haven’t been this excited about poking out code in a long time. A really long time…

Toward that end, I’ve spent the last little bit of this year, most of December mainly, trying out Syntactically Awesome Style Sheets (Sass). To the point;

Sass makes CSS fun again [that it does]. Sass is an extension of CSS3, adding nested rules, variables, mixins, selector inheritance, and more. It’s translated to well-formatted, standard CSS using the command line tool or a web-framework plugin.

Farting around on the command line to see Sass’ worth is one thing. But making productive of said tool is quite another. Enter Codekit (which is much more than a web-framework plugin, or so it appears). And in recent weeks, I’ve really taken to using said tools, enjoying the time I spend developing for the web, and actively wanting to improve the CSS I write. That’s all that should matter, right? This is how I’m going to look at starting 2013, at least.

And sorry for the somewhat scattered post today, I’m rusty. I plan on resolving that soon into the new year. Stay tuned…

Originally posted at Abledaccess.com

But by far the most important one I use, that makes the time I spend on a computer much more productive and enjoyable, is the manner in which I use a keyboard.

As my physical ability has progressively changed, my needs — in the sense the solutions I use — have not. Well that’s not entirely true. I no longer need switch access scanning or mouse keys, but I still heavily rely on the keyboard, and sticky keys especially, to interface a computer. I can use two hands to type, but that can be challenging (working in Photoshop is the exception) so I don’t typically use both hands. But in an effort to speed up my productivity I don’t so much require said solution, as I much prefer to use it.

Which gets to my point, my most productive use of time, in terms of my access, is the keyboard. Most of the solutions I currently use involve these 90 keys that lay before me…

So the key (har!) to keyboard accessibility is something that is often referred to as keyboard shortcuts, or access keys. It’s these keys, usually through a combination of keystrokes, that give me a means of controlling a computer via a keyboard. These actions are mainly performed through the combined use of a modifier key (the Shift, Control, Option and Command keys on the Mac) and another letter, number, punctuation or function key.

And I, as stated above, use sticky keys too help my do this. All that means is when I press one or a bunch of modifier keys it remains pressed, which isn’t  at all what really happens but the computer remembers which key I’ve pressed and “holds” it, until I press another non-modifier key I need to tell the computer the action I wish it to perform.

This is where sticky keys play an all too important role. I typically only type with one hand. Which means pressing any combination of two or more keys on the keyboard, depending on where the combination of keys I need to press are related to each other of course, can be tricky to down right impossible. Sticky keys allow me to press a modifier key and, for all intents and purposes, it stays pressed (read: activated) until I press the other key I need to complete the combination for the action I need performed. I even use this solution for an action as fundamental as capitalizing the first letter of a new sentence. Pretty important, right?

Anyway I thought this a worthwhile post to write only for the fact my Mom, as she was “fact-checking” my last blog post, asked me how she could interact with a computer without a mouse? And this is essentially how I do…

Originally posted at Abledaccess.com

But in combing through various articles and Twitter links this morning I stumbled across a post written by Derek Featherstone, titled Awareness, that immediately had me contemplating both my Grandparent’s struggles. To be fair, I’m not sure they saw their disabilities as anything they “struggled” with, as it was just something they had to deal with to successfully live a life. But for the purposes of this post and what GAAD actually represents it’s nearly impossible, for me at least, to fathom their lives as anything but a “struggle.”

When both my Grandparents were young — my Grandfather was 3 when he was struck by a motorcycle and contracted Red Measles while in the “Fever Hospital” and my Grandmother was 7 when she was afflicted with Meningitis — they were each left with their disability’s. But in spite of such matters they lived out their childhoods and met each other at a social club organized by/ for the Hearing Impaired in Dundee Scotland as young adults. They were married in 1948, had two children by 1955, then immigrated to Canada in 1957…

As Derek put it “disability and the concept of accessibility can be confusing. Awkward. Uncomfortable. The first step to true understanding is usually awareness.” I’d agree. And, for the record, while I’m not a huge fan of the label of “disability,” I do recognize the need to use it. While it denotes a specific amount of difference, in terms of what is different, the fact that something has to be said towards any difference seems backward to me. In a perfect world calling attention to anything would be moot, we’d already have intimate knowledge of everything, however we don’t live in a perfect world, obviously. Therefore raising awareness is so very important.

And, much like Derek, I’m not convinced my interest in issues relating to accessibility on the web, at least, stem from what my Grandparents had to deal with. It’d be nice to claim, but would be entirely disingenuous. Honestly, my interest comes from a much more selfish place, being myself. And how accessibility issues affect me, as a quadriplegic. And if awareness is a goal of today I could tell you lots about what makes my life more difficult. And actions I take to improve certain circumstances. But in all fairness today isn’t about me. It’s about other people. And recognizing what anyone who isn’t you has to deal with in order to live a life.

That said, what I’m about to write has little to do with web accessibility. But it’s most definitely related. Insomuch as it has to do with assumption and ignorance. Web designers/ developers, whether forced to or not, make a whole lot of assumptions in any given day at the craft. Now I’m not bashing that fact, unfortunately it’s the nature of the beast, as we don’t typically have full access the entire gamut of devices we need to test what it is we build.

When I was in grade 7 (this would have been in 1987) my family, and my Grandparents included, travelled to the UK to visit family. Now this isn’t anything I often think about, but it’s always something that has stuck with me ever since. While in Scotland, and visiting my Grandmother’s sister, a woman — I don’t recall if this person was family or simply just a friend of my “Aunt” and Grandparents — in the matter of a few minutes, referred to my Grandparents, openly (and without even a hint of shame), as being “Deaf and Dumb,” A number of times. I don’t ever remember feeling such anger and disgust for someone I hardly knew.

My Grandparent’s being Deaf wasn’t ever a problem with anyone in my family. Which leads me to believe she wasn’t family. They’ve always been my Grandparents, period. And now some insensitive woman was, whether she realized what she was inferring or not (this, after all, was the convention from years ago, “Dumb” was a term used to refer to and individual’s inability to speak, I believe), was insulting them to their Grandson, right in front of their faces!

Both my Grandparent’s were extremely accomplished at reading lips. They knew full well what she was saying. Whether my Grandparents interpreted what she was referring to them as was even remotely similar to my interpretation, isn’t for me to speculate, but there was no mistaking my Grandmother’s reaction. I will never forget the look of embarrassment that came over my Grandmother’s face as this stranger spoke down at them. And, adding insult to injury, the way I remember the whole interaction, is this woman was speaking about them, not to them. Even though they were right there. Assuming they couldn’t hear her and/ or they couldn’t appreciate what she was saying hurt my Grandmother. And whether that is fair or not, I haven’t a clue. Point is, assumption hurts. Her’s or mine.

There was so much more I set out to write, but in the interests of getting this posted before this day runs out, I’ll conclude with this: my Grandparent’s were very kind, loving and intelligent people who overcame a lot of ignorance in their life, but never was it more apparent than here. When a 13 year old kid saw enough of a problem with someone’s remarks to be so infuriated that he so vividly remembers the incident a full 25 years later I think says it all!

Always remember your assumptions will invariably cause a reaction. Good or bad…

Originally posted at Abledaccess.com