In native WinForms programming there was the concept of "AutoComplete" with a mode "Append" where, as you type, the rest of the textbox would fill in with a suggestion which would be highlighted. If the user continued typing, that suggestion would naturally be replaced with the text entered, and the auto-complete suggestion would append again if available.
In web contexts, I have only seen auto-complete implemented as a selection dropdown below the input textbox (e.g. jquery autocomplete). There's also the input tag autocomplete attribute, but the options can't be controlled by javascript. Searching for "autocomplete" and "autofill" dead-end with issues relating to the autocomplete attribute.
If "AutoComplete Append" is used in a web context, does it go by a different name?
Is there a reason that this paradigm is avoided (or, doesn't even exist) in web development? (it seems particularly useful in mobile websites where screen real-estate is at a premium)
Related
I have an existing (search autocomplete) component that needs to be made accessible.
The component consists of a text input, which on input opens a combobox (with data fetched from the server) which shows the data in a grid-like layout with additional information like categories and some visual styling (the icons are purely decoration and can probably be hidden from screen readers). To my understanding, this would be implemented according to this example.
However, the options in the combobox are also grouped by type (eg. "Content", "Categories"), which, in a combobox using a listbox, would be implemented using the 'group' role like in this example. I know this is an editor's draft, but in the spec it is already in the working draft.
Now, is it possible to implement this in an accessible way, having both the grouping (ideally with the grouping semantic available to the screen reader, like with role='group') and the additional information (ideally in gridcells, as in the example)?
Or will I have to resort to hiding either of them, to either using a listbox and hiding the additional information from the screen reader, or by using a grid and having either no grouping or just rows that are non-interactive and have no semantic meaning?
Note: I have no influence over the styling/layout, only what is presented to the screen reader. I am aware that this is not the most ideal starting point.
Can someone advise me if there is a specific WCAG 2.1 failure when buttons are used as links. Same question vice versa. Links as buttons.
I have a site i am working on where by design there are links that appear the same as the buttons do.
So you may have buttons <button> like:
Edit details - which takes you to a new page where you can edit items in the page where the "edit details resides".
Continue - a button that takes you to the next page in a series of pages.
But then have links <a> which appear as buttons, so the same style, but they are labelled select, select and selected and these are a product type, so do not link anywhere.
Another example is the back link is a button<button> but looks like a link (text with underlined style)!
I know that this behavior confuses voice recognition as the user says click link or click buttonand not all objects get flagged that appear the same.
My question is does this fail WCAG2.1 specifically? Would this fall under 4.1.2 Name, Role, Value?
The 4.1.2: Name, Role, Value undestanding addresses the case of elements having different role than usual.
If custom controls are created, however, or interface elements are programmed (in code or script) to have a different role and/or function than usual, then additional measures need to be taken to ensure that the controls provide important information to assistive technologies and allow themselves to be controlled by assistive technologies.
As Adam already cited, "additional measures need to be taken to ensure that the controls provide important information to assistive technologies and allow themselves to be controlled by assistive technologies". So yes, this fails WCAG 2.1, unless you take measures to ensure that your button-links and link-buttons really work as they are supposed to for example that a <a role="button" […] can be triggered using the Space key.
If you really have accessibility in mind, don't mix <button> and <a> elements up. Not even if you think you are smart and add role="button" to a link or role="link to a button. You would have to do more than that to make them behave like each other (see MDN about the button role).
And even then you should consider this: links are for navigation, buttons for performing actions. If you have a navigational element that looks like a button, its behavior might be confusing (even if it has no role="button" attribute). Also note that the default value for a button's type attribute is submit ("The missing value default and invalid value default are the Submit Button state.").
Web accessibility should encompass all disabilities that affect access to the Web and there are a lot of possible disabilities – and having one disability does not necessarily mean a person has no other disabilities.
The easiest step of making your website more accessible is to stick to the standards. Don't change an element's behavior unless you really have to (and even then: do you really have to?).
Update: General comment about WCAG and accessibility:
Web accessibility is also not just about simply conforming to guidelines like the WCAG. Even the WCAG itself does not claim that a website will be 100% accessible when conforming to it:
Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, as well as to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community.
Update: Examples of possible violations of WCAG 2.1 (with room for interpretation though)
Just letting links look like buttons and nothing could be failing:
Guideline 3.2 Predictable in general ("Make Web pages appear and operate in predictable ways.")
Success Criterion 3.2.4 Consistent Identification (unless all links look like buttons; the only actual success criterion in these examples)
4. Robust in general ("Content must be robust enough that it can be interpreted by by a wide variety of user agents, including assistive technologies." & Guideline 4.1 Compatible "Maximize compatibility with current and future user agents, including assistive technologies." --> you already mentioned voice recognition and the possibility of not being able to target a link because it looks like a button)
Jonathan Pool wrote a blog article about this issue in which he points out another possible violation:
Worst case: A button that takes an irreversible action ("Yes, I confirm that I am waiving my rights.") pretends to be a link, so the user tries to use SPACE or SHIFT-SPACE to scroll the page but unexpectedly presses the button. This, arguably, would violate Web Content Accessibility Guidelines 2.1 Success Criterion 3.3.4.
So I read a lot of articles that say that HTML 5 form validation is accessible (things required attribute which will prevent the form from being submitted is a field is left blank), yet when I tested my form on NVDA on Chrome and BackTalk on Android, if I hadn't filled in the input, it focuses back to the input field (which is good!) but both screen readers announce "Please fill in this field" which is useless to the user, since they don't announce the label of the field.
So HTML5 validation alone isn't accessible? Also, can you combine HTML5 validation and custom JS?
Do you have to write custom client site validation in order to make forms accessible?
Short Answer
Yes the standard HTML5 validation is accessible and will pass WCAG2.1 AA, but you can do a lot better with some JavaScript.
Long Answer
If you need to support Internet Explorer 9 or below then you will need to use JavaScript (which according to WebAim survey - section "Browsers" still covers around 3.6% of screen reader users).
Native HTML5 validation is a very good starting point, but there are limitations (you gave one in a comment, some screen readers (NVDA) do not announce the label again, meaning a user has to physically ask for the label to be read via controls).
The other thing is that once you leave a field it doesn't normally tell you you have made a mistake until you have submitted the form (it is meant to but this is not always the case depending on your announce speed, settings and browser).
For example updating aria-invalid is useful for immediate feedback (and provides support for older browsers, while being more robust with 'unusual' screen readers).
Using an aria-live region to provide immediate feedback onblur (or throttled / debounced) is also useful and a better solution.
One other thing is that the native validation is not actually very effective. For example fff#fff shows as a valid email and will allow a form to submit on a type="email" field, same with type="url" it will allow https://fff to be submitted (in Chrome at least).
I could go on with other things such as providing better instructions on how to fix errors (especially for things like phone numbers) but you get the idea.
Basically, use as many native HTML5 features as possible to give a solid grounding and a good fallback for JavaScript errors / people not using JavaScript. Then use CSS and JS to improve the experience for everyone.
Also, can you combine HTML5 validation and custom JS?
You can and you should but be aware that you end up doubling up validation (which isn't a bad thing as I stated for fallback).
The beauty is you can use pseudo selectors in your JavaScript to target fields by type, saving the need for adding unnecessary classes etc.
e.g. document.querySelectorAll('input[type=email]') could be used to select any email input for validation or document.querySelectorAll('input[required]') to find all required fields.
You can also use things like max="100" on slider / numeric inputs to set your validation ranges 'on the fly' and still have a fallback for no JavaScript.
As you can imagine this let's you write a library if you can't find an off the shelf one that is reusable on nearly any form.
I just read this post about the term "control" when dealing with forms.
However, the OP asked it in relation to Bootstrap, and I'd like know if this term has a general definition, and more importantly: Does its usage relates only to web forms, or does it have more usages in web development?
Typically, a "control" is a UI element which causes some action to occur. For example, both text inputs and submit buttons are examples of "control" UI elements.
There are special control elements implemented by specific frameworks or platform ecosystems. For example, there are many variations on calendar UI element controls.
Form controls are those elements (which you use in conjunction with a form) that the user interacts with directly. Examples include text boxes, drop down menus and buttons.
From the specification:
A form is a component of a Web page that has form controls, such as text fields, buttons, checkboxes, range controls, or color pickers.
and
Most controls are represented by the input element, which by default provides a one-line text field.
I've been developing for some time now...every now and then I find out about more HTML tags, PHP functions etc that I never new I had at my disposal.
Today, I'm talking about the different HTML input types....well, only one and then some link->rel values...
Input type: search?
I have looked in several places and all I get is the obvious answer of what it's purpose is.
I can do fulltext queries just fine by making the field a text type...
so what's the technical difference between the text and search input types? and are there any benefits of using making the input field a search type?
And, I have similar misunderstandings with some of the rel values of the link tag:
Next, prev, search etc...
I can do the same things without using those rels...I can create a 'slideshow' of articles without using next/prev. search, i don't understand at all... I can only find the defeintion of it..'Links to a search tool for the document'...does this mean a tool like that which google provides so your users can search through a document?
I can do these things without using s altogether so I'm guessing the answer to my question is in the fact that I don't use for these tasks and maybe I should? Combine then with AJAX?
Thanks
At the moment, there are no differences between input type='search' and input type='text'. The reason these new HTML input types are put in place is so that functionality can be added later in the future. It's good practice to use type='search' when you are creating a search field, as it could become more useful in the future and it also makes your code more semantic.
There are really some differences are there between "search" and "text"
These two are rendered differently according to the browser. safari, Chrome like browsers adds a cross icon to clear the field more quickly than normal text field.
And in smartphones it changes the normal return button of the soft keyboard into magnifier or search button. which is more user friendly
some browsers will trigger certain applets while user is on a search field
HTML 5 defines a lot of new input types such as date, time, number, email, ... (you find a complete list here) which can be used by modern browsers to provide more functionality such as validation or support for input.
The browser can display a calendar for date inputs. On a touchscreen a different keyboard (containing #) is shown for an input field of type email or phone. For the search attribute an hourglass might be shown.
You should always use the new input types, as they provide more semantic information. An old browser will interpret them as <input type="text" />. A disadvantage is that different browsers display the same field differently and some browsers do not use the tags at all. For input type search a magnifier might be displayed.
Your second question is about link types. Again, this is semantic information mainly for search engines or user agents. The different link types might be displayed in a separate navigation bar.