The following is a fairly typical layout for admin pages (e.g. searching in a database and doing something with the results):
action dropdown
table header row with column names
second table header row with search filters for columns
result rows with a checkbox
search button
The user can set all sorts of filters, search, select some of the results with the checkboxes, then select an action from the dropdown, and the action and the selected row ids will be submitted to some processing script.
There are some basic expectations for such a control:
GET for searches, POST for actions
use the auto-sizing features of HTML tables so that columns can be narrow or wide depending on the content
reasonably cross-browser
I have been looking for a nice technique to achieve this, but everything I can think of seems to have serious disadvantages:
the simplest would be having two forms (a GET form for the search controls and a POST for the checkboxes), but the HTML4 DTD makes that impossible: I can either wrap the whole table in a single form or put separate forms inside every table cell (which is pretty useless).
alternately, I could use a different table element for every row and group them freely into forms, but then the column widths would not match and I would have to set fixed widths. (CSS3 table-* display types lack adequate support.)
HTML5 allows us to place input elements outside forms, and connect them with the form attribute, but that has even less support.
There is an ugly hack involving invalid HTML with forms directly wrapping tr elements, which seems to work but messes up the DOM, confuses Javascript libraries and is not exactly future-safe.
I can wrap the whole table in a single form, and change its method and action dynamically depending on which button was pressed, but that makes me dependent on Javascript; also, I don't want to submit search controls in the POST request and vice versa, it is unnecessary traffic. Also, when there are a lot of result rows, the search request might surpass the URL size limitations (just a few thousand characters in IE) because of all the checkboxes.
I could do the same but disable the unnecessary fields when the user submits the form. Beyond being horribly overcomplicated for such a simple task, this has various usability problems when the request is somehow stopped (e.g. user pressing ESC) and the user is left with a bunch if disabled form fields.
Is there a better solution I am not aware of?
Use AJAX. It allows you to define your own get/post data that is not form-dependent.
Related
My team and I are building a web-app for a customer who has requested custom functionality pertaining to data-tables: upon clicking the header of a given table column, the table then becomes sorted based on that column. This functionality is already implemented.
However, an important stipulation of the contract is compliance with WCAG 2.1 accessibility standards. Aside from within tables, we have aria labels in all the right places, but it's unclear how we should go about making this custom table behavior more accessible-- particularly for screen-reading tech. As of now, the table header cells themselves have event-handlers for clicks to trigger the functionality, but no semantic <button>s are involved in this process, which is where things start to feel a little wrong for me.
The table header cells are also focusable, so that users can use Enter or Spacebar to toggle the functionality that way. How should we handle communicating this behavior to the user, especially those using screen-readers? Since this functionality is not typical of what is otherwise a fairly standard table, guidelines and requirements from WCAG and other sources are unclear.
I apologize, but I am unable to provide a screenshot or code snippet due to the sensitive and proprietary nature of the content.
For any table that is readonly and also is meant not to be sorted etc. standard HTML tables should be used.
In your case please use the design pattern grid from the ARIA 1.1 guideline (chapter 3.12 under this link https://www.w3.org/TR/wai-aria-practices/#grid)
Your customer should familiarize himself about the keyboard commands ARIA declares for grids. Manipulating theese keys will mean much work to you and irritating the screen reader user and hurt WCAG.
Here are two decent examples of accessible sortable tables:
https://assets.cms.gov/resources/framework/2.0/Pages/datatables.html
https://adrianroselli.com/2021/04/sortable-table-columns.html
The first one is a little too wordy with it's announcement to screen readers and could be shortened up for a better user experience and the second one is a little too terse with just saying "title button". We need a Goldilocks example between the two but both examples show how to use a <button> in the table header and the use of aria-sort.
I didn't hear anything in your OP that would indicate that a grid should be used. Note that the first sentence in the grid definition says that a grid is "a composite widget containing a collection of one or more rows with one or more cells where some or all cells in the grid are focusable by using methods of two-dimensional navigation, such as directional arrow keys." In other words, if the user will be able to navigate the table using the up/down/left/right arrow keys (as if you're navigating through a spreadsheet), then a grid is appropriate. But if you have a "normal" table that does not allow navigating cell by cell, then a standard <table> can be used. Just add buttons to your column headings (<th>) that allow the table to be sorted.
I have an html table and I want to be able to hide and show columns dynamically (based on certain values on page load). It could be a large number of columns I need to hide.
I was considering taking the values from the columns that I want to be hidden and putting their values in a data- attribute on the <tr> element to and avoid creating dom elements that aren't being shown in the ui. I need the values somewhere because they are used in click events.
Are there any best practices out there that say it is bad to load columns into a table and hide them with say display: none;, or am I just over thinking it and being anal and should just hide them with css?
I'm unsure of any types of practices particularly for this application. Also based on the information given so far.
The way you are doing it is not the best choice of going about this situation. You are taking data and putting them all in their own elements which not only clusters up HTML with unessessary elements (that are always hidden by CSS) but also can be more taxing then it has to on you and your viewers computer.
When you could be using the data attribute this is a great way to keep the information more consolated, less clutter, well organized, easy to read and manage. Also even when a element has the styling display:none it is still using the computer performance to render all of those elements.
You can read this thread that explains: Read More
In many prototype scripting cases, it's easier to just stick every form item (such as an input or textarea) in its own form tag. Is there anything wrong that could happen from having lots (like 1000) form tags in a page?
What do you mean by ‘prototype scripting cases’? How are the forms being submitted?
If each form is its own action, eg. you have lots of separate product listings with different REST action URLs, then, yes, a separate form per line is appropriate.
If you're just using controls on their own for scripting, and have no intention of submitting them through the normal HTML form process, you don't need any <form> elements at all, just include them bare.
(Except in the specific case of radio buttons, which require a <form> for grouping.)
Should not be a problem but why do that when you can just use one form. It will work even with 1000 forms but it would be stupid with over 50 anyway.
There is nothing particularly wrong with it, but It would be a better idea to have them all in the same or fewer.
I would say, first off, have 1000 inputs on a single screen poses a different problem that should be addressed first. That many controls will be completely unusable.
That being said, having each element in its own form will cause more overhead in processing your page. You'll have to decide whether the impact of this is too large in your scenario.
You will lose the info from other input elements when submitting any of these 1-input forms, since a form submission ONLY submits the values for input elements of that one form.
If you're OK with that in your prototype, not a big problem
The only thing wrong with this is the semantic process of what a form is. A form should only submit what the fields inside of it have. So, anything related to that "form" should have the proper fields with in it.
Technically, when using a form it'll take you to a new page, so, any of your values in any other form on that page will be lost. The only way around this is using javascript to ajaxily submit the data.
There is no issue with using the HTML markup in the way you are wondering. The only thing you will want to worry about is the more control structues you add to your HTML the more text the web server needs to serve up. This will lengthen the amount of time it takes to get your code from the server to the users browser.
My application has a requirement such that I have to display a huge number of HTML input textfields (maybe 2,000 text fields). The fields can be logically grouped into sections and the sections are repetitive. What is the best way to display it to the user so that they can enter data with minimum clicks?
I'm not sure what kind of users you have that would willingly sit through 2,000 text fields, but if it's a requirement, then you do what you have to. :)
You say it can be grouped into sections and the sections are repetitive. I'm not sure what parts are repetitive, but managing the sections carefully seems of utmost importance. Some sort of Javascript hiding/showing seems likely to be a big help... I think I would choose JQuery's Accordion effect or something similar.
You could add Tab key events to each section in order to assist with navigation and open a new section once an old one was complete. Adding change events to the fields might assist with that as well.
If you need to break the form up across multiple pages, then you'll probably want to utilize AJAX to load new sections/pages and store the submitted data into a session until the user is done.
Depending on the format of the required answer, there are two ways:
If the answer is of a known length or the answer is one of a few choices, you may auto-advance the cursor w/some javascript/jquery. For instance, if you're expecting phone numbers, when the person enters the 10th digit in the box, move the cursor to the next box.
If you don't know and you can't apply (1), the quickest way is to encourage users to tab their way through the boxes.
Speaking of tabs, if the boxes can be logically grouped, you could create tabs and have the users page their way through the questions. This will create more clicks, but will improve user experience.
But holy crap, 2k text boxes on one page is crazy!
I work on a similar product, and perhaps the number one thing would be to make sure that tabbing between fields works logically and quickly. The people who do data entry on this type of thing are lightning fast and fairly mindless (I don't mean that in a pejorative sense), typing in numbers from a log or printout without looking at a screen.
Apart from that, we implement tabs (like tabbed browsing) on the page, group boxes, and other things like "dynamic lists" which is like a data grid of text boxes that the user can add and delete rows from client-side.
Paged format, like a survey? You could then use SESSION to store the input for each page and retrieve the prior answers when the user switch between them. Another method is to use ajax to navigate between different . I think the issue is not the number of clips, but 2000 textfields is going to look scary on just one single page.
I inherited an application where display:none was used to control conditional display of input elements based the values of other input elements.
The way this was handled is by running some pretty ugly code to evaluate field values and reset the display property in the during page load. Every time.
Isn't there a better way?
Using display: none in conjunction with JavaScript and CSS is the easiest way of simply showing or hiding DOM elements on the fly. That said, you could manipulate the DOM itself by adding or removing elements rather than simply showing / hiding them (with jQuery, for example).
Maybe your should just redesign the form that uses all the display: none fields or rewrite/refactor the script that does this checking? If the form is too large split it into several pieces - this will help the user too. I personally don't like if the form changes often whenever I am trying to fill in everything.
If you are not showing and hiding elements dynamically as the user interacts with the form, then there's no need to use CSS/Javascript. Just use your server-side language (PHP/JSP/whatever) to not output the hidden fields. You'll use less bandwidth, and the form will work even with Javascript disabled.
Is the idea to reshape the form on every POST or reorder fields before submitting. If the first then the fields shown should be removed on the server-side before page get to the user. If you are talking about changing on the client side before a post (e.g. removing fields which are not relevant based on the input in some fields as the user types), you can use javascript to remove fields from the DOM.
The two things your solution needs are:
The forms must be functional without javascript (even if they feel less slick)
Don't submit fields the user cannot see unless they are input tags with type="hidden". You will only confuse yourself on the backend if you don't know whether a user left a field blank or could not see it because it dynamically had its styling changed by a client-side script.
there is an partial alternate to display:none i.e
use this style in css
opacity:0;
but problem with this is it doesn't appears on canvas but it is still there.
using display:none; completely delete element and creates when u apply attribute display:block;