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.
Related
My company runs a web application and in a couple of places our clients have a text editor (CKeditor) into which they can enter text for display on the customer facing area of the app. The information has to be displayed in very specific ways due to the way the products are regulated, and the client often copy/pastes html with inline style rules that they get from directly from their suppliers.
A couple of times now, we've had issues come up where the inline style rules aren't assigned to classes or anything, so they affect other parts of the page. We can go in and manually fix the code, but it absorbs a bunch of time, and we run the risk of adjusting something and taking a product out of compliance, if we fix it we take on some liability.
We can't have the client be responsible for fixing it, as they have no clue what they're looking at, they literally paste it from the supplier.
We can make it so that the areas of the customer portal with content from the CKeditor open in a new tab instead of being displayed on the same page, and then the style rules wouldn't touch anything that they're not supposed to. This is the solution I'm considering right now, but it'll take a fair amount of time and will require the client to communicate the change to all of their customers; again, pretty strict regulations.
My question: Is there some way we can just put a container around any content entered into CKeditor, so it only affects a limited area on the display page? Something that will basically limit the scope of inline style rules, but that we can create outside of the ckeditor?
Thank you!
Apologies for any faulty terminology or vagueness, I'm new to the field and faking it as best I can currently :)
TIL that screen reader users rarely use tabs for navigating web pages and instead use specific keyboard shortcuts from their screen reader software (e.g. CTRL + OPTION + Arrow Keys in VoiceOver). This would mean that optimizing for tabbable navigation does not always make sense.
However I've seen some web pages adding tabindex="-1" to their headline elements or for elements that are not directly viewable due to overflow: scroll.
So my question would be: When does it make sense to optimize for tab navigation and when doesn't it?
E.g. in our current use case we've created a questionnaire that basically shows a question (h2 element) that can be answered with 2-5 answers (button elements). Clicking the answer will lead to a new page with the next question. When activating VoiceOver it seems like a good idea to have the question element set to tabindex="-1" and auto-focussed when the question is opened. But the learning above seems to challenge this a bit.
Thanks for your help!
So first of all you are confusing tabbing with focus. While a screen reader user may use arrow key navigation, they may also bring up a list of links on the page, or forms, regions, tables or (most often) headings in order to navigate to sections that interest them / get a feel for the page layout.
Tabbing is useful as there are plenty of people who cannot, struggle or prefer not to use a mouse but do not require the assistance of a screen reader i.e. Cerebral Palsy due to accuracy issues.
Hopefully that clears that bit up for you.
As for autofocusing an input on a multi-page form, that is more of a UX issue...is it good UX for all users if you auto-focus the form.
I would say yes, requiring people to click, tab or use shortcuts to get to the input if that is going to be the action that 99% of people need to take is not good UX.
Notice I say the <input> and not the heading.
What you do want to do is look into how to indicate this is a multi-page and multi-step form on the first page of the process.
You should also consider having a checkbox as the first step that says something like "this form is multi-page, would you like us to auto-focus the first question when a new page is loaded" and have it default to checked.
That way someone has the choice to stop the auto focus if they wish.
Additionally (or as an alternative if you do not want the checkbox) you may consider adding some text near to the submit button (and properly associate it with aria-labelledby and an ID) that explains that the next step loads a new page and the first input will be auto focused.
Another thing is that assuming you have titled the pages correctly (Form name or process - step 2 of 5) then a screen reader user can easily ensure they are on the correct page.
So focus the input if this is a multi page form, not the heading level 1.
Focusing headings after navigation is a trick for Single Page Applications (SPAs) so that might be where you have seen that, if you load the page content via AJAX then that is one of the recommended ways to handle navigation. You indicated next page "loads" which makes me think this is a Multi Page Application, but I thought I better add that just in case as a general tip.
Bear in mind that all of this advice is general. Depending on your form, site design, loading pattern, user base (experienced users / internal system vs general public) etc. the best practice may be different.
So long answer short - use autofocus on the input if this is a multi step form and you think it is appropriate and obvious that the input would be the next thing to fill in.
Then test it with someone who uses a screen reader and get feedback as to whether it makes sense or if it was confusing or unexpected.
You are making a confusion between screen reader user and keyboard user.
One doesn't necessarily implies the other.
People having dyslexia but normal sight may use a screen reader so that they can hear a text out loud instead of trying hard to read it themselves, but since they otherwise use a mouse or a touch interface, they aren't keyboard users.
People having difficulties using their hands but with a normal sight might not be able to use a mouse or a touch interface.
They don't need a screen reader, but use exclusively a keyboard or maybe another specific input device that mimique the most important keys of a keyboard (in particular, tab, arrow keys, enter and escape).
A joystick in some form can be such a device.
Considering what has been said above, designing a proper keyboard navigation and optimizing it always make sense. It may not be of important use for some screen reader users, but it's very important for keyboard users, as it's maybe their only way for them to interact with the app/page.
I am a screen reader user. With others, I believe a confusion about input focus is being associated with structural and contextual concerns. To the first question regarding when to “optimize” TAB experiences. It is always important since keyboard navigation is a supporting pillar used in my toolbox as a screen reader user. In addition, any input based non-screen reader accessibility tool is likely going to use this means of access.
As a developer, a guideline I always impress on other is the fact you want the natural structure and flow of code to do most of the work for you. Secondly, the process should follow expectations of your target audience and it seems you want to follow a “wizard” style. So, let me spell out a typical expectation for a wizard style questionnaire flow when using a screen reader.
UX point: does page reload fully or dynamically change?
This matters as this has a direct impact on my current reader “cursor” and how I will navigate to find the question.
From above statements, I will assume H2 will be used consistently. Thus, I will naturally use quick navigation to go to the first H2.
Now, I will use screen reader tools to read the question (be it TTS or braille output).
Once I feel I have its meaning, I will typically use TAB to find the first input control. Buttons are not input controls and thus violates user expectations. I am looking for checkbox, radio box, text field, and/or combo box.
If check or radio boxes, then I am assuming a group and hope for grouping (sadly rarely present) and will use tactics to deal with the situation I have found. If grouped, then I am using TABs a lot to move quickly and hear the “context” of the specific box focused with input.
Finally once I have answered the question, I am looking for the next question or forward/previous mechanism. These typically show up as buttons.
Hopefully, I am demonstrating how conventions/expectation are built using basic structure rather than trying to force procedure on the user. Thirdly, sites like a11y project can be very helpful with coding.
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)
I'm not sure I've asked that question correctly, but hear me out...
In my main navigation I am calling a number of my links via fancybox.ajax, which then displays a separate page (ie. clicking on a link entitled 'INFO' opens info.php within Fancybox).
This is working, but I also see examples where people use a hidden div.
This question is helpful, explains things from an SEO standpoint, and has caused me to rethink my structure. The question is why would I want to contain my data in a separate page rather than a hidden div, and what benefits does it bring me? I'll note that I am currently using separate pages because I believed that was a good practice, but after reading that question I have been turned.
EDIT : I understand why I would use a separate page without a modal obviously...but I am specifically asking about not using hidden divs with a modal box
If you are calling those external pages via link, then Google follows the links regardless whether they are opened in a modal box or not. If you have javascript disabled those pages still will open. So
<a class="fancybox" href="info.php" rel="help">INFO</a>
... is a perfect valid structure from the SEO point of view. How the information will be shown to the visitor, in the same window, in a new tab or in a modal window is a matter of presentation.
Curiously, you could have a hidden <div> and open the contents of such in a modal window, but as mentioned by #zachary, having hidden content may affect the performance of your page load.
NOTICE that in this case we are talking about displaying "linked" content in a modal box, which is different than pulling the content dynamically via any ajax method (jQuery .load() or $.ajax() for instance) ... that definitively has effects from the SEO point of view because Google won't see the contents and the contents actually won't show up at all if the visitor has javascript disabled.
The Case for AJAX Modals
Pros
Easier to manage and organize in some setups
Markup is clean
Great for when working with a lot of data that takes time to load. Lazy loading in this way makes the app feel responsive.
Cons
Google does not crawl content (can be a pro in some cases)
Slower to render compared to hidden div
In most cases you want the hidden div. And if not, a function to render the content dynamically.
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.