Perth Web Accessibility & Inclusive Design Message Board › Cheat Sheets / Top 3 Considerations
Firstly, apologies it's taken me this long to type my notes from the 18 February MeetUp - just been snowed under at work and uni.
But at that meetup we decided that instead of making a full page cheat sheet per se, we decided to go with a "Top 3 Considerations for your role". So thought, depending on your role (Content writer; Developer; Designer; Project Manager / Strategy Developer), what would be three simple guidelines that would make the web just that bit more accessible.
So this is what we decided, I'd thought I'd post this up here, and after we get group feedback, I'll make up a blog post and factsheet that I'll host via the WA Museum, and also try to distribute widely through this group and networks.
== CONTENT WRITERS ==
1. Structure your content.
Before importing your content from word into the web CMS, please mark it up and structure it with headings, paragraphs and lists.
2. Stop putting text in images!
It may look pretty, but please try and separate text from images.
3. Be succinct, and explain technical terms and acronyms.
Stick to a point, and when you need to use more technical phrasing, don't be afraid to explain yourself.
== UI / UX DESIGN ==
1. Be mindful of devices.
No matter what the site is, don't forget it may be used across a plethora of devices, from phones to wide-screen monitors, and tablets to gaming consoles. Pay particular attention to forms, menus and not to disable pinch and zoom, even in responsive sites.
Ensure there is enough contrast to read or see what you've made.
3. Don't forget assistive technologies.
It's an easy step to skip, but do try and test your designs by using assistive technologies.
== PROJECT MANAGER / STRATEGY DEVELOPER ==
1. Set realistic goals.
Set realistic goals and outcomes, even if it's not possible to get 100% of things right within time and budget, and it's absolutely worth pursuing the best that can be achieved.
2. Make accessibility part of your strategy, not just a project outcome.
Website accessibility should be embedded into an overall strategy, and define what you want that strategic approach to achieve from accessibility. It should not just be tacked on as a project requirement or outcome - it should help inform the project.
3. Define your risks.
Honestly assess your risks, and what are the outcomes from pursuing good / best practice in terms of your project risk assessments.
== DEVELOPERS ==
1. Execute semantic markup.
Your CMS / code should execute semantic markup from your templates.
2. We ran out of time...
So we didn't quite get to finish the last two developer guidelines... Next time perhaps :-)
Thanks for sharing Morgan.
Geoff emailed me the following, in the interest of getting input from other parties, have reposted here. Tis great feedback:
I had a read of your cheat sheet you sent through.
Perhaps we could add for developers:
· Something about the use/misuse of tables
· Don’t hardcode styles/html that is hard to maintain
· Be aware of timeout limits
· Ensure you can use it using a keyboard only
Would appreciate your thoughts.
Would also be good as an infographic.