As my title explains, how do I adapt a website for blind people? From what I've heard, there's a new Swedish law at the end of this year that says that websites should be adapted for blind people. It doesn't concern all websites, but website that contain information about the authorities such as police, hospitals, banks, pension/retirement benefit and so on.
This is the absolute first time I've heard of this. I have no idea how to adapt the homepage for blind people for the company I work for. Any ideas?
Where do I begin and how do I apply sounds that reads the content of the site? Is there any tutorial on this matter?
This is quite a broad topic but can be covered relatively easily.
What you're talking about is making use of Web Accessibility. The best way to be able to achieve eb accessibility is to make sure that your mark-up is valid and everything keeps to a certain structure that a screen reader or robot would be able to read it with ease and relay that back to a blind person.
The W3C have a full initiative towards Web Accessibility (the WAI) who are there to sort out how to verify a page is accessible for those incapable of accessing the web in the normal way (Mouse, keyboard and monitor).
They have a set of easy checks which are easy to follow and make amendments from your website to.
Read them here: http://www.w3.org/WAI/eval/preliminary
Ultimately, your best way to achieve full web accessibility is to ensure that the HTML mark-up is clean and has every last piece of meta data required, all images have alt tags and the structure to your page is easy for robots to understand and follow. HTML5 helps with this massively as you now have the usage of tags such as <article> and <aside> which are there to determine article areas and article details areas (great for blogs and news stories).
Hope this helps and if you need more information, then the W3C and WAI are your best bets.
W3C: http://www.w3.org/
Wai: http://www.w3.org/WAI/
There are a number of different standards people use when designing for accessibility. You generally need to include things like alt tags for images and links on your page, ensure your page can be viewed without JavaScript, high contrast modes, etc.
Try looking at WAI for some standards and how to get started. If accessibility is being enforced by your countries legislature, they will generally choose a standard or create one that you should adhere to.
Generally people viewing websites that need to hear the content will use a screen reader. It will go through the content and read it to the user. There are a number of readers that you can use for free and try out.
Related
I am coding a responsive site, and on the desktop version I wish for the navigation to appear on the left, but on the mobile version I want it to appear below the main content. I came up with the solution at http://abbymilberg.com/layout-sample.html by adapting a well-known grid system.
A colleague says it violates standards because the divs appear in a different order visually (on the desktop version) than they do in the markup. He seems unable to provide which standard this violates, though. I understand that it goes against traditional EXPECTATIONS from an age where all sites were desktop based, but can anybody provide me with a concrete example of what section of what standard (508, WC3, etc) this actually violates? I'm not interested in discussion of whether you think it's a good practice, just whether it violates a definitive standard. Thanks.
This does not, as far as I am aware, violate any documented standards. In terms of source ordering, it's generally better to have to document make sense to the user without script or styling applied. After all you ultimately have no real control over how it might render for them!
As to whether it's actually a good idea in practise, you'd need to conduct some user testing and find out. I for one would be interested to see the results!
Semantically and accessibility speaking your colleague is right. Because if you strip down the css, the arrangement of the divs won't make sense since most codes for navigation is on the header/top part of the code.
Can you provide us the code and a screenshot?
This does not violate any document standards in any way.
Document standards are a set of rules to follow, there are no "rules" for how you arrange your website layout. So semantically, syntactically and technically, no you are not violating any rules.
This may however, NOT be considered "best practice". Best practices aren't really rules, they are guidelines to help you make your site the best that it could be. I'm not sure that this would be considered best practice on the basis that an arguement could be made that... If your layout is so odd that you have lots of content falling before the MAIN content of your site, that since bots read left to right top to bottom, this could hurt your search rankings in that it makes it harder for google to understand what your page is about.
So I've been looking into this HTML 5 Microdata, but I'm not sure if or when it is appropriate to use. I know that if used with rating and you search a website it will pull up things like video rating and article ratings etc. But for Microdata like People or Places, is that so useful that I should start implementing it into all my websites - big and small? How big of an impact will this really have on my SEO if I start using Microdata on everything?
Maybe using something like http://schema.org/ as my standard term dictionary. I think that is what Google suggests using. Here's a link to the dev of microdata http://dev.w3.org/html5/md/ which will be helpful if you are unfamiliar with microdata
Following to that Schema.org - Why You're Behind if You're Not Using It... article on SEOMoz, I must say this question is not just about microdata and Google SERPs positions. I think it has to be taken in a much wider meaning:
Some advantages:
Implementing microdata on a website DOES increase CHANCE for Rich
Snippets displayed next to your site on Google search results. You can't say 'microdata = rich snippets', but you also can't say 'no microdata = no rich snippets' :)
Having rich snippets increases users' attention to that single search result and it CAN result in more clicks => visitors on your page.
Some cons:
Some rich snippets, which can be a result of using microdata, can let users find information they're looking for directly on the search results, without actually reaching your page. eg. if user is looking for a phone number and see it on rich snippet, he doesn't have to click and visit your page.
You have to decide on your own if you can take that risk. From my own experience (and that article comments as well), that risk is quite small and if you can, you should implement microdata. Of course, 'if you can' should really mean: 'if you can and it won't need the whole site to be rebuilt' :) If you have more serious things to do on your site, you should put them in front of a queue. Today, it's only 'nice-to-have', not 'must-have'.
And just for the end - I know my answer is not just yes or not the answer, but it's because the question is not that kind of question. However, I hope it could help you make your own decision.
My answer would be "Always."
It's the emerging standard for categorizing all forms of information on the web.
Raven Tools (no affiliation) has a schema.org microdata generator that's a good place to start:
http://schema-creator.org/product.php
They have a couple stock schema templates on that page (look on the left column).
The Semantic Web is an awesome idea. And there are a lot of really cool things that have been done using the semantic web concept. But after all this time I am beginning to wonder if it is all just a pipe dream in the end. If we will ever truly succeed in making a fully semantic web, and if we are not going to be able to utilize semantic web to provide our users a deeper experience on the web is it worth spending the time and extra effort to ensure FULLY semantic web pages are created by myself or my team?
I know that semantic pages usually just turn out better (more from attention to detail than anything I would think), so I am not questioning attempting semantic page design, what I am currently mulling over, is dropping the review and revision process of making a partially semantic page, fully semantic in hopes of some return in the future.
On a practical level, some aspects of the semantic web are taking off:
1) Semantic markup helps search engines identify key content and improves keyword results.
2) Online identity is a growing concern, and semantic markup in links like rel='me' help to disambiguate these things. Autodiscovery of social connections is definitely upcoming. (Twitter uses XFN markup for all of your information and your friends, for example)
3) Google (and possibly others) are starting to pay attention to microformats like hCard and hCalendar to gather greater information about people and events going on. This feature is still on the "very new" list, but these microformats are useful examples of the semantic web.
It may take some time for it all to get there, but there are definite possible benefits. I wouldn't put a huge amount of effort into it these days, but its definitely worth keeping in mind when you're developing a site.
Yahoo and Google have both announced support for RDFa annotations in your HTML content. Check out Yahoo SearchMonkey and Google Rich Snippets. If you care about SEO and driving traffic to your site, these are good ways to get better search engine coverage today.
Additionally, the Common Tag vocabulary is an RDFa vocabulary for annotating and organizing your content using semantic tags. Yahoo and Google will make use of these annotations, and existing publishing platforms such as Drupal 7 are investigating adopting the Common Tag format.
I would say no.
The reason I would say this is that the current return for creating a fully semantic web page right now is practically zero. You will have to spend extra time and effort, and there is very little to show for it now.
Effort is not like investing, however, so doing it now has no practical advantage. If the semantic web does start to show potential, then you can always revisit it and tap into that potential later.
It should be friendly to search engines, but going further is not going to provide good ROI.
Furthermore, what are you selling? A lot of the purpose behind being semantic beyond being indexable is easier 3rd party integration and data mining (creating those ontologies). Are these desirable traits for your data sets? If you are selling advertisement, making it easier for others to pull in your content is probably not going to be helpful.
It's all about where you want to spend your time.
You shouldn't do anything without a requirement. Otherwise, how do you know if you've succeeded? Do you have a requirement for being semantic? How much? How do you measure success? How do you measure return on investment?
Don't do anything just because of fads, unless keeping up with fads is a requirement.
Let me ask you a question - would you live in a house or buy a car that wasn't built according to a spec?
"So is this 4x4 lumber, upheld with a steel T-Beam?"
"Nope...we managed to rig the foundation on on PVC Piping...pretty cool, huh."
I'm trying to compile a guide for students used to publishing in print who are learning web design.
Some obvious things which web developers know but they don't:
You can't rotate graphics in HTML
All objects have to be rectangular, you can't have a circular DIV
Many typographical effects in their repertoire can't be achieved
Some things which are tricky are:
Can they have variable opacity? Well, yes and no.
Can they have rounded corners? Maybe.
Some things which aren't technical difficulties, but which are problems:
Image file sizes: I have a student who wants to have a different large graphic header on every page of their site; that's not technically a problem, but it will mean a visitor has to wait for a new graphic to load every time they navigate
Accessibility: "why not just make everything a graphic, to overcome the limitations of HTML?"
Please help me fill out my list and add any hints or tips for people making this transition.
web is not print
Layouts can be fluid.
elements don't have to be absolutely positioned
web pages need to be checked in several browsers for compatibility
avoid divitis; from experience people coming from print into this field do everything by brute force instead of trying to think of elegant solutions for optimization and semantics purposes
print is consumed visually - the web is consumed by people with visual impairments as well. Don't forget lynx users no matter how small the market share is :)
semantics is important, learn about them
thats all i can think of right now...
Coming from someone who has done both print design and web design (and done a decent job at both, I think), it seems like you're off to a good start. Other thoughts:
Darko Z mentioned this but I think it's worth stressing that browser incompatbilities must be recognized and dealt with. In the print industry there are standard formats like PDF which guarantee that things will come out in print the way they look in design; besides, many publishers will directly accept the native file formats of the most popular design programs, like Adobe InDesign, Quark XPress, even MS Word (for the cheapskates ;-P). The point being that print designers are used to a "set it and forget it" approach where they assume that once they design something a certain way, it will stay designed. The fact that there are different web browsers which render the same web pages slightly differently is likely going to be a major pain in the butt for people used to the print world.
Addendum to the above: fonts. You can't use (or at least can't rely on) uncommon fonts in web design, for obvious reasons.
Screen real estate has to be used effectively because there's a limited amount of it. And I mean really limited - no matter how hard you try, you can't write HTML that will make someone's monitor expand 5 inches or put another screen on the back ;-) It's not like in print where people can peek back and forth between different pages of a book. Reading web pages is kind of like looking at parchment through binoculars; you have to design the pages with that limited field of view in mind.
Web page designs are dynamic and transient; they stay up for a while, they get boring, they get recycled/replaced with new designs. So you're not stuck with mistakes. But it also means you need to design with future changes in mind, e.g. by using CSS so you can change the look of whole classes of elements easily. There is some use of styles in print design but nowhere near as much as online.
Fonts and Text
You are limited to a small subset of
fonts
Fonts are viewed at different sizes
There is a readability limit for how
wide paragraphs should stretch (in a
fluid layout)
Write for readers of all types - Some
will skim, others will read in detail
Images
Sites are viewed at different
resolutions and screen sizes - Design accordingly
To achieve transparent backgrounds in
IE6, use PNG8 with alpha (IE6 doesn't
support varying levels of
transparency, it's either 100%
transparent or it's opaque)
Use CSS sprites
Images should not be used in place most of text
The img tag should be used for images
with semantic value and all layout
images should be CSS images
Every img tag needs to have the alt
attribute to validate
(X)HTML and CSS
Browser rendering varies greatly
Validate CSS and (X)HTML for a
greater probability that the design
will be cross-browser friendly
Don't use CSS hacks
Use the proper semantic markup
Pages should be able to work without
JavaScript enabled
Read Yahoo's guide for
performance and use YSlow
Dreamweaver's design mode doesn't
reflect how a page will appear in
real browsers
General Design
Simpler is often better in terms of
usability, accessibility, design, and
download size
Lists of greater than five or six
items should be broken up visually
Consistency is important - Don't
change your navigation, etc without
an extremely good reason
When choosing colors, keep those with
color-blindness in mind. This will
affect how you choose to convey
meaning by color.
Place the most important information
above the fold (the part of the
screen that shows without scrolling)
The web is interactive. This
drastically affects how you consume
and display information. You can hide and subsequently display information using tabs, accordion, and similar methods.
Think in terms of primary and
secondary calls of action. What do
you want the user to do? Where do you
want them to go next?
Some broad points:
1. Print is static, the web is interactive.
The essence of a print project is a fixed point in time, an idea captured on paper or some other substrate. Web projects are moving, changing experiences that represent both the ideas of their creators and their users.
2. Everything is uncertain.
You mention typography in your answer, it's probably worth broadening that to cover all aspects of appearance. The variety of operating systems and hardware available mean that its hard to determine how all your audience will experience your final design. Whilst some things must be compatible across all browsers, sometimes it is not worth the time and effort needed to make something pixel perfect in all systems.
3. Learn about programming.
Unless you've an aptitude for it, you don't need to learn how to program for the web. But it would still be a big help to gain some familiarity with web programming, as if you can't code, you'll need to work closely with someone who can and you need to be able to communicate effectively with them.
4. Create working prototypes
When something is static, it can be designed using a static format. To design something interactive like a website, you should be making use of moving prototypes that represent the kind of behaviour the final design will have. You can use paper to do this, or more sophisticated mockups using xhtml, css and javascript, or a dedicated prototyping program.
The user controls how they want to see content on the web, not you. Your design will not look the same to all people because some people may make it different on purpose.
Screens can be arbitrarily large or small
The web is interactive: usability trumps pretty-lookingness
Your page will be read by machines: make sure the data is easy to get at by scripts that can't read images / large blobs of text (aka "be semantic")
Remember to save your jpg files in RGB format not CMYK format. I regularly get sent jpgs that won't display on a web-site and every time it's because it's been saved in the wrong format from Photoshop.
This will become less of a problem as browsers support more image formats, but considering that 20%+ of users are still on IE6 for the sites we develop this will take a while to go away.
A lot of these are good rules of thumb for print designers who want to learn how to actually markup HTML and write CSS. But as a Web developer in the past, I'd frequently just take a designer's template and write the HTML and CSS for them. Whether or not that task was simple or difficult depended on the designer's awareness of the capabilities of CSS.
There was one pain point in particular that kept coming up. So for print designers moving to the web, the absolute number one rule to remember is:
Don't design any element to have an explicit, pixel-perfect height. You can restrict the width all you want, but changing fonts, preferred font sizes, and different text strings being pulled from the database on different pages means that text needs to be able to flow vertically without generating hideous, hard-to-use overflow scrollbars.
Designers who remember this can usually conjure up designs that are easy to cut up and integrate in a mostly semantic manner. Designers who forget this sometimes end up creating designs that have to be shoehorned into a 3 inch by 3 inch box, and that's when I reach for the vodka.
A given color or font will render differently in different browsers.
Especially when one browser is on Windows and the other is on Mac or Linux, etc.
I wrote a blog post about this a while ago - http://aloestudios.com/2008/08/dear-print-designer-doing-web-design/
So did my friend Mark - http://www.visual28.com/articles/tips-for-better-web-design
Jeffery Zeldman's book Taking Your Talent to the Web is specifically targeted to the question you have asked. It's been out for a few years...not sure if there's a 2nd or 3rd edition. Check it out.
My main advise is that you need to recognize that while you have dot precision in print applications, most of the time in web design your focus is to design and code a site that will accomplish your content and layout goals for any number of platforms, resolutions and color depths. Color depth has become less important than it was in the past.
I am working in the web dept of a large legal firm, and among other things am responsible for maintaining a professional look for all our email communications (over 600 pieces per year).
Right now I am in a rut. Using a lot of pressure and manipulation, a person in management got to "art direct" a couple of HTML emails working directly with a member of my team and I caught the design at the last moment.
Her "designs" introduced background images behind the text of the emails along with additional, high-contrast imagery sitting behind the title in the header.
I ended up mandating a design change, however she is very insistent on "her" design and questioning all my reasoning for simplifying the look.
Basically she is questioning my expertise and asking for "proof" that her design is not user friendly.
I have the meeting in a couple of hours and was wondering if anyone here could point me to resources that discuss these specific items:
Argument against background images positioned behind the copy of an email. The images are at about 10% opacity, which makes them incomprehensible, and makes the design busy and ugly (my perspective).
Argument against high-contrast images behind titles.
Now, I am aware of the technical implications of including images in HTML emails, Outlook 2007 not loading background images etc. This is not necessary a technical issue, but a serious aesthetic/usability step in the wrong direction.
Thank you!
Facts:
Common sense in communicating dictates that anything that distracts you away from the message -- the content of the emails is not a good idea.
Is there images in the background of your letter heads and on all your invoices? Why so? Why not?
What do background images contribute to the value and perception of the message, the image of your corporation? Is it clearly known the impacts they have?
Go take a look at email newsletter sites. They are covered in guides and tutorials on how to email market effectively.
www.icontact.com
www.constantcontact.com
and so on..
Opinions:
Emails are not meant to be flyers. They are meant to communicate, clearly, simply and concisely while bringing a professional image. Making it look like a cartoon, or a flower shop, or whatever else you are dealing with probably doesn't add to it.
The issue you may run into is she is taking it personally because she is attached to the design for personal reasons and not designing for the needs of the business. So an attack on the design is an attack on her. She is too involved with her ego of looking good and avoiding looking bad or wanting some kind of glory.
Simply put, she should be the one qualifying to you why it IS good design, not the other way around. If she doesn't know, why is she asking you to prove it to her? How would she understand?
There's a book called Dealing with difficult people that may be of use to you.
Of course, if common sense was really common we wouldn't have to point it out as being common sense.
Update us on what happens!
http://www.asciiribbon.org/.
They have a lot of points on why not to use HTML ect, in emails.
Quite a few e-mail clients do not support HTML e-mail.
Other clients have a very poor or broken HTML rendering, causing the messages to be unreadable as well.
Sending HTML e-mails causes great overhead, and is very inefficient.
People that are limited to a text-only terminal, people with disabilities, blind people, basically anyone that cannot use a graphical interface easily or at all, are likely unable to read your mail.
(Extract from link)
In addition to what others have said, consider legal accessibility requirements. I found one example of the US Department of Education accessibility requirements. I'm sure searching for this one can find more examples.
Although it doesn't really apply, you may be able to reference the Americans With Disabilities Act, assuming you're in America.
Also, since you're sending HTTP formatted mail, maybe the Web Content Accessibility Guidelines 1.0 are of interest. For example, Guideline 2.2 of this document states "Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen."
A professional email should only be graphic-intensive if those graphics either emulate the look of the company stationary, emulates the look of the company site, or if the graphics are interactive. A common example where this makes reasonable sense would be billing emails from Amazon.com. Note, however, that the content itself does not actually have any graphics, only the frame above, below, and to the sides of the content uses graphics. Similar stuff shows up in banking emails and paypal emails. This sort of thing makes it easier for people to associate the email with the site and makes for nicer printed records that match the online version of the same records.
For standard communication, I'd just go with a header and/or footer graphic.
What I did was escalate to a person who has both the position and understanding of the importance of the issue. Also, presented a version with a cleaner design. Made sure to address all objectives, and did not imply that design decisions are open to discussion.
I HATE email with designs and pictures on it. It is unprofessional IMO
I hate them.
the desirability/niceness of designs and art are subjective. So, how can you be sure all the people who receive them will appreciate them.
For me they are a big turnoff.
Also consider looking up some references in Human Factors engineering texts that show readibility studies. I bet a quick library search in this area would yield much scientific data that her way causing reading errors, eye strain and or slower reading speed.