It's possible add extra states to defaults states of a widget ?.
For example, working with styles in tk (ttk) some times the options to configurate a widget are very limited. However, using the command ttk::style map and (if possible) defining extra states, would be easy to configurate it.
The low level state management engine maps the states to bits of an integer. The full list of supported states is (this is information extracted straight from the C code; this is utterly the ground truth):
active — Mouse cursor is over widget or element
disabled — Widget is disabled
focus — Widget has keyboard focus
pressed — Pressed or “armed”
selected — “on”, “true”, “current”, etc.
background — Top-level window lost focus (Mac, Win “inactive”)
alternate — Widget-specific alternate display style
invalid — Bad value
readonly — Editing/modification disabled
hover — Mouse cursor is over widget
reserved1 — Reserved for future extension
reserved2 — Reserved for future extension
reserved3 — Reserved for future extension
user3 — User-definable state
user2 — User-definable state
user1 — User-definable state
Looking through that list, I'd guess that particularly user1, user2 and user3 are open to use for your extra states. Defining more than that requires custom changes to the C code, but you have three right there to be going on with.
I guess at a pinch, reserved1…reserved3 could also be used. I shudder to think of how complex a UI must be to need that many different independent state descriptors, but they're there and I really doubt that Ttk will make much use of them any time soon. (If you're making a lot of use of this sort of thing, do drop a line to the developers of Tk to let them know about it; it helps persuade people to not “optimise” away this stuff and particularly good uses might lead to a state bit becoming officially named.)
Please don't reinvent the meaning of any existing state flag though. Everything is confusing enough without that!
Related
I am using change language drop-down in my web-application, I am working on accessibility of web-application, while working on accessibility I discovered that when particular option is selected from dropdown voiceover just pronounces the selected option,but inorder to make it more accessible I wanted to pronounce it as value selected. Is it possible to prefix text 'selected' in voiceover / screen reader pronunciation?
Please find the code below
<label for="lang">Choose Language:</label>
<select name="lang" id="lang">
<option>English</option>
<option>日本人</option>
<option>русский</option>
<option>中文</option>
</select>
Thanks
This is once more the famous question "How do I make the screen reader to speak X instead of Y ?"
The general answer is, if you want Y be spoken instead of X, then just write Y and not X. If it isn't appropriate to write Y, why should it be to speak Y?
Why a scren reader should speak something different than what's written?
I won't make the whole discussion here again, but except in relatively rare cases, things shoult be spoken as they are written. If it isn't the case, you may create problems for several ranges of people: partially sighted people who rely in both speech and written text won't hear and see the same; it's unclear if braillists should read X or Y depending on how far you consider braille as being as writing system per ce; etc.
As the name says, a screen reader is there to read what is written on the screen.
For all the rest, important information not really written directly on screen, like the fact that an item is selected or not, all screen readers have adopted different strategies and often they are configurable.
For example, the word "selected" might be said before or after the selected element; a different voice might be used; the pitch might be made lower or higher; A sound might replace the word "selected" altogether; etc.
The best is to not interfere in any way with how exactly that kind of information is given to the user.
By interfering, you might clarify things for one specific group of users, but confuse all others.
In the case of selection in a combo box, just use the selected attribute appropriately, or maybe aria-selected for custom components, in order to mark the selection properly.
From there, leave screen readers report selection to the user as they are used to do it. Don't do anything special.
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.
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 always feel the disabled attribute for HTML <input> and all is twisting my brain. Why choose a negated attribute name, isn't enabled more intuitive?
Just compare:
enabled=advancedUser
disabled=not(advancedUser)
enabled=not(locked)
disabled=locked
enabled=advancedUser and not(locked)
disabled=not(advancedUser) or locked
disabled=not(advancedUser and not(locked))
The fundamental reason behind this is that it was a later addition to the HTML input fields, and needed to be that way to maintain backward compatibility with existing web pages.
When the <input> tag was originally defined, its functionality was extremely limited. It did not have disabled or readonly attributes, nor many of the other properties we take for granted today.
These were all added later, but by the time they were added, many web sites were already using <input> fields, so the ability to disable it had to work without affecting existing code that didn't use it. Therefore the default state had to be enabled.
It also had to be a boolean flag, which is why it is disabled rather than enabled=true. The latter would have been a key-value pair attribute. This wouldn't have been a good choice.
Consider the following:
enabled=false
enabled=0
enabled=FALSE
enabled=no
enabled=disabled
enabled=flase
etc...
The browser would have had to be able to cope with a huge number of possible values. Making it a boolean flag simplifies things enormously. It makes the spec easier to understand, both for the web site developer and the browser developer.
The other thing to bear in mind is that the time when this property was added to HTML was in the middle of the so-called 'browser wars'. Many features were being added to the competing web browsers, in a hurry and without the benefit of formal specs, and many features were added which we can indeed look back on and wish it were slightly different.
I don't believe this is one of those features: the disabled flag is perfectly logical really if you stop and think about it. But it's quite possible that it may have been better designed if the browser developers had been co-operating a bit more back then.
But whatever the case, the situation today is that this is what we have. The HTML spec may be evolving, but existing features such as this are not going to change now.
SRP(PDF version; HTML version) states that
There should never be more than one reason for a class to change
When you take a look at Outlook, Calendar Event window, it has "Save and Close" button.
So when the functionalities of either or both Save or Close changes, that button should change. It obviously violates SRP.
This functionality both saves time and convinient since that is what most of users expect to do when they save an appoint on a calendar.
But now, my question is, when else do you violate SRP other than when the feature need to be usuable in Outlook?
SRP does not apply to UIs. Keep in mind that even though the button is called "Save and Close" there can undoubtedly be two separate methods or types to handle the saving and closing functionality. The button simply ties those two separate pieces of functionality together.
If you feel the need to violate SRP then you need to re-evaluate your approach. Any SRP violation can be refactored into a new method or type that exposes the composite functionality by means of composition of the two pieces.