It’s nice. It’s clean, semi spacious, has a bed and a TV. I’ve noticed one thing missing though, and it’s kinda significant for people who travel with technology…
There are hardly any power points! There’s 1 spare behind the TV, and one behind the lamp that’s in use but that’s all I could find. I know more exist behind the fridge and the oven, in the bathroom etc. but I’m obviously not unplugging any of those.
So, I’m offering up my thoughts on power point placement in hotel rooms, serviced apartments, or places that people stay while on holiday.
Where would I place power points?
On both sides of the bed – 2 on each side please
On the wall, close to the TV, but not hidden (in addition to the ones that are hidden)
Close to the desk (if the room has one)
Putting power points in the places mentioned above should allow for charging and using of devices more than enough devices. If we could get some USB charging ports on the walls, that would be awesome too.
When I started Recreate Web in 2012 I wanted to make the web better. I wanted to help people and organisations create websites that work for everyone.
It’s been great. I’m proud of the impact that we’ve made in the last 3 years and grateful to our clients who’ve given us the opportunity to work on some amazing projects.
But there’s only so much I can do on my own.
So in early 2016, I will be joining forces with accessibility specialist and good friend Sarah Pulis. Recreate Web will become part of our new company called Intopia. Together, we will be creating digital solutions to make the world more inclusive and accessible.
Thank you to everyone who helped make Recreate Web into what it is today, whether by spreading the word, being part of the team, or by engaging us for services.
I’ve had a lot of fun, and learnt heaps along the way.
I look forward to continuing to work with you as Intopia.
My first real web ‘project’ was built in 2001. I was hosted on GeoCities, and coded it using Microsoft Front Page. I was 15, and I’d just finished a week long Web Development basics after school course at RMIT.
It was a very basic, ‘this is what the web is, and this is how you put something online’ type course, but it was enough to spark my interest.
I’d always known I wanted to work with computers, but it was after this course that it became clear to me that ‘working with computers’, for me, meant working on the web.
I started researching what I was told was the ‘language of the web’, HTML.
I got directed to the HTML 4.01 Specification, and then got kinda scared… There was so much information, and I didn’t know where to start.
I started by looking for somewhere to start, and the ‘What is HTML’ section seemed to make sense.
I started reading section by section from there down:
What is HTML?
A brief history of HTML
Authoring documents with HTML 4
Separate structure and presentation
Consider universal accessibility to the Web
Help user agents with incremental rendering
The 2 topics in the above list, ‘Accessibility’ and ‘Consider universal accessibility to the Web’ were my first exposure to what’s been my career for at least the last 5 years.
The “… authors should consider how their documents may be rendered on a variety of platforms…” kinda struck me.
What other platforms could there be? I mean, you view the web in your browser, right? At the time, I had no idea that the web could be looked at on anything other than a PC.
I stated searching for the words ‘accessibility web’ hoping to find out more, and stumbled onto this quote from Tim Berners-Lee:
“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect”. Tim Berners-Lee
I kept reading and researching, and what I came understand, is that the web has the power to change people’s lives. It has the power to remove barriers, and allow everyone to equally participate in society. And it’s our job as web developers and designers, as web professionals, to make sure that that can happen.
It’s our job to make sure that what we build is usable by all. Accessibility is not about guidelines or standards, accessibility is about people.
Today, Thursday 15 May 2014 marks the 3rd annual Global Accessibility Awareness Day.
Global Accessibility Awareness Day (GAAD) is a day dedicated to increasing understanding and stimulating discussion about digital accessibility and inclusion.
Personally participate and encourage your colleagues to participate in a GAAD activity and experience accessibility first hand.
Give #gaad some twitter love by following @gbla11yday, tweeting about your local event or your GAAD activities.
It doesn’t matter how you get involved, as long as you get involved.
GAAD in Sydney and Melbourne
A11Y Bytes are community events to raise the profile of and spark discussion about digital accessibility and user’s needs and preferences. This year, A11y Bytes will be held in both Melbourne and Sydney. Come hang out with us for an evening of short presentations that will help us learn and talk and grow together.
A11Y Bytes Sydney
Thursday 15 May
Come by at 6.00pm and we’ll kick off around 6.30pm
Shelbourne Hotel, 200 Sussex St, Sydney
This is a presentation I gave at the Web Directions Respond 2014 conference in Sydney on February 5th 2014. A link to a downloadable PowerPoint version is provided at the end of this post.
Hi, I’m Adem, I’m an accessibility specialist, and today I’ll be talking to you about what Responsive Web Design can learn from accessibility best practice.
Responsive design as I understand it is all about flexibility, and to kinda paraphrase from Ethan’s book (Responsive Web Design),
it’s about creating “…sites that are not only more flexible, but that can adapt to the media that renders them.” — Ethan Marcotte – Responsive Web Design
To me, if I was to define it, accessibility means providing universal, barrier-free and equal access to the web, and technology in general, for all users, regardless of ability, disability, browsing device or location.
So, like responsive design, accessibility is based around that same concept of embracing flexibility.
Adopting accessible and inclusive design practices can help produce more effective responsive designs.
And throughout the rest of this presentation I’ll giving you all some tips, as I prove that point.
Ok, so Zoom. The ability to zoom is extremely important to visually impaired / low vision users, who rely on the ability to engage text to be able to read the content.
We all surf the web on the train…., we use our phones, and we use our tablets. And I’m almost 100% sure that at one point or another we’ve all zoomed into something while using our devices on public transport. We’ll be wanting to look a bit closer at an image, or just make the text of a blog post that little bit bigger.
And I’m guessing that like me, many of you don’t consider yourselves visually impaired, just because you use the zoom, you just like being able to zoom into things when you need to…
And how annoying is it when that doesn’t work, when you can’t zoom in? I have to say, this is one of my pet hates, if I get to a page, need to zoom in and I can’t I go somewhere else…
Being able to zoom in on things is not only an accessibility requirement, it’s also great when you’re reading something on a small screen and need to make things a bit easier to see.
Following on from zoom, I’m sure we’ve all heard the term “Progressive Enhancement”. You’ve got a basic implementation of a site that works across most browsers, devices, and with a wide range of assistive technologies, and you add interactivity or enhance functionality when it’s supported by the device or browser being used.
I’ve used a non web example here, because I think this quote illustrates it quite well:
“An escalator can never break: it can only become stairs.” — Mitch Hedberg
they still work when the technology fails or there is a power outage, they’re just a bit less convenient to use.
Similarly, with progressive disclosure, you show only the information necessary at that point in the interaction. You separate information into multiple layers and only present layers that are necessary or relevant to the task being performed.
The means less clutter, and a website that is easier to understand and navigate.
We’ve all seen how twitter does this, they start with your feed, that has an expand link under each tweet.
By clicking that link, you get a timestamp, numbers of people that have retweeted you and a text area where you can compose a reply.
From an accessibility perspective, this is particularly good for people with cognitive impairment and vision impairment. And I know of people who’ll use the mobile versions of sites exclusively, because they find them easier to navigate and interact with.
Colour contrast is one of those things that people may not necessarily think about, but it can make a real difference to the effectiveness of a design.
We can be on the web anywhere these days, using any number of devices. You could be on your phone, your tablet, even your smart watch.
Now, if we take a look at the image, we’ve got it split in half, with someone using their iPhone to view a site while indoors on top, and someone viewing the same site while outdoors on the bottom.
While the contrast of this site is quite good, and things are still readable, if we look at the outdoor section it’s clear that the contrast has been lowered.
You could be in many different situations while browsing on your phone, an area of high light, or low light, indoors or outdoors or going through a tunnel on public transport.
In any of these situations, not having good colour contrast could make content hard, if not impossible to read.
Consistency and predictability is your friend
The easier it is for someone to use a website, the better their experience will feel. The visual design of elements should make it easy for a user to understand how to interact with them.
Simplest way to explain this is probably to talk about links. There’s no point in designing something flashy to act as a link, if no one understands it’s a link.
People expect links be underlined, or appear as a button, a tab, or some other type of obviously actionable element.
What we’re aiming for here is… Woo Hoo!
We want the user to enjoy our websites.
What we don’t want, is…..
That DOH moment, we don’t want people leaving our sites because they can’t operate our interfaces.
What I’m saying here is to basically to stick with what works, don’t re-invent the wheel. There’s no need.
Standard controls are keyboard accessible & touch friendly
I’m sure we’ve all encountered something similar to what’s in the screenshot. You’ve got the standard HTML select box, how that’s displayed on an iPhone and how it’s displayed on an Android device.
And here you’ve got the standard HTML select box, and a version from one of the UI frameworks.
And you’ve probably all heard that an important thing from an accessibility perspective is to make sure that things like form controls, navigation are usable with a keyboard.
But you may not know, that using the standard HTML elements for select boxes, buttons etc gives you cross device, cross platform accessibility for free.
Because standard controls inherit the native accessibility features of which ever platform they’re being used on. That means a lot less development work, as the interactions have already been implemented.
Touch, Keyboard, even screen reader the standard controls will work.
And I’ve got a demo of the standard HTML select vs the UI select box, recorded on my Galaxy S4 running Android 4.3 using Firefox.
So, as we’ve just heard, for the standard control, all the options are announced, and the fact that the control is a combo-box is clear.
Whereas with the UI framework version, as we heard was Mustard button, which provides absolutely no context that there are any other options available.
Who’s seen something like this before?
You’ve just done a search, or you’re moving through a list of products and when you get to the bottom there’s the list of linked page numbers you use to move through pages.
Now I’ve got fat, ‘homer like’ fingers, and as hard as I’ll try, there is absolutely no way that I’ll be able to hit the number I’ll be aiming for, not at that size, and such a small space separating each number. No chance.
Sometimes text can be big enough to read, but too small to touch. Larger touch targets are important to make sure that people don’t hit the wrong thing, and especially important for those dexterity problems or who cannot see the screen.
If you’re using something live VoiceOver on the iPhone, you move you finger around the screen as it reads what’s underneath it, you tap to select, and then you double tap to activate what you’ve selected. So if you haven’t got enough space between targets to select the right things it’s going to get quite frustrating quite quickly.
Thinking mobile first is a good solution to this problem, because you start by thinking of targets in terms of touch first, before moving to desktop interactions.
An accessible, standards based foundation makes doing responsive easier!
Let’s take another look at my definition of accessibility from earlier, “providing universal, barrier-free and equal access to the web, and technology in general, for all users, regardless of ability, disability, browsing device or location” and focus in on the “browsing device”.
This could be a web browser on a desktop PC, it could be a bowser on your phone or tablet, or it could be a screen reader or a screen magnifier. It doesn’t matter, if the foundation of your site is built with web standards, if you’ve used properly structured and semantic mark-up, your content can “respond”, it can “adapt”, and it can be flexible to the needs of the user, regardless of the device they’re using or the context they’re using it in.
That’s it, thanks for listening.
Download PowerPoint slides
You can also Download the PowerPoint slides to this presentation. Note: I’ll be making accessibility updates to the PowerPoint version over the next couple of days.
9 May 2013 marks the 2nd annual Global Accessibility Awareness Day (#GAAD). The day is dedicated to getting people talking, thinking and learning about digital accessibility (web, software, mobile, etc.) and users with different disabilities.
While the target audience of GAAD is primarily the design, development, usability and related communities, the events are open to anybody who may be interested in the topic of making technology accessible and usable by all.
Events around Australia
A number of events will be held across Australia in support of GAAD:
Turn off your monitor and browse the web with a screen reader
People who are blind or vision impaired can used technology call a ‘Screen reader’ to use their computer or browse the web. A screen reader is a text-to-speech application that reads out what appears on the screen to the user.
WebAnywhere is a screen reader that can be used by simply visiting a website in your browser. To try WebAnywhere follow these steps:
VisionSim for Android and VisionSim for iPhone/iPad (free mobile apps) see the world through the eyes of a person experiencing one of nine degenerative eye diseases including: macular degeneration, diabetic retinopathy, glaucoma and cataracts.
We hear some strange things working in the accessibility space, like “the brief was to rebuild, not to improve; accessibility enhancements and features are out of scope”.
Now, when I first read the above in an email I was a bit taken aback.
In fact, I had to read it a couple of times before it actually registered.
I mean, it is 2013, right? Right? 2013…
So how is it that in 2013 we’ve still got agencies referring to accessibility as “enhancements” or “features”?
Let’s think about the steps in the standard publishing process for a large organisation:
Identify campaign (or tool, idea, etc.)
Draw up requirements
Send brief to agency
Agency develops concepts
Review concepts and decide which to proceed with
Agency builds campaign to concept
Review build (usually done by briefing stakeholder)
Advise web team e.g. “Hey guys, we’ve got this campaign coming up…”
Agency provides campaign collateral, tools, assets, etc. to web team for integration
Where in this process does accessibility fit?
The correct answer is: throughout the entire development process.
But we all know this is not what happens. More often than not, accessibility is not even thought of until the final step, when all the assets have been provided for integration.
Why it is like this?
Right now accessibility is not ‘front of mind’ and is not considered by anyone not working with or around it on a day-to-day basis.
I imagine some of you are saying “But I employ a web/digital agency, they should know this stuff right?” You’d think the answer to that question is yes, but it’s not really that simple.
Good design takes time.
In today’s era design/creative agencies are almost like production factories; where in order to win work while cutting costs, agency executives force staff to do more with less (more projects in less time). This means good designers and developers do bad things, cut corners and make compromises that they usually wouldn’t.
The aim of the game becomes quantity, speed and profit – it’s about the amount of work you can do and the lowest cost to gain the biggest profit.
With cut corners and compromises comes a reduced quality of work.
Couple that with the fact that accessibility is not front of mind for the client, which means accessibility requirements don’t even make it into the brief, and you’ve got the answer.
So, what can we do about it?
You may not think there’s much you can do, but there is, and it’s surprisingly simple. The secret to success has two key components – the brief and the review.
Agencies work off briefs, they work off requirements, and they work to achieve the goals or outcomes that their clients set for a specific project.
Accessibility doesn’t “just happen”, there’s only so much that can be done by accident, and semantic HTML only gets you so far.
Accessibility needs to be planned for and thought about up front. That means including it as a requirement in your brief to your agency, so they consider it before concept development, before the design stage, and well, well before anything is delivered to your web teams.
Once accessibility is included in the brief it becomes about the reviews.
The agency takes the brief, develops concepts around it and provides those concepts to you for review.
The process is followed as usual, with one key difference: accessibility is a requirement that can be tested, and the agency can be held accountable if they don’t deliver.
If they don’t produce an accessible product (design or tool or whatever), then they haven’t fulfilled the requirements, which means they haven’t hit the brief.
That’s why the reviews are vital.
Concept review, design review, and build review are all so important. The Web Content Accessibility Guidelines (WCAG) give us a set of testable criteria to check against, which makes things easier on both sides. The client can test and so can the agency.
Take the time to conduct the review and ask the agency to provide the results of their testing, because if they say they can build it, they need to be able to properly test it.
Ongoing accessibility is the end goal
Accessibility may not be front of mind, but more often than not there’ll be some type of standard requirements document that your organisation uses for each project.
Add it in, make accessibility part of your standard requirements document and dedicate time to it in the review stages.
It may not guarantee accessibility, it may not make it front of mind, but it should help your agency and your organisation produce accessible content.