I'd like to design a textarea with autocomplete, because it is possible to enter there multiline addresses which can be filled by your available addresses.
The goal is to design it WCAG AA conform, but I saw that a role "combobox" with popup is not allowed on textareas!
Is there any solution you can provide to help me? Can be programmatically with JavaScript or pure HTML or TypeScript.
After working with web accessibility for nearly 10 years, my experience is, if something is not supported either via the HTML og WAI ARIA documentation, there is often a good reason behind it.
First, a user who encounters a textarea, wouldn't expect that it have an autocomplete function.
Second, a screen reader is optimised to follow the documentation. It is property possible to make the textarea work without a role="combobox" and get a screen reader to understand that it's a combobox. It might work on one screen reader, maybe two. And if you test it enough you might make it work on several browsers and OS.
But there are so may screenreader, browser and OS combinations. And you must consider that a lot of users use outdated software, and that count browsers, assistive technologies, and OS.
I've seen so many elements that doesn’t follow the documentation and give so many users a lot of problems, for example the button-element used as a drop down.
An element only must work with one major browser and one major assistive technology to be WCAG 2.1 conformance.
If I was you, I would make the three address lines in three different input-elements, and follow the WAI-ARIA Authoring Practices for combobox with listbox popup: https://www.w3.org/TR/wai-aria-practices-1.1/examples/combobox/aria1.1pattern/listbox-combo.html
Related
Is there any way to limit height for dataset dropdown list? When I use <input list="datalist"> and the datalist contains many elements, I'm not able to see them all. Can I limit the list size and add vertical scrolling to list all the alternatives?
I searched the web and the only answer I could find was that it's known issue without solution and to avoid it I should use jquery-ui combobox instead. I have javascript logic based on dataset so replacment with combo would require much effort.
Maybe there is some workaround to achive a limited list in html5?
The short answer is no, there is no easy way to achieve this without JavaScript. It is entirely up to the browser to render an input with a datalist. It will likely differ between browsers and devices as well.
If you go for JavaScript it is a lot of extra work, as you say. Do not forget about touch devices, keyboard navigation, visually impaired visitors and the tools they use when browsing, etc. Research available alternatives carefully, do not take for granted that they are are all good enough for your users. Unfortunately I do not know which ones to recommend myself.
Today, HTML tags support "title" attributes on all major browsers. When you hover over an option in a drop down list, the title will appear as a tooltip. What event allows the title to display?
I should state that this is my first time asking a question. In keeping with the guidelines, I have researched this quite thoroughly to the best of my ability but I am not an expert in this area. This topic has been covered repeatedly but there has never been a definitive answer (at least I can't find one). I have coded many approaches and all of them work in Firefox but not in any other commonly used browser. I have seen many dated suggestions but almost nothing after about 2007 and none of them work (not even the ones specific to IE). Either I am missing something or I still have a lot to learn (both are likely).
Obviously, I am looking for something beyond a simple text tooltip. What I would like to do is display a small image nearby as the user moves the cursor over the various options in a select list. Piece of cake in Firefox (I can do it several ways) but no other browser seems to support this. Apparently, the other browsers do not support mouseover or hover on option tags yet, that title will appear. There must be an event that triggers it. Why can't it be used?
Any and all ideas and suggestions gratefully accepted. Thank you.
this is not implicitly supported by official DOM so you have to create custom dropdown box.
http://www.sitepoint.com/16-jquery-selectboxdrop-down-plugins/
you can code it to work however you want but there is no way to do it with html dropdown(select/option) element.
Seems that with handheld devices on the rise, one has to start taking them into account more and drop IE6 instead.
With that in mind, it has come to my attention that certain things don't work as well as can be or at all on say, my iphone.
what seems to break includes (but not limited to):
mouseover/mouseout events (can break almost anything)
CSS pseudos :hover as well, naturally (breaks nav CSS-only menus, for instance)
DOUBLE CLICKS - it zooms instead of the event handler
CSS-related issues (minute, it seems to work just like in Chrome w/o the gradients + some font-size issues)
the real question is: do you have any guidelines, articles or whatever that can cover things below or any advice you can give.
where do you start in order to transliterate the experience for desktop users over to mobile ones? do you try to make a separate skin for mobile devices or do you alter / fix your site to work as best as possible - how much maintenance and work is involved in either approach
are there any frameworks (CSS or JS) that can abstract that and do the graceful degradation where required? boilerplate comes to mind, jquery-mobile mootools-mobile (power tools)?
what do you replace things like the ones above with, click events?
how do you incorporate swipes into a web app? can you handle and respond to finger zooms? should you?
additional events like shake, tilt - do they bubble to the browser window?
do you do anything to accommodate awkward OS elements like select, checkbox and radio?
resource management - do you use a detection layer that will only send whatever files are particular to the device as opposed to generic js libs that can deal with both?
as for device support, I am interested in droid and ios only so javascript support will be pretty good - would you drop your main framework and go with a micro js lib instead?
and finally - do you have any impressions on how viable handheld devices are for e-commerce and monetisation (currently and in the near future). I would like to make sure from a business standpoint that the dev work will be worth the expenditure and we're not going to go after buzzword gimmick like '#socialmedia'. any data on conversion values in comparison to the desktop ones? this can help me gauge if these are used as a quick browsing instrument or can actually do the full monty.
any examples of a site that does a great job of working in mobile and desktop at the same time or through different designs, I would like to see them and find what's even possible.
thanks in advance.
You've just asked a lot of questions I've been asking myself recently. I can't give great answers yet as I'm still researching and exploring. but here are some useful links.
Rethinking the mobile web
Mobile emulators
How to build a mobile site
I hope this is at least a little helpful.
I can answer the conversion rate/business viability part of your question.
I had the chance to see Omniture numbers for some very, very big ecommerce interests and the answer is that conversion can be somewhat less, somewhat more, or about the same. There was a pretty good amount of variance depending on the device and the seller's site.
It's what you'd expect though, I think. The quality of the mobile/tablet experience varies a lot right now depending on how well each business optimized for mobile (and for which mobile devices). I think conversion varies a lot as a result.
following link should help. To make website like a nativeapp, jQuery plays amazing role
http://blog.2partsmagic.com/2012/07/developing-web-application-ipad-android-tablet/
I need to build a wysiwyg editor for a project I am working on and need some guidance. Some of my key points of confusion are the following:
iframe docs vs. contenteditable divs: which one should I use and why? I hate iframes, is there a clear advantage to using iframes?
cross browser styling: execCommand seems to apply different styles in different browsers. Are there any tricks to making this cross-browser compatible? Should I not use execCommand at all and instead apply my own styles?.
adding items to the undo chain: how can run my own script, such as inserting an image, and allow cntrl+z (undo) to remove it? Is there an array of undo/redo items for contenteditable that I can push items into?
keeping the text selection: how I can maintain text selection while making operations such as selecting the font style, where the focus will leave and remove my selection. Rangy? Google closure? Are there other range/selection libraries worth looking at?
Any tips on these items or anything else related to building a rich text editor would be greatly appreciated!
From personal experience, I recommend against doing this unless your aim is to provide a very limited amount of functionality. The sheer number of browser differences and the complexity of their workarounds makes this a very tricky and time-consuming task if you want to do it well.
If that hasn't put you off, here's my thoughts on your individual questions:
iframe docs vs. contenteditable divs
I recommend the iframe approach, for two main reasons:
You have complete control over the document type, CSS and script within the iframe. This is essential if you want consistent behaviour and appearance and want to use your editor within different pages.
Firefox in particular is quite buggy with contenteditable elements, which they only introduced relatively recently (version 3.0) while designMode has existed on documents for many years (since pre-1.0; around 0.6, if memory serves) and works pretty well.
cross browser styling
If it's important for you to have uniform results from applying styles in different browsers then in general you will need to write your own styling code. However, doing this will break the built-in undo stack and you will need to implement your own undo/redo system.
adding items to the undo chain
There's no programmatic way to interact with the built-in browser undo stack. You'll need to write your own.
Update November 2012
There is a spec in the works for custom undo/redo so this is likely to be possible eventually. Here are the relevant bugs for Mozilla and WebKit.
keeping the text selection
I have to declare my interests here, since I wrote Rangy. I don't think there's a better library out there that does a similar job; Google Closure does have a range/selection API but I think it uses their own proprietary interface rather than emulating DOM Range and common browser Selection objects. IERange is another library that is similar in idea to Rangy but much less fully realized and seemingly abandoned immediately after release by its author.
Don't, seriously don't.
What you are suggesting is a major undertaking. You really should be looking at TinyMCE, http://tinymce.moxiecode.com/, or CKEditor, http://ckeditor.com/. Getting what you are after is a massive amount of effort to get working for one version of one browser, to make it portable will take man-years of investment.
A better solution is to look at things like TinyMCE's plugins, http://tinymce.moxiecode.com/plugins.php. You can get your basics the basics (and portability for free) and concentrate on adding the specific value-add items you need to.
I'm often conflicted about how to approach this problem in my applications. I've used any number of options including:
A generic multiselect - This is my least favorite and most rarely used option. I find the usability to be atrocious, a simple mis-click can screw up all your hard work.
An "autocomplete" solution - Downside: user must have spelling abilities to find the damn values they need, aren't exposed to ones they may not have in mind, and the potential backend performance of substring searching.
Two adjacent multiselects, with an add/remove button - Downsides: still "ugly" imo
Any number of fancy javascript solutions (http://livepipe.net/control/selectmultiple, http://loopj.com/2009/04/25/jquery-plugin-tokenizing-autocomplete-text-entry/, etc.)
I haven't been able to find any usability studies done on the best approach to this problem. Many of these alternate solutions are great when you're going from <10 elements to a hundred, but may break down completely when you are going from a hundred to a thousand.
What do you guys use? Why do you use it? Can you point me to usability case studies? Is there a "magic" solution that has yet to be discovered?
My advice is don't use generic multiple select controls. I've been running User Experience Research for my whole career, and every single time I test a site with multiple select controls, it always turns out to cause problems for end users.
I did a post on this a while back: Multiple Select Controls Must Evolve or Die
Sounds like you knew this anyway, though. Your real question is "what do I use instead?" Well, to answer this question you have to work out whether the user's task leans towards recall or recognition.
(i) By recall, I mean the user knows what they want to pick before they have even seen the list. In this case, it's probably easiest for them if you offer an autocomplete tool (as used very effectively on facebook, for example). This solution is even better when the list of options is also impossibly long to present on a page (e.g. location names, etc).
(ii) Moving on to recognition - by this I mean a task that involves the user not knowing what they want to pick until they've seen the list of options. In this case, autocomplete doesn't give them any hints. An array of checkboxes would be much more helpful. If you can show them all at once, this is helpful to the user. Scrolling DIVs are more compact but they create a memory load for the user - i.e. once they've scrolled down, they have to remember which items they picked. This is particularly evident when users save a form and come back to it later.
So - thinking about your problem, do you need a solution for recall or recognition?
I can't point you to any case studies, unfortunately, but what I can tell you is that I personally prefer large checkbox arrays in two-to-five column layouts. Sure, they take up a lot of space, but they are extremely precise and uncomplicated.
I think for any control - be it basic multiselect, double list, checkbox array, or any other solution - once you go over a certain threshold of items it's going to be challenging for the user no matter what.
Have a look at Dojo Toolkit's DataGrid control. It's by far the most flexible and powerful, and supports multiple row selections. It also has accessibility features built in.
The ExtJS library has some really good solutions for your issue. There a bunch of user extensions for neat-o combos and multi select boxes.
If you want a combo select list, you can add query searching and pagination, plus design the resulting drop-down using easy templating, like in this example:
http://extjs.com/deploy/dev/examples/form/forum-search.html
Here is a nice multiselect, in the style you seemed to describe:
*(main_site)/learn/Extension:Multiselect2
You can find all user extensions here:
*(main_site)/learn/Ext_Extensions
Plus, you can easily include it into an existing web page without alot of extra overhead. ExtJS's full stack is quite large, but to get only the JS files you need, they provide a nice builder tool to grab just those parts you need:
*(main_site)/products/extjs/build/
Just a warning: ExtJS has just released 3.0, but I'm not sure the user extensions have been upgraded. The "forum-search" was taken from a 3.0 example though, so it will work just fine with the latest and greatest.
(*) Apparently new users can only post one link...