Accessible javascript alternatives to select elements - javascript

I am developing some javascript code that will replace a standard select element with a javascript controlled dropdown menu which will redirect users to a particular page. The standard select element must work when JS is disabled
An example of what I want to achieve is here: www.play.com
What I have noticed with this site is that they simply position the select element behind the javascript alternative. This means that both controls are available to screen readers and keyboard users.
Does anyone have any experience of setting such functionality up and have any suggestions for the best methods to ensure accessibility?

Plain links would be your starting setup, as they work to take users to new pages without any additional scripting required.
You can put them in a container ul, and then use javascript in a 'progressive enhancement' way to turn the list into a dropdown (by re-writing the html) for the people who've got it turned on. This way, a user without javascript turned on will have no problems, and the majority of users will see your drop-down menu.
Even better, don't use a select menu for navigation. It's not really semantically correct, and requires more work to make it operable and robust.
Try something like the Suckerfish drop-down menus which are based on nested lists: http://www.htmldog.com/articles/suckerfish/ or if you want a bit of jQuery fun: http://users.tpg.com.au/j_birch/plugins/superfish/#sample1

Related

JavaScript accordion behavior when it won't expand - set an href?

I have a JavaScript accordion on this site that features within it, the primary functionality for the site. It is based off of this post.
When someone has JavaScript disabled or for whatever reason the panels aren't expanding, is there a way to set it so that clicking on them will act as a traditional hyperlink?
That way users can still be directed to content that they need and the site isn't "broken" for them.
You can use the noscript tag to provide content for those that have JS disabled. That should work no matter what plugin you're using.
Read more: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/noscript
So, basically, you can really go creative and build a separate menu for non-JS users.

dijit form select does not behave like HTML SELECT

I am using dijit.form.Select as a replacement for the HTML SELECT.
I am unable to get it to allow me to select an item purely by typing as you can with the HTML version. Ie, if you have a list of US states you can hit C several times to select Conneticut. What am I missing? TIA
And yet, it works on the web page below....
http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test%5FSelect.html
When designing a select element that is visually consistent with a UI theme, CSS is often not powerful enough to completely control the look of select element, as some browsers treat CSS stylings on a select element differently. So the next best thing for many is to develop a faux-select with javascript so that way you have a better looking select element.
What you're left with is something that looks like a select element, but isn't, and the real select is hidden nearby, typically.
That means that there is a good possibility that when the developer was making that javascript version of the select element, they didn't do their diligence to at least program the minimum features that come native with the HTML version. (after all, it would be a lot of work to do string searching and sorting on a keyup event... and i'm not surprised they didn't do it)
to add insult to injury, sometimes the plugin actually allows for the change event on the native select to still be focused beneath the surface, which is why your typing works sometimes.
A chap named Bob Tarling has solved my problem. Much obliged Bob!!
See this link for his solution http://dojo-toolkit.33424.n3.nabble.com/Sharing-a-solution-for-type-ahead-in-Select-and-help-request-to-adapt-tt3995899.html#none

Trigger event when a particular text fragment shows up in Find? (ctrl-F)

When the user searches for text within a page (⌘F or Ctrl-F), does it trigger any Javascript-accessible events?
Here's my example use case:
I have an information-dense documentation page where the primary sections are listed in a sidebar.
These primary sections expand to show sub-headings (hidden until user views that section).
Sub-sections can be difficult to find, unless you've been deep-linked to the page.
It'd be nice to piggyback on browser "find" functionality, so that if the user searches for some buried item, the JS will detect it and reveal that section.
Please disregard the UX assumptions here. This could also be easily accomplished with a custom search field that exists on the page. I'm only curious about the technical feasibility of detecting (and piggybacking upon) the built-in browser find functionality.

Make javascript mandatory in web application?

