Latest Submission August 31, 2004
Disabling browser functionality – when is it appropriate? Good reasons include preventing the user from using the “Back” button and to make the UI behave more like GUI application. Usability and accessibility issues include restricting user access to font size and accessibility options and other browser options.
Although there are numerous discussions on the reasons, pros and cons of doing this, specifically to maintain statelessness by removing the “Back” button, doing so now appears to be an outdated method for controlling the user navigation, and thus maintaining the correct server application and database states. The solution for many developers and designers was to remove all browser controls rather than meeting the challenge of controlling the state of the server/DB when the user presses the “Back” button. Some development groups solved the problem of maintaining state with greater ingenuity through the use of cookies, URLs or hidden form fields. The solutions involve maintaining what the user has completed to a persistent container such as cookies (user’s hard disk), the web page (browser’s cache) or the back-end server (the server’s RAM or hard disk). This is not to say that the solutions are easy to do; it does mean that there are now better solutions for the issue than just stripping out user access to the browser’s functions. Likewise, keep in mind that the user should be able to control, access or view certain functions and features at all times (e.g., text size, status bar feedback, refresh – error recovery, and printing) that would be difficult to recreate within the web page design without the browser controls enabled.
Tree – How should tree views be handled with open and closed graphics, +, - arrows, open or closed folders and what should JAWS say?
Tree views are a method of representing complex data/information especially in the case of information with a logical hierarchical relationship (e.g., file directory system, organization charts, genealogical family trees, and sitemaps for web sites). However, tree view controls are difficult to use for many users, especially novice GUI/Web users, and as such are not recommended in applications for these types of users.
Alternative controls to consider for small to large sets of hierarchical data are dropdown list boxes, or tab strips in combination with tables. Consider also using a more traditional navigation structure and organization (e.g., indexed menu layout). Even complex data can be represented by a flat display in a table or by using a search and results method. Furthermore, consider researching the mental models of users for the tasks at hand to see if the models fit intuitively into a tree structure, and not just the development group’s implementation model.
When a tree view structure is determined to be the best solution for the task and the information contained in the task, tree view controls can be represented with either plus or minus symbols, or with right-facing and downward facing disclosure triangles. The former is a MS Window’s method, while the later is a Macintosh method. Icons may be included with either set of symbols. It is also recommended that the depth of the tree be kept to only 2 or 3 levels. Many professionals cited studies in which all levels of users increasingly performed poorly the deeper the structure of the data went. In other words, information structured more broadly and shallowly (i.e., many branches with fewer leaves on each branch) is favored over the opposite (i.e., few branches with many leaves on each branch). However, remember the necessity of fitting the user’s mental model. Finally, there are visual indicators that should be present to assist in the meaningfulness of tree view controls; line connectors from parent to children, or by background color distinction at the different levels.
The way in which JAWS reads tree views has not been documented by HCI/Usability forums.
Red Ball, Error messaging
Research Conclusion:
When constructing error messages consider the following general guidelines:
In the case of form pages, present an error message box at the top of the page with some visual distinction from the rest of the form that lists all of the offending fields or missing data. Use a distinguishing font style or treatment for the message (use more than just font color, but don’t get carried away here). In combination with the error message box, use local messages at each place where there is an error (i.e., place a visually distinct, specific message in close proximity to the field where the error occurred, preferably above the field).
An example of the message presented at the top of the form page:
Three required values are missing on the form. Please provide information for the following:
- name
- email address
- phone number
The fields with the errors on the form would be marked with the following
above the field labels:
“*Type your name.”
“*Type your email address.”
“*Type your phone number.”
Depending on the form in question, client-side validation of some fields may help to eliminate some problems before the data is sent for server-side validation. One possible solution is to use client-side validations to access the HTML displayed, and make pre-determined error messages appear next to the fields (requires JavaScript). This eliminates the need to reload the page from the server so that the user does not have to wait for potentially long reloads, and it saves bandwidth to and from the server. The error checking should occur after the user “submits” the form. If the client-side code detects a problem, the user can make corrections to the noted fields and resubmit. At this point, server-side detection still takes place in cases where JavaScript is turned off on the client and/or the data must be compared to a database.
Hotkeys, what combinations, consistency and when used
Access keys may be used for advanced users or users with a lot experience with the site or application, users with disabilities, and for frequently used functions.
Consider using an attribute of a form or anchor tag in HTML. For example, ACCESSKEY="1" - where 1 is any character on the keyboard (e.g., this assignment would be invoked by the user as “ALT + 1”). Numbers may conflict less than letters with access keys already assigned by browsers. The most common problems are that browsers have access keys already assigned, not all browsers assign the same action to access keys, and when browsers are set to different languages it is extremely difficult to avoid conflicts between the browser, the site or application, and any assistive technologies being used.
Use ToolTips, mnemonics, and a list of shortcuts in the help and documentation literature.
Complex key combinations are best avoided, if possible (e.g., CTRL + Shift + <key>). Basically, complex key combinations are difficult to remember and usual require two hands to operate (which in and of itself is an accessibility problem). However, given the potential conflicts with browsers, sites or applications, and assistive technologies, it may not be so easy to avoid.
Due to differences in handling event object models among browsers, JavaScript may have to be used to resolve these differences.
Skip to content—how to implement this, variations that are appropriate based on the recommended navigation styles. For example, maybe we don’t need “Skip to content” in simple form for the public, but we do in complex form for the public. We need multiple “Skip to contents” when there are even more complex navigation schemes.
Consider that “skip” links are used by more than just blind users utilizing screen readers. “Skip” links are also an important component of the page for mobility impaired users and also for users with low vision who use a screen magnifier utility. Therefore, it is not advisable to mask the link or hide it in the background as some designers and developers advocate or have done.
There may be an alternative to the “skip” link. When using style sheets code the HTML so that the navigation links are at the end of the text stream, and then position the navigation wherever it is desired on the page visually by using the style sheet to define this. However, there may still be some HTML header information that gets read before the actual content.
Time out (used in Complex form for the public) – go to next page, navigate to a reasonable starting point if timed out
Because users get distracted by phone calls or other tasks, give the user a message describing why there is a session time out and that it will occur unless the user presses a “Continue” button within a specified amount of time.
When a timeout does occur, save any completed information and allow the user the option to pick up where the session expired on them. Any lost data is not going to be seen as favorable even if users understand the reason for the time out.
A common guideline for session inactivity is to let it go for 60 minutes until a time out is to occur (keeping in mind that a warning message as described above will appear prior to the time out). Sixty minutes will allow for unexpected interruptions in the task and for user breaks (e.g., coffee, smoking, and even meal breaks).
Indicating required fields—when is it appropriate, how to do it, making it accessible, differences in approach for casual and frequent users, what fields should really be required, putting all the required fields together on the form
Although there are many possibilities for indicating the required field, and chances are most users have experienced many of them, placing an asterisk in front of the field label is the most recommended method of showing that a field is required (for all practical purposes this has become the de facto convention). The asterisk should be explained at the top of the page or section in which it is used (and probably at the bottom of the page, too, for pages that scroll). This way users with screen readers will understand or learn what “*” means when it is read as “star” by a screen reader (i.e., an asterisk is read by screen readers as “star” and may not communicate the associated meaning to those using them without some explanation). Another option to reinforce the meaning of the asterisk for limited or non-sighted users is to use an HTML asterisk with a transparent image next to it and its ALT tag defined as “required field”. That way a screen reader would call out the field as required rather than as a “star”.
No direct recommendations have been found on the appropriateness of the required field indicator. I interpret the statement of the issue to mean the conditions of when everything on the page is required versus when only one or some of the many fields are required.
Dynamic questions—e.g. displaying the second question after the user answers the first question, so that the question and/or the possible answers can be customized as an appropriate follow-up to their first answer, and to avoid overwhelming people with too much at once
First of all, is there a usability problem with the length of the current online form? If there is no empirical evidence to suggest a problem with the usability of the length of the non-dynamic form, then do not create a dynamically driven form just for the sake of doing so or to solve a problem that doesn’t exist in the first place. Certainly there’s no arguing that a short form is more desirable than a long form. However, is there really anything inherently wrong with the usability of the existing longer form?
The dynamic display of questions based on the answer to the previous question can help to reduce overwhelming the user or for screen clutter in a long form. However, the following are some of the undesirable consequences to this approach as noted by some HCI professionals:
If the long form is shown to be problematic, then a suggestion is to break up the questions into a set of steps that are divided up over several pages. Be sure to include which step the user is currently on and where they are in the overall process.
How do you orient people to their current location, i.e. highlight current locations, tab, breadcrumbs?
Breadcrumbs are most often located near the top of the page just below the page title and left-justified. They are denoted by the “greater-than” sign (>) between each link. Other characters used between each link, although to a much lesser extent, are right-facing arrows (?), pipes (|), and colons (:), and rarely used characters are “less-than” signs (<) and left-facing arrows (?), both of which tend to be aligned from the right side of the page. There are even a few sites that do not only use space and a visual distinction among the links in the breadcrumb trail.
The term breadcrumb means more than just the pathway the user has taken to get to where they are in the site. There are generally three types of breadcrumbs in use (as outlined by Keith Instone of Usable Web): Location Breadcrumbs, Path Breadcrumbs, and Attribute Breadcrumbs.
Location breadcrumbs show the current page in relation to the site’s hierarchical structure. It can also be thought of as the ancestor path showing the current page’s parent, grandparent, and so forth. This type of breadcrumb is most used, and useful, for static pages.
Path breadcrumbs show the actual path that the user took to get to the current page in the site (i.e., the chronology of pages visited to get to the current page). This type of breadcrumb is the one from which the metaphor is derived - as in the Hansel and Gretel fairy tale. They are most often used for dynamic pages on database-driven sites.
Attribute breadcrumbs show meta-information about a product with a large set of attributes in a breadcrumb-like way. This type of breadcrumb is common in e-commerce sites.
Among the literature and sparse research there is very little empirical data on the effectiveness of breadcrumbs for increasing a site’s usability. Some studies indicate that few users utilize breadcrumbs, although with some training, instruction or exposure to them there tends to be some improvement to their effectiveness. Furthermore, when breadcrumbs are used, be sure that the type of breadcrumb used on the page matches the type of content and structure of the site. Doing so may lead to improved meaningfulness and usefulness during the task that they are undertaking.
Alternatively, a tool called TreeDec from the National Institute of Standards and Technology provides useful information on the user’s current location, the hierarchy of content, and other related content. The tool creates a navigational table on each page that includes the following three sets of links on each page: 1.) An ancestor path, which shows the context of the current page; 2.) Siblings, which show related pages; and 3.) Immediate children, which show details of the current page. The downside to this is the amount of page space taken up by all the sets of links.
Finally, user orientation goes beyond showing the literal and logical navigation paths by holistically focusing on all of the page elements that identify the context of where the user is on the site or within a task, where they may need to go, and where they have been. Consider the following elements as orientation aids, too:
Command Buttons on a page – where to put command buttons – keeping them separate from navigation-- Don’t put Cancel (or Clear) on a data entry page on the internet – enabling buttons only when it is appropriate for them to be selected – when to make something the default button (avoiding the potential for mistake by making something the default button too soon)
Definition (Microsoft):
A command button, also referred to as a push button, is a control that causes the application to perform some action when the user clicks it.
Design of command buttons:
Location on page:
Research on the alignment and order of command buttons within web pages is divided and inconclusive. The sides are drawn almost equally between left and right alignment, and between which side the Submit button should be in relation to the Cancel button.
Deciphering the arguments on the issues, I’ve drawn the following conclusions.
When the choice of action is primarily limited to submit or cancel, it is advisable to place the Submit button to the right of the Cancel button. This follows the Microsoft UI guidelines for dialog boxes (although it is contrary to other guidelines, e.g., Apple). On the other hand, when there is a multi-step task as in a multiple page task or wizard, then use Cancel | Previous | Next, where Next is replaced by a Finish button for the last step of the task. This fits the model of progressing forward or backward in the task which matches the movement of left to right in Western cultures.
Concerning the placement on the page of the two primary actions, the research is also inconclusive. Consistency of placement may be the best guideline to follow in this case rather insisting that the placement be left-justified, right-justified, or centered on the page.
Usage of Cancel or Clear buttons on data entry pages:
It may be helpful and acceptable to put a reset-type button (e.g., Clear) on a form page when the user needs to do repeated form-filling and submissions. The benefits of the reset-type function must clearly outweigh the potential for frustration caused by an accidental deletion of completed information. Keep in mind that retaining form field data from one completed entry to the next may also increase the potential for erroneous data submitted when it should not have been.
When to enable or not to enable buttons:
Insufficient data to draw any conclusions
Default button:
Insufficient data to draw any conclusions
Progress indicators when the system is processing a submission
A progress indicator is a control that shows the percentage of completion of a lengthy operation or system processing time. The control is usually a rectangular bar that fills from left to right as the operation completes. The bar may be solid as it fills or in discrete segments.
The user scenario for SSA is usually when the user inputs data and then submits it to the system by pressing a “submit” command button (the actual name of the “submit” button is determined by the action that is being performed). The system may take a few moments to process the information and send back a confirmation and to allow the user to proceed with the task or another task.
In this scenario, once the user submits the information by pressing a command button, a new page should be loaded with a message stating that the submission is processing and that it may take a few moments (exact message may need to be tailored to the specific condition). In addition to this type of message, a progress indicator control is recommended to communicate the status of the processing. Once the processing is complete the page should refresh with a confirmation page (stating that the information has been received/stored/accepted/etc.) and then a way to proceed with the next page in the task or to another task.
The presentation of this intermediary page with text and a progress indicator control helps to communicate the status of the system and also traps the submit action so that there is no multiple submissions. For the situation where the user may press the “Back” button during this processing time, see the issue entitled “Disabling Browser Controls on Web Applications” for guidance on what to do. When the system processing time cannot be computed and therefore the accuracy of a progress indicator is not valid, use an animated GIF on the page that sufficiently gives the impression that processing is taking place (e.g., an image of a progress bar that constantly moves).
Search (usability issues with search, the pros and cons of advanced search, best practices for layout of a search page, etc.)
First and foremost search is best represented simply as a text edit field and command button, rather than as a link to a search page. It is highly recommended that a basic search interface be found on all pages of a site. Use a simple search interface in a consistent location (e.g., in the page header) on each and very page of the site. The rule repeated over and over by experts is to keep search as simple as possible. Suggestions for a basic search interface include:
[ ] Search
Keyword(s): [ ] Search
Search for: [ ] Go
(Where “Search” and “Go” are buttons (not links), and the text field is large enough to fit common length keyword strings.)
Some experts have commented about users thinking that they may be searching the entire Web when they use the search feature. If this is a concern for the targeted users, then it may be advisable to include a little more description in the basic search interface. For example:
Search SSA.gov for: [ ] Go
In most cases, it is recommended only to offer advanced search parameters on a search results page. If users of the site often go to or need advanced search parameters then use an advanced search link under the ubiquitous basic search field that is much less prominent than the basic search components. The vast majority of users only utilize the basic search function.
A site’s search engine should be optimized to handle minimal keywords across all stored data in the site. In other words, make sense of terse keyword entries since that is typically what users search upon. Most users do not enter elaborate keywords and phrases.
In general, it is advisable to limit keywords to one field and have various controls for different search parameters that narrow the search rather than multiple keyword search fields and associated search buttons (i.e., one keyword field with a variety of settings for scoping the data searched). It is not advisable to provide multiple search keyword fields each with its own search button. If for some reason this cannot be avoided however, clearly distinguish each field as a separate search interface so that users do not confuse the fields as all being tied together into one complex search interface. Some experts reported users being confused at receiving error messages after filling in one search field while then clicking on a search button to an unrelated search field (resulting in an error message or no results found).
Where options are required in an advanced search to narrow search results into categories (or some other type of scoping), default the option to an “all” category or “search entire site” rather than to one of the specific categories. This may help to reduce errors where the user may have overlooked the option and searched an irrelevant category, and thereby leading to a search failure. Likewise, clearly label the results of the scoped search at the top of the search results page and provide a simple control where the user can conduct the same search (keywords retained in the field) that is not scoped (i.e., the entire site).
Most users do not understand or use Boolean search parameters. Provide Boolean options only on an advanced search page. If Boolean options are mentioned, do so with examples.
Search results (how to display search results, grouping search results, standards for navigating a list of search results, etc.)
Offer a short “search tips” page whenever the user runs into a “No matching results found” situation. Combine this with a model example of a keyword search for increased effectiveness.
At the top of the search results page make sure that the keyword search field is still present and contains the original keywords that the user submitted. This helps users to refine the search if they did not find what they needed in the results. As mentioned in the “search” section above, provide a control for the user to toggle a scoped search back to an unscoped search.
Some sites allow a function to search within the contents of the results page in order to pare down voluminous results. Although this seems like a beneficial way to tweak the results, many experts reported that the function is rarely ever used in usability studies and only a very small fraction of the time according to search logs. If the function is provided at all, require the user to choose the function specifically rather than to default it on. There were many reports of sites that default the function on and therefore cause users to get erroneous results when they thought they were doing a new search from the search results page. In other words, users did not understand that they were only minimizing the same search results rather than doing a fresh new search.
Relevancy ratings have been shown to help some users to make decisions as to which results to pursue and which not to. Many experts [and apparently users] feel that relevancy ratings are of little to no use to users. Someone mentioned that users even joked about the relevancy of the relevancy ratings during usability tests. Another problem with relevancy is that some users may interpret relevancy as pertaining to what they are really trying to find as opposed to relevant only to the query that they just submitted (and the accompanying algorithmic match of keywords to documents in the database). The resulting gap may lead to unsuccessful user searches even though the results are valid database returns. The general recommendation here is to clearly define what relevancy means in terms of how the user may use the information, and that the results are ranked in terms of an algorithmic match as to how often the document contains the keywords submitted.
As for what the relevancy rating looks like, one noteworthy suggestion was to replace the relevancy rating with something graphical, especially since relevancy results are only relative to each other. The suggestion was also due to the lack of real meaningfulness of a precise relevancy number or percentage point. The suggestion was to give a quick indicator of good, medium or poor match. Perhaps a good convention would be to combine the relevancy rating with a more qualitative graphical bar. The user can decide which is meaningful and helpful.
As a compliment to search relevancy ratings in the results include various ways in which to sort the search results (e.g., high to low, low to high, alphabetical A – Z, alphabetical Z – A, best match [to the search], link popularity, etc.).
In addition to search result display strategies and navigation design, a couple of experts suggest conducting an analysis on search engine logs. Basically, this involves analyzing the search engine logs for common queries and determining the best landing pages, then refining the search engine to present those pages first. Rolf Molich of DialogDesign in Denmark describes his search analysis below.
What is a "search analysis?" It's an almost insultingly simple method that I have applied with some success for a number of clients. It basically involves collecting the entries that users make in your free form search box over a period, for example two months. You will get a lot of entries, for example 500,000. Count identical entries. Analyze the top 200 entries, which usually cover about 50% of the searches, in more detail:
- Enter each one in your search interface
- Evaluate the output on a five point scale (4-perfect search result - first result leads directly to highly relevant information; 0-unusable search result)
- Tune your search engine.
Even though they got ten attempts, none of the clients that I have used this method for were able to guess what was #1, #2, #3 on their list. In typical client evaluation of a site that was otherwise quite usable the top ten got the grades 2-0-4-4-2-0-1-2-0-0. Users are amazing!
Once the analysis had been done it was quite easy to see what should be adjusted to get a 4-4-4-4-4-4-4-4-4-4 result. Interestingly, all of the tuning advice was contained in one of the reports referenced above that I use as the basis for my work.
Combo boxes (We started working on this during the first release, then dropped it because the group decided it was too non-standard. Is anyone else doing it on the internet? The combo box is like the drop-down list, but you can also type something into it that was not in the list.)
The “drop-down combo box” is the Microsoft term for the described control. It would probably be best to further define the requirement for a control that adds an item to a list that did not otherwise already contain the item. Are the values entered into the field portion of the drop-down combo merely used as an answer to a question, as one might find in an online form, or is it going to alter the data table that stores the values of the list and therefore subsequently change what gets displayed the next time?
It seems that there is sufficient technology capable of creating the drop-down combo box in a web page. It can apparently be done with elaborate JavaScript.
Providing this type of control may not be the best type of interaction available for a web page with a wide range of user types. A drop-down combo box control is complex and very confusing especially to novice users (even within a robust Microsoft Windows application, let alone a web page). Drop-down combo boxes seem to be rarely implemented on web pages.
Consider splitting apart the two functions of the drop-down combo box into a drop-down box and a text edit field. The two fields could be tied together in function. For example, include an “other” value in the drop-down list that when selected evokes a text edit field so that the user can enter an unlisted item. Define the requirement for whether or not this gets added to the list or is just a separately stored value in a data table or form. This works well for filling out forms in which the user picks from the list or provides a value that defines what the selection “other” means to them.
Another alternative to the drop-down combo box is to use a text edit field to enter a value into the field, and combine this with the necessary controls to add the entry into the editable list, select any item from the list, and to modify or delete a selected item(s) in the list. This supports more complex requirements where the user needs to go beyond just selection and/or inclusion to making additions, deletions or modifications to items.
Another option to the drop-down combo box control is have the user make a choice what they wish to do; to select from a predefined list of items, OR to enter a value. In other words, radio buttons could be used to distinguish the function that the user wishes to do, (a.) to select an item in a drop-down list box (even a combo box could be used for character-matching to items in the list), or (b) to type a value into a text edit field and press a button that adds it. This approach may work for completing simple question and answer type forms, but gets complex when the entries need to be edited (subsequent deletion or modification).
Consider also that allowing users to add to a database whatever items they type into a field may present some serious (or even humorous) data errors, data integrity, and data validation problems. However, I am aware that DB administrators may be the intended user group for this type of functionality.
Calendar controls (When you have a date field and you click on a button to display a calendar, which allows you to choose a date. What are the pros and cons of using them vs. selecting dates from drop-downs? When would you use one vs. the other? What design standards are there for the pop-up calendar itself?)
Questions to answer regarding requirements of a calendar control (AKA – “date picker” in Microsoft terminology):
Date control options:
Single text edit field for date. Text edit field alone may be the fastest way to input a date, but it is often too ambiguous for many specific entries like 5/1 or 1/5 unless the user defines a month/day or day/month preference. Allowing the user to define the format may increase the user control of the interface, but it may also complicate it and increase the number of steps to complete the task. Even showing a format or an example next to the field does not sufficiently guide all users or eliminate data entry errors. A slight variation of the single text edit field is to allow any logical date format and have the application prompt the user for clarification if the app cannot validate it or there is more than one possible way of interpreting the entry. This, however, may come at a higher cost for sophisticated programming and slower responses for the server to do the validation and return a response (and thereby leading to user frustration).
Separate text edit fields for each date component. Create an individual text edit field for each of the data elements for month, day and year. The month field may permit numeric entries, text entries or both. This is possibly a slower method of inputting data for the user than a single field, but it does have the benefit of guiding the user a bit more and by breaking down the elements into more valid entries.
Separate drop-down list boxes for each date component. A separate drop-down list box can be used for the month, the day and the year. User error is likely decreased while data integrity is increased. Likewise, programming the controls is very easy. However, the number of steps required to access each control and to make each selection is fairly numerous and tedious because of the potentially large set of values within each control (e.g., 31 days in a month, 12 months in a year, and many years depending upon the nature of the entry). On a day control, for example, the user must click the control to drop-down a list, possibly scroll down to the end of the list, and then select the desired value. However, drop-down list controls are definitely ubiquitous for date entries on the Web, so much so that you might say that it’s practically a de facto standard. Chances are high that nearly all users of a site will have already encountered this type of date entry interaction.
Calendar control issues and considerations:
- Calendar controls are most often used as an alternative, supplementary, or secondary method of user interaction for date entry or date selection. The calendar control has the advantage of supplying the user with additional contextual information when the exact date is not immediately known or remembered, but may assist in picking out the appropriate date.
- What should the format of the control be? There are different international conventions for the day that starts off the week, Sunday or Monday (USA = Sunday while Europe = Monday). Many calendars around the world are also oriented vertically by day rather than horizontally by day.
- Advanced technology like Java, JavaScript, or DHTML may be required to display a pop-up calendar control. An alternative may be a server-side generated image map type of a calendar control that is displayed on the web page.
- With a pop-up control there may be a decrease in user accessibility with the control and its functions. What are the accessibility ramifications of selecting a control that evokes another control over top of the existing web page?
Other issues and considerations:
- The application must validate entries even when drop-down lists are used (i.e., the user may select the month of “February” and the day of “30” or “September” and “31”). It may be possible to set the values of the day field after the selection of the month. However, in this case the user must always select the values for each field in a defined order (i.e., month first and then day) rather than in any order desired.
- Client-side JavaScript can prevent users from typing invalid characters into a field, and server-side JavaScript can clean up valid but improperly formatted entries (e.g., the entry “83” becomes “1983” upon submission for a field asking for the year of high school graduation, or some such type of data).