I'm using the Win 8.1 SettingsFlyout in my app. Design has asked for several Entry Points (nomenclature from Guidelines for app settings) with fairly long titles. These settings names work fine in the Settings Charm flyout (the one that lists all the entry points), but when the user drills into a specific flyout the title (as displayed in the header) gets truncated. This is especially painful in foreign languages, where any attempt to control the translation becomes a bureaucratic pain. The ~20 characters available is insufficient for what Design wants here.
Is there a way to change the style of the Header (or at least the Title) in my SettingsFlyouts so that the Title can be displayed on multiple lines?
Related
I am converting HTML to PDFs with some page numbering requirements that are standard in book printing.
Page numbers should be hidden on some pages
Front matter, which means everything up to the actual text, should have Roman page numbers (i, ii)
Page numbers should restart from 1 at the beginning of actual text
Table of Contents should show page numbers
Hiding page numbers is very important. The three others are big nice-to-haves.
I am using html-pdf-node, which uses Puppeteer -> Chromium -> PDFium.
Since html-pdf-node only supports very simple page numbering, I am looking at possibilities of doing it in one of the deeper levels.
I tried to search the documentation of the four levels and I checked possibilities of removing or editing page numbers with other tools. With Chromium/PDFium the answer might still be in the docs even I did not see it. I also thought of forking our own version of PDFium if possible.
I'm trying to improve screen reader support on our webapp, but I'm struggling a bit with what the best practice is for our buttons. Our current pattern looks something like this
If I focus on the button, should the screen reader say...
...Choose file, required?
...Upload personal letter: choose file?
...Upload personal letter: choose file. Allowed filetypes: doc, docx. Required?
We're currently going for the more talky version, but our team has limited experience with screen reader users and how they're used, so a push in the right direction would be very helpful. Thank you. :)
There is no real rule. It should be fine as long as indications are clear enough for the user.
In fact, it depends a lot on how you are used to your screen reader, Internet and your device in general:
Advanced users tend to prefer shorter labels and may be annoyed by longer ones.
Beginners may not understand if the label is too concise
Beginners may also be overflowed if the label gives too much extra information, or don't understand if the vocabulary is too technical
Screen readers have many options allowing you to decide what to say and what not to say. For example, Jaws calls that verbosity and there are 3 general levels that are further customizable.
Sadly, on the web, you can't determine the selected level, nor adapt the markup knowing that this element is only spoken in advanced or intermediate mode (this can be further highly customized anyway)
So the best is probably the middle option: be not too concise, but not too verbose either.
I'm a screen reader user myself; as an advanced user, regarding your propositions; I would say:
The second gives more confidence on what you expect exactly than the first one. If there are several files to upload, for example a cover letter + a CV + a photo, it's very important to have the information, so that there is less risk to mess up, i.e. upload the photo in the CV field.
If there are several fields with the same label that are labelled the same, it's hard to know which is which.
Indicating the allowed file types and other requirements of that kind is very good, but it is probably better placed outside the label.
Remember that the entire label is spoken again each time you tab into the field. If there are 5 fields with the same information, or if the form is complicated and you must go back and forth several times, it's annoying to hear many times the same.
So, I would go for a variation on the second one: "upload personal letter, required".
And indicate somewhere else in the page technical constraints like file type, size, etc. because it's still a very good idea.
Note that the "required" information can be left out from the label if you put the required and aria-required attributes on the field. It's the recommanded way to indicate that a field is required.
Tl;DR: Keep it concise.
If you want to convey some additional info like allowed file types, sizes, "no viruses please" etc., do not put this on the button itself. Prefer, for example, aria-describedby and make a separate control describing all those things, visually connected to the button (say, to the right of it).
We, I mean screen reader users, often navigate by items and do other weird stuff like invoking list of all buttons on the page (even Narrator nowadays started supporting such things), so if the button label is too long, it would be irritating too shortly.
I'm trying check my website by http://achecker.ca
and in potential problems section, I have very much problems...
Exactly I mean this problem:
Success Criteria 2.4.4 Link Purpose (In Context) (A)
Check 19: Link text may not be meaningful.
Every link on my main page is listed here as a problem...
What wrong could be in links like that:
PARTY
News title
<img src="images/ico/ico10.gif" alt="games">
The testing tool http://achecker.ca/ shows this potential problem for all links, even for this one (which is as meaningful as it can get):
<a href="http://stackoverflow.com/questions/38933605/achecker-link-text-may-not-be-meaningful" rel="external">
Stack Overflow question: <cite>Achecker Link text may not be meaningful</cite>
</a>
It’s documented at http://achecker.ca/checker/suggestion.php?id=19, where it says under "Short Description":
All a (anchor) elements that contains [sic] any text will generate this error.
This page also gives hints how to determine/check if your links pass or fail.
The relevant WCAG 2.0 guideline is 2.4.4 Link Purpose (In Context).
The potential problems listed by AChecker are typically not problems at all, but a human has to make that confirmation.
Regarding the meaningfulness of your links, think about someone giving you the text of a link on its own and asking you to define its meaning. Is the word "Party" meaningful. This word can be interpreted in multiple ways.
When navigating with a screen reader (if one is blind) listening to links in the sequence they appear on the page, nearby links can add meaning to single words like this. Will the links prior give the word Party the meaning of a "festive occasion" or perhaps a "political party", or even an "interested party," etc.. "News titles" is probably meaningful enough. "Games," the alt text for the image, could also be interpreted in multiple ways. Is there context (surrounding links) that give more specific meaning to the word "games?" Olympic games, video games, playing games, etc. If the context does not add meaning, then the link text itself needs to be adjusted to specify which meaning of the word is being used.
All links will be listed as "potential" problems by AChecker, requiring a human to make a decision on whether the text effectively describes the link's destination or function.
Potential problems are those the checker cannot identify with any certianty. Anywhere there is meaning involved, AChecker will identify potential problems. Known, Likely, and Potential problems are described on the first page of the Handbook, linked from the top right corner of AChecker.
http://achecker.ca/documentation/index.php?p=checker/index.php
Quote from the handbook:
AChecker identifies 3 types of problems:
Known problems: These are problems that have been identified with certainty as accessibility barriers. You must modify your page to fix these problems;
Likely problems:These are problems that have been identified as probable barriers, but require a human to make a decision. You will likely need to modify your page to fix these problems;
Potential problems: These are problems that AChecker cannot identify, that require a human decision. You may have to modify your page for these problems, but in many cases you will just need to confirm that the problem described is not present.
The key here is that they might not be meaningful.
I think they are being flagged because they only have 1-2 words in and so the tool is asking you to verify that the link text is good.
The kind of thing that should actually be considered as a failure of this rule are links that simply read "click here" or "more info", because they aren't actually explaining where the link goes. Other things to watch out for are multiple links with the same text but different destinations, and links with no text at all.
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've got a bit of a usability issue that I'd value some input on.
The initial page to my site contains two groups of controls, one for users to login, the other for new users to activate.
The issue is with the latter. When users signup for the service, they recieve an activation code that's in the form XXXX-XXXX-XXXX-XXXX. At the moment they have to enter this into four separate textfields. Whilst I've added some javascript to this to automatically move them back and forwards between textfields as if it were a single control (which works pretty well) the issue is that it lacks a way for the user to paste their data into it and as such is a bit of a pain.
Now this is not a huge issue, but it potentially means that peoples very first experience with my site is a slightly frustrating one, having to hop backwards and forwards between the email containing their activation code and my page. That's obviously not optimal.
At this point you're probably thinking that the glaringly obvious answer would be to make the activation code entry into one single textfield. And you would be right, but I lose one very important thing if I do this: I lose the key visual differentiator between one form and the other, which automatically tells the user which is the form they need to use without reading anything or having to analyse anthing. As it is at the moment, effectively there are two different shaped holes on the page and the users data will obviously only fit one of them so, to an extent, it's a no-brainer which form is relevant to them.
So, does anyone have any good solutions to this? The single restriction is that I need to keep all controls on one single page.
Thanks in advance for any help.
Edit:
Thanks for all the input so far, every bit of which has been valuable. I'm currently thinking that the best solution is not one single thing, but actually an amalgamation of different approaches to make the whole thing more usable.
On that basis, here's what I'm going to do, based on all your suggestions:
In the purchase email, setup the link
to the initial page such that it
contains the activation code in the
querystring. Setup the initial page
to check this and forward them
straight on. This probably means that
the vast majority of users won't even
see the initial page, but there will
still be cases whereby people receive
their codes by other means and will
have to input them directly
Convert the four textfields to a
single textfield with
"XXXX-XXXX-XXXX-XXXX" as an inline
label.
Setup the login controls to forward
on any user that mistakenly enters
their activation code here without just dumping them to an error screen.
And I don't know why I didn't include it in the first place, but here's the URL for anyone that wants to take a look at the current implementation (you'll have to excuse the fact that it's in Italian, but it should be fairly straightforward what's what).
Have given the answer to bryan which contains most of what I'm going to use. If I had the necessary reputation I'd vote up all your answers as they've all helped. Thanks again.
A few easy options:
You can keep them the same physical page, just alter the querystring when you send the activation code. Hide one set of controls if the querystring is available. If you have to display both sections, then grey out one section based on the querystring information.
Change the control to have one textfield, but include "XXXX-XXXX-XXXX-XXXX" as the default text in the New User Activation. If the user clicks on the textbox, remove the text so they don't include the prompting text with their activation code. People will see the default text and gravitate towards it if they're expecting that pattern. People logging in will see the default text and block it out.
You could write an onpaste function in JavaScript which chops up the pasted string in to 4character blocks and them writes them to the appropriate textbox's via the dom.
Sounds to me you’ve a problem of users confusing two text boxes but then you’re making it worse by dividing one text box into four. For example, auto-tabbing through fields is bad usability -see comments and answers to “Moving a focus when the input text field reaches a max length.”
Assuming this isn’t a hypothetical problem and you’ve actually observed people use the wrong field, you need to find another solution for users confusing the fields:
Use terse field labels. Label the field “Activation Code” not “Enter your sixteen character dash-delimited activation code from the email we sent you when you signed up.” Text necessary for explaining where to get the activation code should be after the text box.
Use cueing text or graphic design on the outside of the text box to indicate it has four substrings. For example, put “XXXX-XXXX-XXXX-XXXX” under the text box.
Remove all extraneous elements from the page –the more graphic and text distractions on the page, the less the differences between the two text boxes will be noticed.
Make it so it doesn’t matter which text box the users use. If the string entered in the Username text box doesn’t match any username, then see if it matches any activation code, and vice versa.
Eliminate the activation code text box. Instead, when you send the activation request, include a sign-up URL that includes the activation code as a parameter (more details in answer by bryanjonker).
Sorry, this should probably be a comment, not an answer, but it wouldn’t fit.