Let's say I have a static website which I try to make accessible.
To this end, I include a "Skip to main content" link at the top.
I also want people to know what they're getting into, so I have a disclaimer message at the top.
The disclaimer message includes a JS-driven "hide" button, but this is not accessible (or visible) to users without JS.
Which do I put first, the link to #main, or the disclaimer message?
(goal 1) I want someone who is a new visitor to the site, with JS disabled, using TTS, to see the disclaimer first.
(goal 2) But if they've been before, It probably won't be helpful for them to hear the disclaimer every time they open a new page.
Is it possible to accomplish both goals?
If it wasn't static, and included a server-side element, I could have the {hide} link be server-side cookie-based, but that is not the case.
Edit: There was a comment, which I now regret flagging, saying that "99.999999% of users" (a statistic I question) have JS enabled, implying that the other 0.000001% do not matter. I disagree with this assessment, because I strongly believe in my goal of accessibility to all 100% of users visiting my site. While perhaps it is never attainable, I will not stop trying.
Is it possible to accomplish both goals?
Since it sounds like the only tools available to you in this case are HTML and CSS, I would say no, it's not. So with that in mind…
I would add the skip link first. You could place the disclaimer between your skip link and your navigation. Though your disclaimer would be repeated on every page, it'd be no different than a nav bar at the top of your page that the user would have to listen to every time – that's why you have the skip link in the first place.
TTS users should be plenty aware that they may be missing important information if they click that link. I'm no legal expert, but I'd be willing to bet that you (or your company) are not going to be suddenly liable for damages because the disclaimer was not the literal first thing a TTS user hears when entering your website.
with JS disabled, using TTS,
100,1% (*) of users using text-to-speech do use Javascript. This includes blind people, people with vision loss, people with cognitive disorders, illiterate people or non native speakers, ...
Also note that, among them, a large part of people with disabilities will view (visually) your webpage. The "skip link" is also useful for people with physical disabilities when mouse navigation is complicated (parkinson disease, hemiplegia, ...).
The other ones (blind people) relying only on audio will not view your webpage visually but will still use a javascript compliant screenreader (Jaws, NVDA, Chromevox, VoiceOver, ...).
For instance, you can see WebAim survey where JavaScript was enabled in the browsers of 100% of respondents.
(*) The 0,1% extra is because Javascript can help improving accessibility.
Related
I am working on a web page which is relatively long (4+ pages). For ease of use I have added the back to top link at the bottom of the page.
I would like to know, whether I can skip this link from screen readers or assistive tools by using aria-hidden="true" and tabindex="-1". Does this fail the accessibility criteria ?
Since the back to top arrow is visible at the bottom of the page, is it necessary to make this link available for screen reader users ? So far my understanding is home key serves as back to top for keyboard/screen reader users.
Any suggestions would be really helpful.
You shouldn't be focusing on any one single user's experience. For example, if you have that 'Back to Top' link in logical spots, it should not be taken out of tab order because you're only considering one type of user experience. A the same time, accessible features shouldn't impede on a normal experience.
That said, on a pure development basis, links should receive focus so it does fail since it's not completely operable.
WCAG 2.1.1 is pretty clear on this topic.
All functionality of the content is operable through a keyboard interface...
It doesn't say "most" functionality.
The home key works for mouse users too so why should they also have the ability to click on the "back to top" link and no one else?
I like them more and wonder why they are not more common. Explanations involving caching or SEO make sense to me, but I don't see them as directly driven by user experience considerations. In which way are traditional sites with page reloads better for the user?
Personally I think the best argument for normal page reloads from a user's perspective is that when you do that it's much harder to break many basic browser functions. In general the back/forward buttons work, bookmarking works, copying and pasting links works, history works, page titles work, getting an error page when a server call fails works, everything just works as expected. For free.
I have seen single page application implemented in a way that breaks one or more of the above more times than I can count.
It's naturally not a problem if you get it just right (and then it will in general be nicer to use), but not all sites do.
Just as an example here's a screenshot how a site that is a SPA and justifiedly so (they have a music player that you don't want to interrupt with page loads), broke a basic browser function in a way they might not even have thought of. I was trying to find a song I recently listened to but couldn't remember the exact title... but because of the SPAness the page titles weren't properly reflected in my browser history.
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.
When are appropriate situations to use the target="_blank" attribute on your hyperlinks?
Edit:
To clarify, I know the syntax will open a new browser window. What I am asking is when is it appropriate to do so?
Whenever you want to annoy users.
More seriously, since this opens a new window/tab, it should be used sparingly, in my opinion.
Most modern browsers have some option (ie: middle-click on hyperlink) to do this for you, so I personally prefer allowing the user to handle this themselves.
However, if you are working on something where there is a non-technical reason for this, such as a sales-oriented site, it's often desirable to open a product brochure in a new window, or something along those lines. However, just be aware that overdoing this leads to my pseudo-joke response above....
When ever you want to leave the current page as-is.
I've got a feeling your question should be 'When is it appropriate to open a new tab or browser window?'
If so, the answer might be :
The current form may be in edit mode, and you want to be able to open
another page without either
disregarding or saving the current
one.
You have a data stream like Twitter which you want to leave active while
you go off and look at X.
There is a specific business requirement to do so.
Your users have weak navigation abilities and won't find their way back to the main page.
It is most appropriate when you're linking to outside resources that people may want to go to for additional information, reference, etc.
It lets them leave your site without losing their place on your page or have to use the back button.
It also makes sure they have to look at it one more time if they want to close it ;-)
(that last one is a joke and I don't advocate such despicable practices of course...)
Generally I avoid it like the plague. However, perhaps a good example of why you'd want to use that would be if you're building a cart module or something, and you have the "click for bigger picture" link. I think it's ok in that sense.
Keep in mind that whenever you do it, you're assuming you know the user's workflow better than they do (they can always open the link in a new window without you forcing it). In the case of the "bigger picture" link, you'd most likely be correct in assuming that's what they want, but in most cases I wouldn't jump to conclusions.
When you want the link to open in a new window, I would assume. I think the time to use this is when people might click on a link that'd destroy what they were doing on the page currently, such as a "help" link on a form.
Though some would argue that you should never use target="_blank".
One thing to be aware of here is accessibility. Built in features to help blind users (text to speech for example) may act weird (or just in a way that's confusing to the user) when you open a new window or tab.
Also, you're breaking the most used feature of every browser...the back button.
Only if it, with outmost certainty, prevents the user from having to repeat something.
I think that you should probably not ask a user experience question in a developer forum, because you will get developer answers.
That said, and as a developer, I open new Windows when I expect (or want) the user to come back and continue working on the site where the link originated.
The only time I would consider it is if you have multimedia on the page.
Best example I can think of - the StackOverflow podcast... I can't tell you how many times I've rushed to click a link in the blog post only to take me off the podcast page!
Also, on YouTube when I click "View Comments", it takes me away from the video page.
Whatever you do, don't use JavaScript to open a new window. That's definitely the worst. Nothing worse than a middle-click only to open a new tab with javascript::garbage in the address bar.
The target="_blank" is deprecated in XHTML 1.0 strict, and since I only write in strict I use JS if I really want to open a new page (or tab) and I only do that for external links (like a wiki or so).
More info:
http://www.ajaxblender.com/open-links-new-window-w3c-valid-target-blank.html
NOTE: Although it is deprecated in XHTML 1.0 strict, target="_blank" been brought back in HTML 5.
Stydying your audience will help you decide on this. Casual websurfers will appreciate target=_blank while tech-savvy people are more likely to get annoyed.
As for XHTML 1.0 strict, it is never appropriate. The target-attribute is deprecated in XHTML 1.0 strict.
Never. If I want to open your link in a new window I will do so.
When you open the link in a new window.
There exists practice to open in new window links that refer another/external domain (wiki for example).
I use it for product brochures and the like as I think it is useful for the customer to stay on the product page. I always indicate [new window] next to the link to keep the customer informed. Often the product brochure is a PDF, so I also note that the link will open a PDF.
Use it as you need it, but keep your users informed so as not to annoy/confuse them.
I prefer to avoid it, because most users can figure out on their own how to open a link in a new window, even if unsophisticated. My preference is to use an explicitly named destination, e.g. target="somename" if you have a good reason for opening a new window on your own.
I only use it when the client insists.
Otherwise I prefer to let the user decide.
I might be in the minority here but I like using target="_blank" for my links ONLY when they're meant to be reference links. In most cases, you shouldn't be using it for regular links around a website.
I really don't like it when I click on a link in a blog post or an article and it loads on the same page and I need to navigate back to the original source page.
When you are creating an email for mobile users and are linking to external content. That way, when they click on the link they will open the page in their browser.
When you want to open any particular link in new tab on current window then you can use target="_blank" in html.
<div class="restrunt-menu-list">
<ul>
<li>
<span>
<a target="_blank" href="www.example.com">View Menu</a></span>
</li>
</ul>
</div>
But It might affect your system performance because all browsers takes a lot of memory when it open a new tab or new window.
So less opened tab means less memory uses, less memory uses means better performance.
You can also see that which tab using how mach memory in chrome:
Press shift+Esc , Then you can see Task Manager- Chrome with list currently using memory by each tabs ( in chorme ).
For all external links...
We are designing a web site and have run into some UI challenges that would be neatly solved with a tabbed interface. Users will interact with different elements of the site (there are some basic view/edit/copy/paste functions available) and having only one object in one tab visible at a time simplifies things quite a bit.
We are, of course, completely comfortable with tabbed interfaces but what about novice users? I've searched the web for guidance and I haven't found anything definitive. Do you have experience presenting a tabbed interface to novice users and did they have trouble with it? Or, have we reached the point where everyone is comfortable with tabs and we can use them without reservation?
Usability is important-- more so for this project than most. If naive users are confused by a tabbed interface it just won't work and we'll have to find another way.
In his excellent book "Don't Make Me Think" (Sensible.com), Steve Krug discusses the benefits of using a tabbed interface:
They're self evident
They're hard to miss
They're slick
They suggest a physical space
He goes on to describe the keys to successful tabs as demonstrated by Amazon.com:
They were drawn correctly
They were color coded
There was a tab selected when you enter the site.
Obviously, he provides details to each of these bullet items in the book (I won't plagerize him here). The book is definitely worth a look if you want guidelines for creating web sites for novices and experts alike.
Tabs are becoming common place enough that I wouldn't worry about using them, as long as you implement them correctly. Make sure that you make the active tab visually distinct from the other tabs.
Also, try to create the tabs using progressive enhancement so that the content is still there with JavaScript disabled. There are two main ways of doing this:
Load every tab but the first using
AJAX. The tabs themselves should be
links to the content that the AJAX
fetches.
Keep all of your information on the
page, but hide it using JavaScript.
When you cycle through the tabs,
they are populated from the hidden
parts of the page.
A design resource you might find helpful is the YUI Design Pattern Library and their section on tabs.
I think as long as the tabs are visible as such it's understandable by the user. I have seen websites where they present a vertical bar with links that act like tabs but it's not immediately visible to the user and found that very confusing.
I would have to disagree with those are in favor of tabs. In a design test we did for a fairly high-traffic website (over 1mil uniques at the time), we found that tabs have not been used. Tabs were clearly marked, located to the right of the main content area. Based on that experience I would suggest either finding an alternative or, as staticscan suggested run usability tests to figure out which ones work.
Don't think you can decide a-priori what is usable and what isn't. Do usability testing
"It takes only five users to uncover 80 percent of high-level usability problems" Jakob Nielsen
Google usability testing and start learning. It's not hard.
I tend to agree with lothar and ricebowl - people seem pretty familiar with it these days. The most important thing with any GUI element is clarity - the user must innately know what will happen when they press something (they know that clicking an inactive tab will make it active); and in navigation - it must be very clear exactly which tab they are currently on. As lothar said, if it's not immediately visible to the user, it's very confusing. If you address those issues, then it should be fine.
Just wanted to note SmashingMagazine has a new article showcasing tabs: Showcase of Tabs
I think people are used to the metaphor (from binders, or card-indexes and so forth) of tabs. Especially those that use the web for any length of time. I think that, if IE's adopted a metaphor, it implies a common familiarity with that metaphor.
So, no, I'd suggest that they're not confusing and suggest that you go for it. Just, maybe, post a welcome/first-time introduction (or a prominent 'help' link to such an intro) to the use of the tabs.
I've been a developer for an intranet app that used a tabbed interface, generated with HTML and controlled by JavaScript. This was way before IE7 and Firefox. In fact, it was a bit of a novelty on websites in general, too.
Fortunately, a previous developer had discovered that if you made it look like a dialog box - even down to using a grey background, then people usually understood the metaphor. We also loaded all the content for all the tabs in the initial page-load, and had the Save/Cancel buttons outside the tabbed structure. Because of this, most people immediately understood that they could move between tabs (we used JavaScript to hide and show the DIVs) and a Save would save changes to all of them.
If you want to deviate from such an obvious metaphor, then you need to do some usability studies.
A well implemented Tab interface should not confuse users.
In line with what others have said one of the most ipmortant things to consider with Tabs, or any other navigation interface is for it to be obvious where they currently are in the navigation scheme.
Another important point is not to break the browser! Many AJAX or javascript implemtations break the back button. This is a minor annoyance to some and a major inconvieniece to others. Make sure to consider your target audience here.
Personaly I prefer the oldschool method of not preloading all of the tabs but having each tab as its own page and using a templating methodology to manage the navigation interface, be it tabbled or otherwise. This maintains the browser history and works fine with or without javascipt.
Tabs, etc are just tools. How we decide to lay them out and use them is what determines their effectiveness.
What I try to keep in mind is:
1) Keep it close. The things we use the most should be on the front or up close to the top as much as possible and bury the rest based on how often they are used/adjusted.
2) Easy enough for Mom to use. All interfaces are confusing if they are not laid out in a clear and logical manner.
3) Organize how it's used, not how you think it makes sense.* I often use tabs to break up steps in a process, or to break up areas such as basic / advanced options. I group them based on similarity or usage depending on what works better
4) Keep them few Either way I try to stay below the 7-10 range tops as the human brain has a hard time jumping beyond 7-10 digits, so I assume the same for pieces of information. Vertical Accordians might be something you want to look into as well.
I have also embedded tabs within tabs before. Works well but only one layer deep most of the time.