I am wondering if the autofocus form attribute violates accessibility standards. Is there a cited authoritative precedent for that?
If used judiciously, it does not violate accessibility standards.
The one scenario where I have seen it cause a confusing loss of focus problem that violated WCAG 3.2.2 http://www.w3.org/TR/WCAG20/#consistent-behavior is in Safari on OS X, where the autofocus input was part of a constantly updating Angular.js application. In this scenario, Safari will continue to grab the focus into the autofocus input, when the area was updated, causing focus loss.
You can read about how I addressed that here http://unobfuscated.blogspot.com/2015/01/angular-accessibility-issues-focus.html
Related
WCAG's definition of functionality
processes and outcomes achievable through user action
link to source
Following WCAG's definition for "functionality", it seems intuitive that just as functional elements should always be keyboard focusable, non-functional elements should not.
However, in accessibility matter, naïve intuition can be misleading. As I could not find any definitive guidelines or failure criteria for this on W3C site, I'm asking here:
Is it ever a good practice to make a non-functional element keyboard focusable?
If there are W3C or other official standards supporting your answer, please mention them.
Note 1: Please do not provide scrollable but otherwise non-interactive elements as an example - for our purpose, scrolling is an interaction.
Note 2: Somewhat related, but not a duplicate of the question "Should text ever be focusable for accessibility? I'm specifically thinking about key-value pairs", also somewhat similar to this question: "Accesibility vs. read only inputs", but that was asked in 2013, and its single answer isn't authoritative enough IMO (and I'm guessing is incorrect for today's accessibility conventions).
Is it ever a good practice to make a non-functional element keyboard focusable?
Yes, but in very rare circumstances.
Oh, you want a longer answer? 😋
Tab panels are a prime example (and the only concrete example I can think of) of when tabindex="0" is useful.
In this instance it serves no purpose other than to allow a user to easily navigate to the panel so they can read it's contents.
This is demonstrated and explained on the W3 Example of manual tab activation page.
The reason this is suggested is that it functions in a similar fashion to a "skip link".
All the tabs are operable with the arrow keys, but the whole tab list is one tab stop.
Then when a user has opened the tab they want to read they can press Tab in order to jump to the content instead of having to read out the rest of the tab options.
Some "fluffy" examples
The only other time I have seen this used and it felt correct is in a "live chat" application when you could Alt + Tab through the conversation items. This felt better than using headings, sections or other ways we may make something keyboard navigable (and arrow keys didn't feel intuitive).
One last one that comes to mind would be data tables, sometimes you may want a table to receive focus so that a user can navigate by arrow keys. So it receives focus to activate the component and let people know it is interactive via keyboard.
I am thinking of someone not using assistive tech but who uses the keyboard due to mobility impairments in this instance.
However that is just speculation I have never implemented that myself and if I did it would probably be because a highlighted row changes a graph etc. (which I am sure you would count as interactive!)
Any official guidance?
With regards to official guidance, I doubt you will find something concrete. Obviously WCAG 2.4.3 - Focus Order does come into play here as adding a tabindex="0" to everything is not a "logical focus order", but it will not give you a definitive answer as it has to allow for custom components etc.
I am afraid this one is a "best practices" rather than a rules scenario. You would probably still pass WCAG if every item on the page had a tabindex="0" as WCAG doesn't focus on user experience but rather on whether something can be used at all. However nobody who relies on assistive tech would want to use the page with a hundred tabindex="0"!
If you adopt the principle that the focus should always be visible, then situations can exist in which the only way to make that be true is to put a non-interactive element into focus. A skip-navigation link needs a destination after the navigation header, but it is possible that nothing in the main region is interactive. A modal dialog, when dismissed, needs to have a focal successor, but its dismissal may cause the triggering element to disappear and leave no other element, or at least no intuitively reasonable successor element, interactive.
Another scenario: A user action could cause informative messages (hints, clues, annotations, etc.) to be inserted at various points throught a view. They might all be in live regions, but that would not make them easy to locate. Making them focusable would allow the user to navigate through them sequentially, ensuring that none of them is missed and no laborious searching is required.
I've seen a few error dialogs implemented this way, where the only interactive element on the dialog was the OK button, and they decided to set tabindex="0" on the message text.
This meant they could put focus on the OK button when the dialog opened, for faster dismissal, yet allow screen reader users to tab to the message text. This was probably more common before we had role="dialog". Overall I would say that making a noninteractive element focusable should be situational and rare. Don't do anything that would confuse users. But if it results in something that's intuitive and easier to use, I would say go for it.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What's the point of valid CSS/HTML?
This is a over-asked question, but I'm going to ask anyway.
How important is site/code validation?
I'm not referring to code errors that would break a site layout, like forgetting to close a tag, or using an unsupported tag. Just general warnings and tag usage errors.
I used to make sure my sites were validated 100%. No questions asked. Lately, I have not taken that approach however, especially with the use of HTML5. I feel that it is more important to make the site function as needed, even if it means putting a <p> tag within a <span> tag. Also, some of the CSS validation rules are pointless I feel. They are more considered with saving every possible byte then code readability.
Does it really matter? Looking for thoughts/concerns/opinions/links to articles. Thanks!
I do it for Peace of Mind.
When code is valid, it's more likely to work with a compliant browser. In theory, just because I test it and it works in various browsers today, does not mean it will work in newer browsers tomorrow. Standards Compliance solves that issue because if it follows the "Standard" today, it will follow the "Standard" tomorrow... of course, assuming that new browsers continue to support the Doctype you've selected to standardize against.
Why Validate - W3C
From W3C itself, here's a "Why Validate?" page that is extremely helpful: http://validator.w3.org/docs/why.html
Some of the main points:
Validation as a debugging tool
Validation as a future-proof quality
check
Validation eases maintenance
Validation helps teach good practices
Validation is a sign of
professionalism
Edit
The biggest reason I think is that when you don't validate, you're catering to broken browsers instead of designing for the browsers that do it right. Chad recently quipped that "if you use a degraded browser you deserve a degraded experience", and I think he's absolutely right. Design perfectly valid markup for standards-compliant browsers, and if absolutely necessary use IE6-specific stylesheets and the like for broken browsers. This way, you don't break the standards-compliancy of the good browsers, but you can "cheat" for the broken browsers.
Edit 2
The best exception, I think, is when you're moving forward instead of backwards. When you move backward, use separate stylesheets that only load for broken browsers - that way the good browsers aren't affected. But when you're moving forward (e.g, using CSS animations with vendor-branded tags, etc) you know that someday those will become standards (well, most of the time).
HTML5 is the culmination of our loose and sloppy HTML periods then overly-anal and pedantic semantic XML compliant xhtml period.
Which led us to an overall "validation is really important, but let's be pragmatic about it."
As stated, valid html is easier to debug, so there's the big plus right there. But there's plenty of room for exceptions as well. As long as you aren't using laziness as an excuse to allow for invalid markup when needed, it's probably a pragmatic decision.
From a User Interface design point of view when is it better to disable a control or to completely hide it. I have attached an example. In both case if the "Enable ASP.NET" checkbox is clicked the "Select. Net Version selector is enabled.
I would argue that it's almost always best to just disable. Hiding controls means you're leaving a portion of your functionality/configurability a mystery to the end-user. Unless there's a compelling reason to keep users in the dark, I wouldn't.
Your example of a checkbox that enables/disables or hides/unhides a dropdown box is a good one. If users aren't aware that checking the box allows them to select further options, they may never check it and find out, because they don't realize the option they're looking for is there.
Many of us, as developers, come from the "try everything" mindset when it comes to using a piece of software. Normal users don't think that way, and that's not a bad thing, either. It just means we have to keep in mind that not everybody will do what it takes to discover a piece of UI that's been hidden. Leaving it visible but disabled lets them see that there's something there for the having should they decide they want/need to use it, rather than leaving them either wondering if the software does something or never even considering that it might.
This really depends on the context of the example. In this case there is some value associated with disabling the control as it provides a visual affordance that enabling the ASP .Net checkbox will have a determinable outcome.
If the outcome of the checkbox is actually a whole series of non related suboptions or the parent control was a dropdownlist which determines which child elements become available then it would be better to hide / show only those elements that are appropriate to the current selection.
One other point, if you are describing "hiding" the controls as control.visible = false in code rather than display:none then remember that the output will actually not be rendered into the browser at all. This may be a concern if you are catering for disabled users with browsers requiring stricter accessibility requirements etc.
To me that depends on user knowledge. If the user knows what should follow I tend to give them as much information as possible so I would show it disabled. If the user is clueless as to what follows I hide as much as possible. Sometimes I do different things on user role and sometimes it depends on the average user of the application and their expected understanding of the underlying issues.
hth,
\ ^ / i l l
I prefer to disabled the control, so the user can see that he may have something to fill out. But it can be usefull to hide it if you are restricted on space.
It really depends on the situation
What are cons if we do not care about validation of XHTML and CSS? Errors other than CSS 3 and vendor specific properties
In terms of development time(How valid XHTML and CSS code save time to find problems?),
Code debugging (How we can track then problem quickly?),
Cross browser compatibility (How it helps us to achieve cross browser compatibility?),
Website maintainability (How it would be helpful to maintain and update for someone else?),
Future changes in website (How it would be helpful to make any changes in design if client can ask in future?),
SEO ranking (How it can affect our site's search engine ranking?)
Accessibility (Does validity of code increase accessibility of site?)
I have to explain a client's Secretary,Code validation is not just Fashion, it is beneficial for his site. I'm not just advocating of this to make more money. it's not useful only for developer it mainly beneficial for his website.
There's the obvious point that if your markup is valid, the odds of it being rendered as you want it to be by a wide variety of browsers are improved.
But separate from that, sometimes you spend valuable development time tracking down bugs (usually ones that seem specific to a given browser) only to find that the reason for the bug is that your markup is invalid and different browsers are handling the invalid markup in different ways. Validating (whether it's XHTML or HTML) saves you time tracking down those sorts of problems. There was an example here just yesterday, in fact. The OP thought he was having a weird Firefox-specific jQuery problem. In fact, he just had invalid markup, and fixing the markup fixed his problem.
So I'm thinking that you tell the client that validation saves time, and therefore money.
Note that this is an argument for validating, not for proclaiming validity (via icons and such).
I found some very good answers here
http://validator.w3.org/docs/why.html
http://ianpouncey.com/weblog/2010/01/web-accessibility-myths/
Using markup improperly -- not
according to specification -- hinders
accessibility. Misusing markup for a
presentation effect (e.g., using a
table for layout or a header to change
the font size) makes it difficult for
users with specialized software to
understand the organization of the
page or to navigate through it.
Furthermore, using presentation markup
rather than structural markup to
convey structure (e.g., constructing
what looks like a table of data with
an HTML PRE element) makes it
difficult to render a page
intelligibly to other devices (refer
to the description of difference
between content, structure, and
presentation).
http://www.w3.org/TR/WAI-WEBCONTENT/#gl-structure-presentation
The ASP.NET dropdownlist control has an arrow that you can click to drop the list down, that color of the arrow is tied to the users windows color scheme. This is not convenient for me and I'll need a workaround. However, I'm wondering if anyone knows (or has a guess) the strategy behind making that dropdown arrow tie to the system color?
Behind the scenes, the Winforms controls use the Win32 controls that have been in existence since Windows 3.0 (or was 3.0 still 16 bit? I don't recall). There is a lot of legacy under the covers, and back in the days it seemed to make sense to do it that way.
I actually think it still make sense today to enforce some level of consistency between the user interfaces of all the applications of a platform.
Really, the style of your dropdownList depends on your navigator. Some navigators offer more support for this than others. The same ocurrs with checkboxes, for example.
Browsers are responsible for turning form input tags into user-interface controls. Internet Explorer and other browsers do this by using the operating system's user-interface controls. "A web page wants a <select>? We've got that control already!"
The problem you're probably experiencing, however, is that Internet Explorer has notoriously poor support for styling those controls - and especially the <select> control. Other modern browsers like FireFox and Chrome provide better support.
At this time, the only options for IE are (a) to abandon the <select> element in favor of some sort of javascript-based component or (b) to wait for IE8 and hope it has better style support. Since it is very, very difficult to find a javascript <select> implementation which provides robust keyboard support, many people choose to just live with ugly <select> boxes in IE for now - sacrificing style for usability and accessibility.
It has nothing to do with ASP.NET; you could view the same site on a Mac and it would look different. This is how windows displays that type of element. If you don't like it, then you will have to create your own. It's been done already.
Browsers, to a varying degree, pick up the users colour settings from the os, like any other application, so in the absense of any author specified settings, they are usually the default.
Be aware that once you start tweaking the styling for selects and other form elements, you need to be sure of giving a quite complete set of style rules, otherwise it can all go to hell in a handcart very quickly, just how quickly depends on the browser.