On this week’s show: Ryan and Paul talk to Robin Christopherson from Abilitynet about web accessibility and Dave shares Headscape’s experiences of moving to Google Apps.
Page zooming vs. text scaling
In show 169 we featured Cameron Moll’s article “Coding like its 1999“. In this post Cameron explained his decision to move from ems based sizing to pixels. He justifies this decision by citing the fact that all modern browsers have moved from text resizing to page zooming, as their primary resize tool.
Cameron’s position has caused some controversy in the web design community, with passionate responses from leading figures like Drew McLellan and Roger Johansson. Cameron’s original post also attracted some heated debate in the comments.
So why do so many object to this move away from text scaling and fluid design? Most of the arguments are the same as those that have been around for years. Fluid design…
- Adapts to varying amounts of content and different languages.
- Makes better use of screen real estate.
- Puts the user in control
- Prevents horizontal scrolling
- Adapts to alternative devices (such as mobile)
However, Molls critics also point out that page zooming is not support by IE6.
Cameron has responded to the criticisms in “The debate over page zooming vs. text scaling.” He argues against the principle of “one site fits all,” which underpins fluid design.
In my opinion this is a question lacking a black and white answer. Although generally I share Cameron’s view, we still occasionally build fluid or ems based sites depending on the project requirements and target audience. There are good arguments on both sides and neither approach should be dismissed.
10 web design rules you can break
What the discussion over page zooming shows us is that nothing is absolute. As human beings we like black and white rules, but actually those rarely exist. The web is full of articles about web design that layout rules for design, usability, accessibility and every other aspect of running and building websites. However, in truth no such hard and fast rules can exist.
Sure, there is best practice. There are principles of design, development and management we should use whenever appropriate. However, these should not be followed blindly. Sometimes meeting business objectives or users needs involves breaking these rules and doing something different.
This week the Web Designers Depot has released “10 Web Design Rules That You Can Break“. This post looks at some of these supposed rules and shows examples of sites that have successfully ignored them. The rules they have challenged include…
- Do Not Display the Horizontal Scroll Bar
- Use a Minimal Number of Font Faces
- Do Not Use Too Many Colors
- Make Your Site’s Goal Obvious
- Navigation Should Be Easy To Figure Out
- Stick to Web-Safe Fonts
- Don’t Have a Splash/Landing Page
In fact all of these ‘rules’ are actually very good advice. However, they should not be followed blindly. That is why I love this post so much. It highlights best practice, while at the same time inspiring people to challenge ‘the rules’ occasionally.
Grass roots viral marketing for ordinary people
While we are on the subject of challenging preconceptions I would like to draw your attention to a post on Sitepoint entitled “Create a Buzz: Grassroots Viral Marketing For Regular People.”
I am constantly amazed at how many website owners (and even web professionals) believe that viral marketing and social media are the easy answer to their marketing needs. As the article points out viral marketing is far from easy and if you don’t have a massive twitter/facebook following it is even harder.
Although the article is essentially a guide on how to be successful in viral marketing, it does not sugar coat the realities. It points out a number of harsh truths…
- You need a product or service that people actually care about.
- You need to reach a major influencer to have any hope.
- Don’t just rely on a single outlet (such as YouTube) to get your message out. You need lots of avenues of attack.
- A lot of it is just down to luck!
If your message doesn’t offer people something they need, something they want, or an opportunity to support something they believe in, you may need to rethink a viral campaign.The truth about viral marketing is that many times it comes down to being in the right place at the right time.
Information as a task
In order to prove I am not the only skeptical, cynical and despondent person on the web this week, I would like to refer you to a post by Gerry McGovern entitled “Information as a task“.
This barely disguised rant about working on large pubic sector and corporate websites, resonates with my own experiences. The heart of the article is a call to website owners to stop putting up content unless it helps users fulfill a specific goal. Its a simple message but one often ignored.
Website owners too often start the process of deciding on content by asking “what do we want to say?” rather than “what do users want to know?” Gerry writes…
Many organizations have a strange attitude towards information. Its creation is nearly always disassociated from its use. Information is rarely seen as useful or purposeful. It’s just there because people need it. It doesn’t help you do things. It’s simply there for you to read just in case you need some information.
He goes on to write…
Organizations have a fabulous capacity to produce massive quantities of low grade, aimless, pointless information. Much of the information that should have a point is useless because it is not useable. People don’t understand it. They can’t act on it. It doesn’t result in someone completing a task.
I couldn’t agree more. Before any content is added to a website the author should always ask “what task does this help users complete?” and “is this task actually one real users will be trying to do?”
Interview: Robin Christopherson on Accessibility
Ryan: Now here with Robin Christopherson from AbilityNet. Good Afternoon! How are you?
Robin: Yes, really good thanks, yeah!
Ryan: Fantastic! So for anyone who doesn’t know you or know what you do, could you explain that to us please?
Robin: Thank you very much. I am head of accessibility at AbilityNet and my team basically deliver consultancy and free advice and information on Web and software accessibility. And AbilityNet for people that don’t know are a charity and we do accessibility services but also assessments of disabled people in the home or in the workplace or in education and making sure they’ve got the right kit to access a computer and the Internet, etc. most effectively. And we’ve got now 800 advice information number, etc. so all things technology and all areas of disability. That’s who AbilityNet are.
Ryan: Fantastic. And you’ve just given a talk on “Designing for All in a Web 2.0 World” which was quite an eye-opening presentation I think for a lot of people who may not have seen or used a screen reader before. What was quite amusing was when you first started using it the rate at which your screen reader started speaking the content of the BBC home page, I don’t think any of us could understand it.
Stanton: I had no idea what it was saying at all.
Robin: You actually would tune in relatively quickly because when I’m working on the computer at home sometimes I don’t have it on earphones so it’s just kind of coming out through the speakers in the office and my wife just having walked past a few times now can get it so I think you probably kind of tune in. Maybe it’s a bit like the black faces and the white candlestick, you know you suddenly kind of see the other one and you kind of click. Yeah, when you’re reliant on speech output you don’t want to be sitting there twiddling your thumbs after having left the synthesizer at the default speed that you get when you install it out of the box. So you want to crank it up and not have to be waiting for it to finish what it’s saying.
Ryan: So you kind of highlight some of the issues from quite a site impairment point of view but there’s also a lot of other considerations that people designing websites should be looking into. You mentioned dyslexia or cognitive impairment. How do those type of conditions affect the way people use websites?
Ryan: OK. What should we as, I suppose now that you mentioned typography being extremely important, what should we as designers and developers be doing to improve accessibility and day to day. I know it’s a very loaded question and there’s lots and lots of things we should be doing but as kind of a minimum we should just do all the time, every time we build a website, minimum we should be doing and then before we take the next step to really drive it home. What’s the minimum things we should be incorporating?
Robin: Um, there are some low hanging fruit. You know, there are some things that you could look at any site, any existing site and clean up: alt tags on images, and a decent heading structure, and make sure that the text resizes, that sort of thing that shouldn’t be too difficult to implement. On anything new that you’re building you really do need to get scripts with the WCAG, the Web Content Accessibility Guidelines, and the new version has come out last December to update those significantly, WCAG 2.0, and those are applicable to all the new technologies that are coming out, etc. and there’s really no shortcut to really kind of internalizing, digesting those and just letting them inform your every day practices in what you do, you know. They impact on everything from the wireframe right through to UAT and go live and also post go live maintenance and that sort of thing so you really just need to make sure you’re one of the web designers that have got with the program and you’re not doing the old bad habits of fixing everything to make it pixel perfect and doing lots of hacks to make it look OK in different browsers and that sort of thing. Luckily we’re in a much more standards compliant world now than we ever have been so you can really adhere to standards and only have to do minimal tweaks to make sure that things look relatively OK right across all the range of browsers and we’re asking that you go further still and you consider handheld devices and you consider Web TV as well as people with different impairments and that’s really going to significantly increase the customer base that you are going to be enabling to access your content and if it’s any kind of website with a business model with a revenue stream, right through to a site that’s an e-commerce site, you absolutely can’t afford to ignore accessibility in such a tough and competitive online environment.
Ryan: Yeah, especially with there was that Legal & General case which you mentioned earlier. They redesigned their website to be more accessible and had some quite good results with that, didn’t they?
Robin: Yeah, I mean this is an ancient example now. We helped the Legal & General in 2005. We did disabled user testing on the accessible relaunch and yeah, I mentioned that one in the Q&A at the end because most people will have heard of that one if any and they had staggering ROI. They had a saving of 200K per annum on site maintenance. They had an increase in online sales almost instantaneously after the relaunch of 90% and that kind of indicates that there was an audience out there that was knocking on the door before but couldn’t get through because of lack of platform compliance or lack of accessibility with the range of assistive technologies that people were using. Other people couldn’t tweak the browser to make the text size larger or impose their own color preferences. So there was an audience out there waiting and as soon as the site was relaunched and had opened the door to all those people, there was a step change in revenue. So, but there have been lots of cases since as well as cases that have shown the danger of ignoring legislation. You know, the Target case in The States where they thought it would be cheaper to be fined than to retrofit their site but when it came to it in the end they lost obviously, because they were in the wrong, and they were fined and they were also told to retrofit so they made the bad decision there and had loads of really bad PR as well. That sort of thing is going on over here but it doesn’t actually reach the court, they are settling out of court and part of that settlement is anonymity, a requirement for anonymity so we don’t have headlines over here, but there is litigation going on. So, there are the carrots and the sticks and all of those things have got to be an overwhelming case for getting with the program and becoming one of those Web developers who are able to build accessible websites which are being stipulated so often in tenders these days. You can’t work with the public sector without being able to create accessible sites and accessible functionality.
Ryan: Yeah, I work in the public sector myself as a full time developer so our baseline is it’s got to be AA compliant with WCAG2, have got to comply to the SENDA, the Special Educational Needs and Disability Act. Not so much the PAS 78 guidelines but I believe those are becoming the British standard, or are rumored to be.
Robin: Yeah, I mean it’s dragging on a bit, but it is going be sometime this year. I think probably Q3 this year and it’s going be a BSI full standard, BS 8878 and Julian and the panel including John Gooday from AbilityNet are on that again authoring panel. I think that one thing that is essential, is really important in assuring real life accessibility is testing. So, any web designer, any organization that have internal guidelines, style guides, etc. should have accessibility built in from a checkpoint or a good practices level but you also need to have a range of testing tools, whether it be the accessibility toolbar or some sort of accessibility checker. We can’t all afford an enterprise accessibility checking tool, but if you can they can be extremely useful from a monitoring point of view and ideally you’d have end users involved. So within your organization, if you’re a large organization or otherwise go externally to an organization like AbilityNet to get some end users looking at your content and making sure that it’s not only accessible to the guidelines but it’s also accessible in reality. We did some lab testing for a site that was strict AA about four months ago and 90% of the tasks weren’t completed by the testers because the AI was all over the place, the usability. None of the guidelines had been contravened but it was an extremely inaccessible site for people for a number of reasons. It’s an acknowledged fact that there are a lot of issues outside WCAG that you can’t really document that are specific to a site and the general layout and presentation of that site and the architecture, etc.
Ryan: Sure. So you mentioned testing there. Is there anything say that any of our freelance listeners that may not be able to afford a specific software, any quick and cheap kind of guerilla usability testing, that kind of stuff they can test for accessibility as well?
Ryan: In your presentation you talked about CAPTCHA still being a huge problem for accessibility and some visually impaired users can’t even register on a site. I also noticed that there was a kind of hidden extra link if you’re using a screen reader that nobody else really sees but you pick up on that once you go through with a screen reader. Are there any other kinds of sign posts that we should be putting into our sites like “Skip to Content” and things like that, that make it beneficial to visually impaired people or visually impaired users or people using screen readers?
Robin: I mean there will be a lot of other people as well, keyboard only users, when they gain the keyboard focus a lot of skip links become visible. People using Web TV, set top boxes often don’t fully support styles and a lot of those things become visible and they are in effect keyboard users. You can go over the top on skip links for example I’ve seen ones where there were like eight skip links and basically that’s a nav in itself, so you really need one at the top that says “Skip these skip links” or something so that is, you can kind of go overboard but yeah there are lots of little tweaks that you can do that make getting around a page, getting around sections of the page that are going to be hugely beneficial, but just doing something as simple as putting headings in, using the landmarks that ARIA offers to identify key, the top of key sections of the page are going to be hugely useful, not just for blind users for example but they are meant for a range of other user categories as well that would benefit from them.
Ryan: Could you talk a little bit about ARIA and how that’s beneficial for accessibility?
Robin: It’s relatively early days really and the support for it is pretty minimal at the moment. You have to have the very latest version of only a number of screen readers and the very latest version of Firefox, IE8 isn’t quite so good at having fully implemented ARIA support. ARIA stands for Accessible Rich Internet Applications and it’s basically the answer to the fact that WCAG, even WCAG2 hasn’t got a huge amount in there from a developing point of view. It’s more of a “Now let’s check the thing you’ve already done” point of view. But also didn’t define a standard for browser developers and AT developers, Assistive Technology developers, to interface and like an API almost and so ARIA has a number of things. Being able to define controls and their role and their status that you could never have done before in a browser. Slider controls in a media player for example a bit like in media player, Windows Media Player, but online in a, just as an embedded control in a page, that has never been possible to be made accessible before. Popup menus and that sort of thing before would have been done in styles or DHTML and that would be very problematic but with the new ARIA way of implementing them as long as you’ve got the right browser and the right AT then that is just like doing it in a desktop environment.
Ryan: One of the tips that you demonstrated on stage was for mobile devices. For the primary navigation one of the internal wars that’s always waged with me is “Should you put the navigation at the top or the bottom of the mobile page?” so that the mobile phone reads it from top to bottom every time the page loads and you showed that this site had the primary navigation in a dropdown menu.
Robin: Yeah, that’s how they chose to implement that as a dropdown and that is very cute implementation. That’s a good choice I think because you’ve got the nav there but it’s literally just one item or two items with the select button. Obviously it would be problematic if it was just a dropdown that was auto-fired for people that just arrowed down it without doing alt down arrow because that’s very a inaccessible implementation of a dropdown box but you’ve just got two items which you have to get over. If you had the nav at the bottom and you wanted to use the nav, then you’d have to get to the bottom and in some browsers there isn’t a quick way of doing that. On my mobile phone, the browser that comes with the Symbian operating system, WebKit I think, the screen reading software talks that I’ve got on my phone. I can literally just arrow left and right or up and down through items on a page, just like tab and shift-tab, that’s all I’ve got. So there’s no way of getting down to the bottom of a page to get to the nav so I would probably on balance having it at the top that in it is two items to get past. If you don’t want to interact with the nav it’s quite an elegant solution really.
Ryan: Are there any major issues with the predominance of touch user interfaces coming through now? I would think that using a mobile phone, the tactile feedback of the buttons is quite important or am I wrong?
Robin: Yeah, I mean we’re concentrating a lot of people who are completely blind but you’ve also got people with vision impairment and people with motor difficulty for whom iPhones are a non starter really so any kind of touch screen interface where it’s the entire interface, it’s not as if it’s an optional extra way of doing it. In Windows for example there’s going to be a lot more touch and multi-touch stuff going on in Windows 7. When apps use that as the only way of doing something, that’s when accessibility is going to become a big issue. There needs to be always an alternative way. Alternative to drag and drop for example of doing things for people with a vision impairment or can’t using a pointing device, etc. So as long as there’s a redundancy there that’s fine, which there isn’t in the iPhone.
Ryan: OK, that’s great. Just to finish up, is there a, do you have a list of things that you see regularly that are counterproductive to accessibility that you can recommend for our designers and developers to just try and stop doing or try and do better, these are kind of like my top five tips, yeah common mistakes type thing?
Robin: Yeah, if you go to AbilityNet.org.uk/webresources then one of the things we’ve got in there is top five tips and top five sins, that’s one of them. And another one is a top ten checklist of things to do. Which implies that if you do them, then um, well if you hadn’t done them like label images properly, then that would be a sin. So follow the check points, those ten and those are ten things you can avoid sinning on. So yeah, there’s a number of resources on there. Other sites that I would definitely recommend to people for getting to grips with accessibility would be WebAIM.org and they go from the very basics right through to really quite advances. Accessify.com is brilliant because they’ve got of information but also a lot of forums as well so you can kind of talk with other guys getting to grips with it. I would point you at the source of the WCAG guidelines but actually they’re kind of not the best place to start but I mean everyone who knows about accessibility knows where that is anyway which is at w3.org/WAI. But yeah, WebAIM, Accessify and our site are good places to go.
Ryan: Fantastic! Well thank you very much for your time!
Ryan: It’s been a pleasure talking to you.
Robin: Thanks ever so.
Thanks goes to Todd Dietrich for transcribing this interview.
Review: Migrating to Google Apps
It’s something we’d been considering for a while, we’d weighed up the pros and cons and finally took the plunge. The key benefits of Google Apps are huge amounts of storage, a quality web interface and considerable cost savings. There’s also the reassurance that Google is actively developing the product with regular updates and improvements that don’t require installing fresh software or waiting for a hosted service to upgrade. If you’re currently using POP to receive emails or are archiving locally, you’re running the risk of losing your history of emails, should a disaster befall your computer. Keeping emails in a centralised service and syncing with IMAP gives you the security of safe storage and the convenience of access from anywhere. This is where large storage allowances come in handy.
Setting up an account is easy. Google offers a team version with fewer features than the premium, allowing an admin to create users, email lists and try out the service. This is also great for demoing the service. Google provide a test domain for sending and receiving emails using your regular style company email address (firstname.surname@). Depending on how big your organisation / company is, it’s worth testing out a few accounts across as many email clients as people run. It’ll help knowing off the top of your head where various settings are to save on support time later.
One of the key features of the premium account is IMAP email import. This allowed us to pull emails from our current Exchange server straight to Google, server to server. You basically just provide Google with your current email login details and it takes care of everything. You can specify a bunch of email accounts to import at once, and if you have a super-admin login to your email you can grab everyones with one set of credentials. This didn’t work perfectly for us, a few accounts seemed to hang and never complete. If that happens, it’s worth removing emails from the server with large attachments and trying again. If all fails, the alternative method is to setup your Google account in your email client and just drag all your emails from one to the other. Might have to leave it going overnight if you have a big inbox! Once you’re ready all you have to do is point your domain MX record at Google and you’re done.
On top of the usual email setup there are a bunch of settings Google recommends for desktop clients to aid consistency with the web version. These help prevent duplicate folders for drafts, sent and trash cluttering up your interface.
Migrating Calendars and contacts is dead easy, Google provide tools to sync local calendars and contacts can be exported / imported.
The biggest hurdle in a switch like this is gonna be support. Unsurprisingly, some people don’t like change, especially when it concerns services as critical to productivity as email. They’ll need reassurances that emails won’t go missing and everything will be as easy as it was before. There will be a short period where emails could end up going to either your old inbox or your new one, but as long as you check both for a couple of weeks post switch, you’ll be fine. We did see an email or two arriving at our old accounts a week after the switch, this is due to caching of MX records, not to worry though, they’ll propagate eventually.
A different way of working
My favourite features of working with Google Mail are archiving and labels. Labels work in the same way as folders, except an email can have several labels at once. This can cause some confusion when using a desktop client, as emails will appear in multiple folders. When an email is deleted from the inbox or any folder in a desktop client, it isn’t deleted on the server. It may still have other labels and will still exist in All Mail. To delete an email from a desktop client it has to be dragged to the Trash/Bin folder. This is great for keeping a clean inbox with current / unhandled with emails.
Another advantage to having all your emails on Google’s servers is search. However fast your computer is, you can’t match the speed at which Google can search your inbox for that elusive message from last year containing critical info. Instead of using a regular desktop client, you can take advantage of Chrome with Gears for a hybrid web client / desktop app. This allows you to keep the benefits of the desktop such as offline email access combined with the familiar web interface.
Thanks goes to Todd Dietrich for transcribing this interview.