Related
How can I ensure (or try to make) web access available for all - who may have a variety of disabiltes?
Any advice for any standards or web sites that could give me some pragmatic advice for the design of a site?
There are a number of considerations you need to address here, if your website isn't catering for a specific disability then you have to work on a broad range of features. In this situation the first thing you need to remember is that you sadly can't cater to everyone. Look at the list below and identify which of these disabilities you can sensibly cater for
Visual: Visual impairments including blindness, various common types
of low vision and poor eyesight, various types of color blindness;
Motor/Mobility: e.g. difficulty or inability to use the hands,
including tremors, muscle slowness, loss of fine muscle control, etc.,
due to conditions such as Parkinson's Disease, muscular dystrophy,
cerebral palsy, stroke;
Auditory: Deafness or hearing impairments,
including individuals who are hard of hearing;
Seizures: Photoepileptic seizures caused by visual strobe or flashing effects.
Cognitive/Intellectual: Developmental disabilities, learning
disabilities (dyslexia, dyscalculia, etc.), and cognitive disabilities
of various origins, affecting memory, attention, developmental
"maturity," problem-solving and logic skills, etc.
The easiest here is the Seizures, eliminate flashing / strobing content from your site, or more importantly if you cant put up a warning before displaying this type of content.
Users with Motor / Mobility issues may have problems interacting with content on your site that requires a high amount of precision, this can be helped by increasing the size of your UI elements, or allowing the user to resize these elements if needed.
Generally make anything clickable as large as is feasible and if you have elements that have features such as drag drop, make the drag handles large so the user doesn't have to click a tiny area.
Auditory is also a fairly easy consideration to make, at the least simply provide text alternatives to any media content your site may have, for larger sites using video then considerations such as sign language may be an option.
Visual is probably the most common consideration web developers need to make. Firstly partially sighted users may want to increase the text size to your page, so make sure that your UI can cope with this. Use clear and readable fonts and make sure there is contrast between the background color and the font color.
Color blind users may wish to change your site color scheme to meet their needs, you can find information easily on the types of color blindness and develop a couple of alternative CSS styles to meet these needs. Also a high contrast option for everything on your site may benefit partially sighted users.
Cognitive / Intellectual is one of the harder considerations to meet, so look at the individual disabilities. ADD for instance makes it hard for a person to focus and makes them easily distracted, considering this think about advertisements, they are designed to distract us and draw our attention, thus by limiting advertisements on your site you can get rid of the ones that flash and scream Click ME!.
Dyslexic users may struggle with reading huge chunks of text which also fits in with considerations for partially sighted people, here you could have an audio option so the text is read aloud to the user.
One more consideration here is the use of color in your website. It has been proven that certain colors can stimulate emotions, for someone with emotional or developmental issues using colors that are considered calming vs ones that excite (reds for example) may improve their experience of your website.
All of the above are design considerations, looking at the development (Code) next there isn't too much you can do, most of the considerations about your code are because of third party applications interacting with your site.
Generally make sure your code is well formed, correct tags / closing tags etc. Make sure it is valid HTML / XHTML / CSS etc if you can validate to the strict standards it wont hurt your cause. Tags such as links / images should have appropriate Alt text to describe what the element is, for instance alt="image1" is fairly useless to a screen reader but alt="Image showing ...... clicking this will take you to....." is useful.
If you can find some trial software grab yourself a screen reader, load up your website, close your eyes and try interact with it, its going to be hard but at least you can see how your user will interact with your site and more importantly you can use the screen reader to check your site actually gets read the way it should.
There are plenty of 3rd party plugins you can integrate with your site to aid your users too, so look into those, things like the option to magnify text or read aloud with just a click will be well received as long as they are not too intrusive to your non disabled users.
Helpful links
http://www.w3.org/TR/WCAG10/ The W3C Disability guidelines are a good place to start
http://en.wikipedia.org/wiki/Web_accessibility Wikipedia web accessability
http://www.etre.com/tools/colourblindsimulator/ Allows you to see how images will appear to colourblind users
http://colorfilter.wickline.org/
http://www.w3.org/WAI/ W3C Web Accessability Initiative Guidelines
Section 508 is the section of the law that requires that US government websites be accessible.
More information is here, including best practices on making content accessible to all.
http://www.section508.gov/
Generally you should support screen readers by using semantic markup, and avoid flashy content and audio -- these are usually impossible or just difficult to make accessible.
You should also look at web typography guidelines and look to hiring a good designer. Poor color schemes, typefaces, and font sizes make reading on the web much harder than it needs to be.
If you're from the UK, from a legal POV you want to be looking at the Equality Act (which replaced the Disability Discrimination Act).
The foundation of web accessibility is based on the graceful degradation/progessive enhancement model (sounds more complicated than it is!). A List Apart wrote a great article on it some time ago.
A good starting point for web professionals is the RNIB's Web Access Centre. Obviously this mainly deals with those user who experience visual disability, but it's a very useful resource.
Web AIM is also a good site for resources/articles although I'm not sure how often it's maintained these days (still, the information there is relevant).
There are far too many individual little things to bear in mind when developing accessible interfaces, but if you take the time to read some of the articles on those sites, you'll pick up the fundamentals which will then lead you onto the more nitty-gritty things.
Accessible development is about a change in mindset as much as learning the nuts and bolts. You need to to be constantly asking yourself "How might other people use this? What barriers might be in their way? What browser are they using? Does this work without colour/JavaScript/CSS?". Learn how to take your site apart and see if it still works.
Web Content Accessibility Guidelines 2.0 (WCAG 2.0) is the W3C Recommendation from Web Accessibility Initiative (W3C/WAI).
An overview can be found here: http://www.w3.org/WAI/intro/wcag20
There are very broad Principles as well as precise Techniques (for HTML, CSS, JS, Flash, etc) and the intent of each and every criteria. These aren't documents meant to be read at once and you'll want to learn more from tutorials and articles found on the web (archives at 456 Berea Street, WebAIM, videos about accessibility)
The W3C Quick Reference guide to WCAG 2 lists all of the relevant techniques you'll need to implement the WCAG2 principles and guidelines that Felipe mentioned, with code examples if appropriate on the individual technique pages. If it's all a bit too technical for you, WebAIM's checklist is the same thing only in plain English.
Unfortunately there's no magic wand for getting sites to be compliant. You have to go through each bit of content and test it and modify it if necessary. Luckily, even some small improvements can make a big difference.
A lot of good answers, but I can't help adding my input as well.
If you want to ensure a website is disabled friendly, there are a number of considerations that should be taken. One that I have not seen on here (perhaps because I skimmed) is to ensure that you use high-contrast colors, with a solid background behind text.
However, you should NOT use white on black or white on black...dyslexics commonly cannot see those colors. Use an off-white for background or text.
Also, make sure your text is large. Ensure as much of the content as possible is standard text, so that text-to-speech programs can "read" the website. Text-to-speech cannot read images. Text links instead of buttons would also be advisable, for the same reasons (though there may be a means of associating text with a button for these scenarios...?)
I've got what i think it a useful idea for CSS development but I'm unsure where to make my suggestion or to whom it should be directed.
Is there a universal inbox for CSS improvement suggestions at the W3C? I know it will take forever to get suggestions drafted, tested and put into the CSS specs but there is no time like the present...
The W3C has a Participation FAQ that you might be interested in, but if your idea is development-related, does it really need to be a part of the specification? Or is it the sort of thing that developers of popular (CSS-related, web development) tools could simply add support for?
Rather than going directly to the W3C, I'd suggest first trying to get some more exposure for your idea. Write up a blog post describing it, submit it to some popular sites like A List Apart, Hacker News, or Reddit -- basically, get as many eyes on your idea as you can.
If your suggestion really is a good one, it'll help to gain momentum by getting a lot of attention. Or, if it's a bad idea, you'll quickly find out by having people "review" it. You'll likely get some good suggestions to improve the idea, and you'll definitely spend your time better getting peer feedback than somehow trying to singlehandedly champion it to the W3C.
I have a friend who wishes to work as a freelance web developer, but insists that tables are the way forwards for layouts.
Several points he maintains in favour of tables:
This is what was taught at the beginning of 10 years of programming & computer science degrees, thus it 'must' be right.
Large companies use tables to achieve 'technical' things (like server side scripting and working with forms)
It saves time.
I have coded him some examples of CSS exactly matching table based layouts, and provided many links to articles explaining SEO and accessibility benefits.
With regards to semantic uses of HTML tags, I have explained at length with examples how tables are great for displaying tabular data but not for general layout.
From the perspective of a client, I have been explaining to him that I wouldn't hire someone using outdated methods as their main strategy for layout. As he is my friend and I wish him every success, I believe it is important for him to gain the best start when pitching for work.
The question again: How can I explain to a programmer that CSS positioning has many benefits over table based layouts?
Show him CssZenGarden. You can't do that with tables.
Designing with tables is really easy. Changing a tables design, such as "Put navigation on the left instead of the top," is anything but.
This is what was taught at the beginning of 10 years of programming &
computer science degrees, thus it
'must' be right.
So were frames and marquee tags. people dont use that anymore for a reason
Large companies use tables to achieve
'technical' things (like server side
scripting and working with forms)
If by 'technical' things he means ugly looking things, then hes right. also as i said, tables are good for tabular data, and you SHOULD use them for that. also, i dont see how server side scripting and forms have anything to do with tables.
It saves time.
Yeah it does, at least initially. if you want your code to be maintainable in the long run, tables will not save you time.
I would say that an approach that uses both tables and divs/css is best.
Tell the programmer to look up accessibility requirements and/or 508 standards. Depending on his target market that should mean it's a requirement.
Otherwise challenge him to a contest. Take a scenario of a potential client that likes the functionality but wants this button moved there, that menu moved here, blah, blah, blah. See who wins.
In your friends defense. If he is targeting small businesses, most of them probably won't know the difference if he uses tables or CSS. They just want a site that works.
It really sounds like your friend is just lazy. He's not going to last as a free lance developer for long if he insists on not keeping up with the technology and trends.
Tables were used for layout because that's all we had. It's always been a hack, they were never intended to do all of the things they were put in to. Surely, most programmers today know the history of HTML enough to know why things were put in place how they were...and that at the time of their invention we had NO idea what the internet would become.
No one put them out as a design mechanism, at least no in the way they ended up. So the argument that "that's how it always was" falls flat there. It was that way because we hadn't come up with the right way yet.
I don't personally think it saves time, either. You spend as much time repeating yourself and typing those irritating tags over and over again, all the while keeping straight how many columns your currently supposed to be spanning.
Table-less design has so many advantages (unless you're displaying tabular data). They are more accessible, easier to manage, (generally) smaller...the list goes on and on.
Anyone who is still holding out is simply either not willing or not able to learn tableless design.
I love this question. It does seem still to be a tough cookie.
I'm a developer, and prefer CSS for everything. first of all
1> This is what was taught at the beginning of 10 years of programming & computer science degrees, thus it 'must' be right. - HA
Table format as I've seen is a presentation thing. Therefore should be removed from the logic.
Working with designers, allowing them to change a tables format at will is a big bonus for the freedom of design.
Tables definitely still have their place in the world but large companies only use them as the techincal team are often met with larger challenges than the choice for a table layout or presentation changes
It can save time, but can later meet other problems, again with redesigns, SEO, accessibility.
I've had the problem when wanting to add another field... inside of <div class='cell'>my new field data</div> POP DONE - you have to fiddle with all manor of table formatting, which is time consuming and tedious -
"Working with designers, allowing them to change a tables format at will is a big bonus for the freedom of design." I don't understand this point, could you elaborate further? I am a designer first and have only been learning web coding to meet my clients web design needs. My friend is a programmer, and needs my design skills to help him gain business.
Well, its my experience, every designer has the right to say "I'd like to move that field slightly to the right by three pixels" - with a table it tough to break out the box. Giving the designer an option to either present something in a table format, or do magic -
For example, today - working with Google maps - its my mind, the route steps (directions you get for turn by turn roads) I saw that as a table and thats it. Later the design scope was changed and it was no longer a simple table format. If I did do table stucture - it would have been a recode on my side or an ordeal on the designers part.
This is a best-practice topic.
I saw it as a prefer method for some web developers. Instead of doing the CSS layout from scratch, they start a photoshop mockup first and then decode it into CSS.
What do you think about this approach?
Best to all,
Mockups are great, but I don't know if photoshop is the very first thing you'd want to try for the purpose -- at the very start, when you're just trying to get a logical layout for the various pages of the site (before refining it in terms of looks &c), a whiteboard with dry-erase markers and post-it notes affords for very fast, repeated mock-up rearrangements for the early brainstorming. Once there is some reasonable agreement on one (or a very few) possible arrangements of information, then visually more accurate tools enter into play.
BTW, just don't forget to photograph the whiteboard before changing it (any decent cellphone will do, you're not trying for high quality here;-) any time there are ideas or suggestions you may want to revisit or ponder in the future!
It is fast. This is why i always use this method. You don't want to spend the time building cross-browser CSS until you are actually set on a layout.
Most webdesign graphic artists work this way.
Many programmers simply find it a waste of time.
It has advantages, and disadvantages.
Advantages:
Many graphic artists grok photoshop/illustrator more than they do dreamweaver.
Customer gets a preview of the final product that works everywhere: mac, pc, firefox, ie, safari, whatever. Sending an html preview in early stages of production with developers using firefox and customer using MSIE always stirs up trouble.
And don't think to be on the smart side, scribbling MSIE driven html. Starting with non-standard html and converting to standard is more painful than doing it the other way.
There's one more catch: many web site customers tend to have a Mac and use Safari. Web committents tend to have a stronger taste for graphics than the average, so the chance to bump into Mac maniacs is higher in this sector than in others.
More design alternatives can be prepared spending less time on each one. This could be a dramatic advantage while dealing with murky clouds of executives with no designated decision-makers on the customer side. Alternative mockups will be passing hand-to-hand until general consensus is reached on one design or the other.
Disadvantages:
"Cutting" the graphic design into html becomes an additional work and it's not clear who's gonna pay for that extra time.
It favours graphic-centric, and rigid, design workflows. Customers agree pre-emptively on a given preview and that's what they get by contract. Every graphic modification means money, behaviour and programming instead tend not to be well defined, or worst, ill defined by the mockup.
The quest for pixel perfect cross-browser adherence to the mockup may drive you insane. If you agreed on a given rigid design with the customer, that could become a dire issue to pursue.
Dirty CSS tricks shoe in into your design. Using an HTML mockup, the customer would have approved a design driven by code with less tricks in place.
Anyway, I wouldn't suggest photoshop for a mockup, but inkscape. (or illustrator, if you worship adobe by burning piles of money into magic circles at midnight)
A scribbling stage is good too, while discussing the contract live with the customer.
I prefer pencil and paper to felt-tips, and I webcam shoot ideas for archiving and email forwarding. When it comes to scribbling, anyone does what feels more natural.
Not doing any and rely onto sample site examples and screenshots for graphical reference is always an option.
If you're productive that way, why not? Not everybody manages to envision their Web site perfectly as they're typing in a bunch of angle brackets.
More seriously put: It's your job, so it's your responsibility to do it in a way that allows you to do it effectively.
When prototyping, it's important to choose the right fidelity. This article from BoxesAndArrows provides a nice introduction to the various options and their uses.
I particularly like this line by Bill Buxton which the article quotes:
There is no such thing as high or low fidelity, only appropriate fidelity.
In this TechTalk by the Facebook Design Team, they mention how they use Photoshop in their design process (IIRC it's somewhere midway through, but I can't seem to forward through the video).
I am a web programmer who knows html and css fairly well. I can use a graphic program for it's basic functionality, but desinging a complete graphical web site is not my thing.
I let a graphic designer use his or hers graphic program to create a nice looking layout, and than code the website by hand in html and css.
It works for me, and gives my customers a design they like (cause a graphical designer will always make a much more nice looking design than most web programmers).
Agile methodology would suggest something easily modified in consultation with the customer. Dave Thomas in Agile Web Development with Rails suggests scribbling on paper. But anything has got to be better than chipping away directly at handmade CSS unless you really know what you want.
I was thinking about saying "scribbling might not cut it for a formal presentation" but the awesome SO crowd beat me to it in the comments...
Personally, and at every webdev firm I've worked at, I've always mocked-up in photoshop first. Jumping straight into CSS and markup is more of a bottom-up approach and makes sense to a lot of programmers but in web development you have to keep in mind that there are aesthetics to consider and a creative direction to follow. It's not enough that your product is functional, it needs the input of a professional creative-director/graphic-designer in order to make the product pleasant to look at and use.
In my experience, the problem has always been wrestling with inflexibility of team-members. Graphic designers who are aesthetics focussed and refuse to compromise their design integrity; which sometimes results in impossible or extremely difficult and un-semantic layouts. Developers who flatly refuse to compromise the integrity of their code where there is a workable solution - which might be a little less elegant. The key is to have a creative team who is intimately familiar with CSS and what is and isn't possible and an engineering team who have an appreciation of the importance of design and aesthetics.
In my freelance life (having had the benefit of working in both camps) I find it much easier to mock-up in photoshop first because I know what I can and can't do. And photoshop mockups are a lot easier to change on client feedback than are CSS and markup. Also, if you can show your client a mock-up, they feel more secure because they know that their money is going into a well planned project with a definate direction.
Hope this helps!
this is my firts post here ever.
I have to develop an aplication for a group of people with special needs. The functionality is really trivial, however, i have no clue of how to do the interface for them to be able to use it.
Their intelectual habilities are perfect, they are actually studying high school, but one of them types with his nose which needless to say, is very dificult and another one types reaaaaaaally slowly with only one of his fingers and neither can use the mouse.
I was wondering if i could use javascript to develop a usable interface, based on huge grids or something like that or maybe you guys have a better idea.
Political incorrectness aside, why don't you ask them? You're talking about accessibility here, if they're using computers they must be able to tell you about what they like or dislike about user interfaces that they've encountered.
I'm going to split my answer into two parts - design and implementation.
From a design perspective, it's important not to be intimidated by the fact that the users use a computer in a different manner. Treat this like any other project. Observe how they currently use other apps, and ask about the kind of things that they find helpful, or have difficulty with. If they claim nothing is difficult, ask a teacher or assistant, who will be familiar with the kind of things they struggle with.
Once you've started implementation, try an idea and get initial feedback. If you simply ask how they find the prototype, they'll likely say it's ok. Instead, try observing them using it without saying anything or giving guidance. If they get stuck, let them find their own solution to the problem. If appropriate, you could ask the user to speak their thoughts out loud (e.g. "I need to save this form, so I'm scrolling to the bottom, and clicking save").
On the development side, try to use web standards (valid HTML, CSS and Javascript). People often point to the "Web Content Accessibility Guidelines 2.0" (WCAG2) but this is quite turse and hard to understand; there are many more friendly articles on "Web Accessibility".
Someone with a physical disability is likely to use an alternate input device, such as a "Switch", onscreen keyboard, head-tracking device, a device for pushing keys on the keyboard, or speech recognition. Many of these methods involve simulating the keyboard, so by far the most important thing is to consider the accessibility of your site without using a mouse. For example, try tabbing through the page to see if you can access all elements in a reasonable amount of time. Consider using the acesskey attribute to provide an easy way to jump to different parts of the page (using 0 through 9 is often recommended so you don't interfere with browser shortcuts).
Also make sure that no part of your site is time-dependant, as different users may take different amounts of time to perform a task. For example, don't use the onchange Javascript event to update a page based on a listbox selection. Ensure you have alt text for images, so it's accessible for speech recognition. make the pages short enough so that excessive scrolling isn't required, but not so short as to require following lots of links.
Those are just some ideas to get your mind going in the right direction - but there are many accessibility resources on the internet - steal freely, and don't reinvent the wheel.
I realise I haven't addressed your question about Javascript - that's because I think it's probably one of the less important considerations. If possible, use Progressive Enhancement techniques to make the site work with and without Javascript. You might also look into the WAI-Aria standard for giving semantics to your Javascript.
And finally, to reiterate my initial point - make something simple, show it to the users, tweek, and show again.
It doesn't really matter what technology you use. Use whichever suites you.
But, make sure that you make UI components BIG in size(Bigger buttons, bigger font, bold font, coloured font(are there any colour blind?). This is for the ease of use of people (you said someone types with nose).
Also, better to have audio as informative source along with the usual screen display whenever some wrong action is performed on the application. This way visually impaired people will be assisted more.
Do it well, you are doing a divine job.
The first thing that you should read up on is the Web Content Accessibility Guidelines written up by the W3C.
In a nutshell this document describes the basic principles for people with disabilities in general.
For your needs regarding persons with special needs, you might want to look at Jakob Nielsen's article on Website Usability for Children, wherein principles of web design for young children or people with otherwise limited cognitive ability are outlined.