I am building a web application that will have a fair bit of forms. The html forms are generated using php.
One of the things I came across is this:
I have a drop down box for the user to select his country. Once he selects the country, a call is made to the server to fetch a list of states within that country and populate it in a drop down box.
Initially, I thought I could provide 2 options:
An enhanced jquery version where ajax is used to fetch the states and the populate it in a drop down.
Where javascript is not availiable, the whole page is submitted to the server and then rerendered with the new states in the drop down.
However, onChange() requires javascript. So if someone where to visit the form without javascript enabled, there's no way we can deal with the second option, since javascript is required to submit a form using onChange().
What are some ways to deal with this? My only solution at the moment is to just make javascript mandatory. Users without javascript enabled will see a message saying that the page will not work properly.
Some sites:
Hotmail.com - Refuses to show anything except a "javascript is required message"
Facebook.com - Tells us we should use the mobile version of the site.
Google Maps - Does not work. No message to say javascript is required.
Gmail - Falls back to basic html.
Google account - Does not work. No message to say javascript is required.
Is it acceptable to require users to have javascript enabled at the current state of the web (august 2011)?
Just came across this possible solution:
http://cita.disability.uiuc.edu/html-best-practices/auto/onchange.php
I could perhaps add a button which the user can use to select their country. This should allow us to reload and render the form with the states drop down without any javascript.
You can provide a drop-down of states and tell the user to leave it blank if not applicable. If JavaScript is enabled, it can remove the drop-down until a country where it is applicable is selected.
No, it is not acceptable to require JavaScript; many security-conscious users use NoScript, for example, and would prefer not to turn it off.
By default you should load all possible values into the second dropdown, then clear them out on page load with Javascript. That way people without Javascript enabled can still choose the correct option.
I'm guaranteed to take flak for this, but whether you support no-JS or not should be your call. If you think your userbase is likely to have a sizeable portion of people who disable JS, then you should give them a site that works, but not optimally. If you think most of them will be running with "normal" (air quotes are important there) browsers, then you may consider dropping support for no-JS users.
I am NOT a professional developer, so take my input accordingly. Here are my observations:
I support a website for a wedding cake vendor. Upon observing the competition, all the more appealing sites are embellished (tastefully) with slideshows, dropdowns, animations, interactive form validation, etc.
When scouting for methods to incorporate these features into our site, I found that mostly every classy method was based in javascript.
Figuring it was better to present ourselves as the classy act we are (humble smile), I have decided to require users to have javascript enabled. We've been up for 7 years, and I have not received any complaints. All work on mobile devices.
A compromise option is to start with your State drop-down populated with the states of whatever country your business is in, e.g., all US states, with an extra option (preferably at the top of the list) that says "Other, non-[yourcountrynamehere]". Next to the State drop-down have a text input where the user can type the name of their state if it's not in the list. If JavaScript is enabled then on document-ready you can hide the text input and go with your Ajax solution. Without JavaScript the user has a fully functional page that doesn't even need a reload.
What I ended up doing is to add a button beside the drop down that says "select country". Users without javascript will see this button. Upon clicking it, the page will reload with the list of states rendered.
For users without javascript, this button is hidden, and selecting a country will automatically render a new drop down containing the relevant states.

Creating a Better Tabbed Interface in Django

I've been trying to create a tabbed interface using Django. The current effort (which works fine) is having each template have the header hard-coded in, with the selected tab given the "selected" CSS attribute. Of course, this is a massive violation of DRY and I'm looking to remedy it.
My current idea is adding a jQuery script to the page that looks at all the tabs and sets one to "selected" if it's text matches the beginning of the title for the page. Is there a better way to do this without using JavaScript and just pure CSS?
Update: The below link is broken now, however Django now has in built feature for comparing URLs now. Check this bug for more details.
You can create a template tag to implement it have a look at this http://gnuvince.wordpress.com/2007/09/14/a-django-template-tag-for-the-current-active-page/
You can implement something similar for your case.
I usually just pass in the selected tab in the context in each view that utilizes the tabs, and select the tab in a common header based on that value.

Categories

Resources