I'm working on improving accessibility for a website, and I'd like to force JAWS to read a block of text in order to help the user.
For example, I have a help icon link that pops up a help modal. This modal contains some helpful text. I want to be sure that this text is read to the user. I'd like to have a solution similar to a div where I can do something like:
<div class="ForceReadText">
<p>Block of text to be read, that currently isn't being read.</p>
</div>
I'm not very familiar with JAWS, and my google-fu skills are failing me. I figured it'd be better to ask someone who might know how to accomplish this. Any ideas?
Forcing things is difficult and gives the appearance of rudeness. What I've done in the past for accessible modals is to make the icon that opens them a link, with the link pointing to the id attribute of the modal or its heading. If someone wants help, the click the link and are taken to the information (and will use the arrow keys to read the text); if not, they can just move on.
<img src="icon.png" alt="More information">
For what you are describing, it sounds like you might want an ARIA live region. MDN has an overview that may be of use.
For a quick overview, a live region is great fit for real-time updates to a page, such as errors or alerts. A live region has the ability to interrupt whatever a screen reader is speaking in order to speak the message instead. A live region does not change the location of the focus on a page.
The trick will be understanding that a page really should have just one live region.
The other trick will be getting all your messages into one live region, though it is certainly do-able if your pop-up behaves like a tool-tip (just re-use it).
If it behaves like a modal, keep reading...
Now, all that being said, the previous answer (from #stringy) is probably a smarter approach as long as you have good focus management practices (necessary for a modeal). If you do not, then a live region may be a better fit (and maybe less jarring).
Either way, take a look at these patterns and see if one addresses your goal:
2.3 Alert
2.4 Alert and Message Dialogs
2.9 Dialog (Modal)
Related
We've implemented a content switcher using a native dropdown select element, which switches between HTML tables directly underneath. This is to be used inside blog posts, with various table content relevant to the post. The table will be switched out immediately using JavaScript upon selecting an option from the dropdown. Simplified code below for illustration. We're using React but I don't think that affects the question.
<div className={styles.csvList}>
<label for="csv-table-selector">{label}</label>
<Dropdown {...}/>
{selectedTable && (
<div id="selected-csv-table" role="region" aria-live="polite">
<h2>
{selectedTable.name}
<h2>
<Table {...}/>
</div>
)}
</div>
Right now we’re using a ‘polite’ aria live region containing the table, which will start to read the whole table out when the table changes. This is very similar to the Mozilla Docs implementation example for live regions.
Is there a limit for the amount of content which is sensible to keep in a live region? I couldn't find any resources anywhere online with guidance for when content is 'too much'. With tables, my assumption was that the screen reader user would prefer to navigate them manually rather than have the whole thing read out.
I also considered having a visually hidden live region, which will read out something like 'Table was updated below' when the table is changed. Is this more desirable than the whole table being in a live region?
Is this design doomed to be confusing for screen reader users? I'm aware that the 'tabs' design pattern is more usually used for this kind of scenario, so was wondering if we should abandon the dropdown switcher idea and go with that instead.
Yes, I would definitely recommend applying the Tabpanel Pattern as this will simplify work for you, and the users.
Because expectation is simply that when the active tab changes, the immediately following content changed. No additional announcement is necessary.
Solution with Dropdown, Without Live Region
If you still would like to use the dropdown, the expected behaviour would still be somewhat similar.
Instead of announcing that content change somewhere on the page, you would guide the user directly to the switched table by setting focus on it. Of course the table has an accessible name.
This way you wont ask the user to navigate themselves, after the announcement, but it’s already done.
I have been told by my boss to add tabindex="1" to the Accessibility link in our site footer so that it will be the first thing that someone who browses a site by keyboard can get to and read about the accessibility steps we take.
I have added tabindex="1" to the link which you can see here, but the browser doesn't seem to respect it at all (tested in Chrome/FF/IE 11). There are no other tabindex attributes on the page that I can see, so surely it should get picked up as the priority by the browser.
There are access keys used on the page, could this throw it out in some way?
I am sure it is something really fundamental, but I can't see what it is. Any help would be appreciated.
Thanks
It works for me, but as a long-time accessibility advocate I'd like to help persuade your boss it's a bad idea.
To see it working I suspect you are on a Mac and you need to enable keyboard navigation. People who need that would typically have it on already.
However, the reasons that adding a positive tabindex are not helpful include:
Someone using a keyboard (or keyboard equivalent device) and can see the screen will be confused. They press tab and suddenly end up at the bottom of the page, then flip back up to the top. Combined with the lack of focus visibility, this will be very difficult to cope with.
Someone using a screenreader will probably not notice the tabindex to start with because the main way of navigating is with 'arrowing' (using up/down to go element by element). However, if they are in the content area and press tab to skip to the next link or form control, they will suddenly go to the bottom of the page. Very confusing.
So in summary: Adding a positive tab index on a link in the footer will negatively impact the people it is supposed to help.
Here are the appropriate ways to use tabindex.
There are quite a lot of obvious accessibility issues on the site, I'd recommend getting some advice.
I just did a quick search for my question and couldn't find anything directly on point.
I'm still very new to HTML and was wondering if someone could tell me how I could add a picture to my website and set the code so that if I click on it, it enlarges the picture in a new window.
I'm going to be adding around 600+ pics to my website so I was also wondering if there's a way to write the code once and have it apply to all the pics I add.
Thanks in advance,
- Danny B.
There's many many ways in which you could do this. The basic HTML for inserting an image with a link to a new window will be:
<a href="enlarged.html" target="_blank">
<img src="photos/photo-name.jpg" />
</a>
But it is a fair bit more complicated if you want to be able to dynamically display a large number of photos. If you want to code this yourself, you'll want to look into using something like PHP to output the HTML code automatically for 600+ images. Then instead of pointing the link for each to a new page, you might want to consider having the images load in a cool way, such as a javascript lightbox/colorbox some of the other answers suggest.
One possible alternative solution might be to look for some pre-created photo album script. I don't have any experience of these so I'll let someone else make some suggestions on that.
There are several ways to do this, but I'm assuming you'll have a simple site with lots of images on one page, and you'd like the images to zoom open "in a cool way".
Check out this: http://colorpowered.com/colorbox/
... click on View Demonstration and then see the various photo handling options.
This needs just some basic HTML and minimally configured Jquery. Very simple to use and produces a nice effect.
Google around using the keyword lightbox. Most of the solutions are ready-to-use Javascripts. Just include once, assign some IDs/classes, execute during onload and that's it. I personally have good experiences with Lightbox2 and jQuery Lightbox plugin.
I decided to go w/ target="_blank" -- Lightbox2 seems like it'd be great, but I'm really not sure how to use it and where to put all the code. The instructions I've found for it still assume the user has some standard knowledge in the field, that of which I do not currently possess. So, I'll stick to the target/blank approach until I can get more familiar w/ coding and then I'll upgrade to Lightbox.
Once again, I want to say thanks to everyone. You guys always respond quickly and accurately.
With much appreciation,
- Danny B
The simplest way would be to add a link to it, and set the target attribute to target="_blank". The link should point to the image itself. This would regularly open a new tab though, if you want a whole new window, you should tryhref="javascript:window.open('myimage.png','_blank','toolbar=no,menubar=no,resizable=yes,scrollbars=yes')",which would open a new, standalone window. If you're looking for fade/resize effects and such, try one of the other answers posted.
I have made life difficult for the HTML / CSS developers by making any interaction that has a side effect into a button and NOT a hyperlink.
For example I changed the "Clear Basket" in a shopping site from a link to a button.
On the premise that any action that has a side effect should be a button not a hyperlink. (even tho a spider or robot will never get to this point)
How does this relate to REST?
The best answer will have good reasons I can use as to why I make things difficult for the HTML/CSS guys,... or why I'm wrong :-) ,... perhaps I'm being purist but for no real reason?
Note: I'm not averse to putting ajax functionality that has statefull side-effects on a hyperlink or even on selection-changed event.
Cheers.
Murray.
I think you did the right thing but justifying it is probably outside the domain of "REST".
If these links are truly just <a> tags that result in the browser making a GET request then clicked, then they shouldn't have any side effects because GET is supposed to be, per the HTTP spec, safe and idempotent. See earlier comments about spiders following the links, etc.
Now if the "links" used javascript to really do a POST to the server when clicked, or some kind of trick like that, then they are A-OK from HTTP's point of view. Probably more work than they're worth, but RESTful.
But there is user interface design to consider too. Because in basic HTML without CSS and javascript a link is always a GET, users have been trained since 1994 to expect anything that looks like a hyperlink to be safe and idempotent. By doing something different, your designers are in violation the principle of least surprise. This seems like something Jacob Nielsen would back you up on.
This doesn't really have much to do with REST, but I try to follow this simple rule:
Hyperlinks are for navigation.
Buttons are for interaction.
It does not really matter if your "stateful" actions are links or buttons. You can have a link that deletes/adds, etc. Consistency is what matters. So if you want to have these actions be buttons, that is fine. I think that talented CSS people can make links look like buttons. You may not need html buttons at all.
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.