My application needs a sidebar that shows a list of options and highlights the selected one. I do not want a drop-down as that requires the user to click it first before all the options can be seen.
This is the sort thing I have in mind (example from w3schools website):
I opened up the Firefox DevTools and saw they used <a> elements, however I don't believe this to be the correct approach for my app as it as a SPA and as such does not have separate pages.
What would be the most semantic way to write the markup?
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'm not really sure how to ask this question, or whether it's even possible. I have previously built an android app that searched for data within a specific webpage and returned the data to the app. This app worked perfectly for over a year until the website in question performed a site wide session of prettying itself up, and in doing so, inadvertently breaking my app.
Within the new designed website, a dropdown menu has been added, which has several selections:
'Show20News',
'Show50News',
'Show100News',
'Show250News',
'Show500News'
The default selection is 'Show20News', and what I want is to make a selection of 'Show500News' instead. However, I want to append the selection to the URL, rather than manually selecting it. I have contacted the websites web team who just can't seem to understand what I am asking for, hence my visit here.
The website link:
https://www.londonstockexchange.com/news?tab=news-explorer&results=500&indices=AXX&sources=RNS&period=daily
What I'd like to achieve is adding the 'Show500News' selection from the dropdown menu to the end of the above URL, to avoid the manual process of getting the same results.
If you take a look at the source code of the link above, you will notice that there is no code that represents the possible selections. It is this that has me stumped. If possible I'm hoping that someone maybe able to nudge me in the right direction, or at least tell me if and why it's not possible. Thanks.
I am making a social networking site and would like emoticons to be available to users to click, and view a whole range of standard emoticons. I have seen around the web, and have not come up with any concrete information whether this can be done, and how.
The way I imagine the emoticons to be is similar to what WhatsApp have adopted. An emoticon icon, which, on click, displays a whole range of icons. Just wondering whether it is possible and if so, how?
It can be done, you would need a java-script widget for it though and depending on the rest of your framework it could be fully integrated or it would require some additional files.
Here is one example of such a widget, not sure if it is precisely what you need but you can get the idea there:
https://www.npmjs.com/package/emoticons-js
Umm, you can have a set of icons what you can display?
Or use the unicode entry points for the emojis?
http://apps.timwhitlock.info/emoji/tables/unicode
Then you need one element with some onclick handler in Javascript which opens up a floating div showing a selection of emojis.
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.
I have multiple html forms on a page and noticed that if the user is tabbing between form elements they can also end up tabbing between forms which I don't want to happen.
I've read the answer about forms that are not being used given here:
Multiple forms on one HTML page: how to restrict tabbing to a single form?
I'm wondering if there is now a better way to keep form elements knowingly grouped together y the browser so that tabbing will loop between elements within the same form only. One would think the use of the form tag would suffice but clearly this was something that went over the head of those browser vendors we all know and love.
Edit: This is for a webapp not a desktop website.
You probably found a solution already but hope it will help others.
I had similar problem and created tiny jQueryUI plugin that limits fields that TAB affects. you use it simply:
$(".someGroup").tabGuard();
and that will make tab iterate over fields inside of .someGroup wrapper. This way you can group various forms on a page and the one in focus will keep iterating on TAB or Shift+TAB if that makes sense. Find it here:
http://tomaszegiert.seowebsolutions.com.au/tabguard/index.htm
I hope someone will find it useful.