It's valid in XHTML 1.1 and WCAG 2.0 guidelines don't have any info about its usage?
I know it's not valid in XHTML 1.0 strict, but if many people are using other things like JavaScript, jQuery, rel attribute, PHP etc.
Does it make sense? It means people don't want to follow validation rules, they just want to skip the validation.
It's mainly to do with separating content from behaviour. The basic premise is that we should use HTML/XHTML to denote content, CSS for presentation and layout, and JavaScript for interactivity.
The target attribute doesn't fit in with this paradigm (it's a bit of HTML content that affects browser behaviour), which is why its use is frowned upon.
Why are you trying to force the link to open in a new window in the first place? If the user want to view it in a new window or tab, they should be the one to decide. It's harmful for usability; for example, it stops the back button from functioning correctly, and takes some control out of the users hands. Check out this article for more.
Designers open new browser windows on
the theory that it keeps users on
their site. But even disregarding the
user-hostile message implied in taking
over the user's machine, the strategy
is self-defeating since it disables
the Back button which is the normal
way users return to previous sites.
Users often don't notice that a new
window has opened, especially if they
are using a small monitor where the
windows are maximized to fill up the
screen. So a user who tries to return
to the origin will be confused by a
grayed out Back button.
link
Except for 4 special target names, the target attribute is used primarily for frames. Since XHTML 1.0 has no support for frames, it makes sense that it doesn't include an attribute designed to operate on them.
Its sad that this also means losing the "open in a new window" effect, but that's how it is
Related
Is it ok in regards to accessibility to scroll content into view? Is it disorienting for some users to have the page move by itself?
For instance, if a dropdown opens and only a few options are visible, is it better to let the user scroll the whole dropdown into view or to do this programmatically?
Scrolling into view seems like a nice UX improvement (we're avoiding an extra action from the user) but also possibly important accessibility-wise (the user might not realize there is important content below the fold, so we're making sure they see it).
On the other hand, moving the whole page seems like it could be jarring to some user, who may lose track of where they are on the page...
Good question. There may be some that benefit from it, but others will definitely find it disorientating.
Without knowing more about the actual case, I would default to not auto-scrolling, because auto-animation requires a number of other things to be in place.
There are some WCAG rules which only apply when there is automatic movement. (e.g. https://www.w3.org/WAI/WCAG21/Understanding/pause-stop-hide)
Also the fact there's a CSS media query to accommodate this kind of thing shows that this is a feature that some users will prefer to avoid.
If you're using a CSS transition to handle this, it should be quite easy to put it in a prefers-reduced-motion media query, and the browser preferences would offer a mechanism to switch off the feature, making it compliant with SC 2.2.2
Even if you're doing the scrolling entirely with javaScript, you can still access the media query.
As an alternative, or even as an additional hint (belt and braces), you might consider adding a visual affordance to the last visible item indicating "more...". I have seen this handled with an ellipsis, or downward-pointing triangle/caret, but those idioms aren't strongly established for this kind of thing.
Screen reader users may be at a small advantage here. If you've marked up your popup correctly, the AT will announce the number of items, visible or not. :)
Good luck!
I'm tasked with evaluating some legacy web pages (classic asp) for accessibility. You can assume the HTML is not perfectly formed and that it's loaded with inline javascript and that we make use of javascript libraries that vomit HTML to create dynamic features. It's a circus in there.
While I recognize that the obvious answer is to re-write the page(s), that's not an option in our given time tables. So I'm trying to find the best way to make the pages work with a screen reader. Here's what I think I know.
We can use JAWS scripting to instruct the browser how to read the page.
We can use ARIA attributes to give the pages better organization and structure.
Specifically, I'm trying to figure out:
Question 1) If a JAWS script is present, will it be used exclusively by the browser/screen reader and ignore any improvements I make in the underling HTML structure?
Question 2) Could some well-place ARIA attributes give the page enough structure so that the default screen reader properties will work in an acceptable manner (without a JAWS script).
Question 3) I suspect the tough answer is that I would need to do both, which I'm trying to avoid because we barely have the capacity to do just one. But we don't want to lose a customer, of course. :-(
Many thanks for any input.
Instead of explaining only to JAWS how to access your pages, use JavaScript to explain it to any Assistive Technology (AT) for the web. I expect the same effort, while it will profit way more users.
In a JAWS script you would need to describe ways to access DOM nodes that are not accessible. That would include
speaking out information that you have to find elsewhere on the page
adding keyboard navigation where it's missing
Both can be done in JavaScript, probably even easier (you'll need to address DOM elements).
What you will need to avoid is restructuring the DOM and changes to classes, since those are most likely used by the scripts that generate them.
But I'd expect that adding attributes and keyboard handlers will do no harm to the existing scripts. Beware of already existing handlers for focus or keyboard events, though.
I would recommend making a list of attributes and handlers you suspect to conflict with the existing scripts, and searching the scripts for these, like onkeypress or onfocus event handlers.
The absolute best way to make your application/site accessible is to use semantic HTML. It doesn't matter if that HTML is generated by asp or jsp or whatever.
If you have a table, use a <table>.
If you have a heading, use an <h2>.
If you have a list, use a <ul>.
Use <section>, <article>, <nav>, <aside>, <header>, <footer>, etc
That's how you create structure on your page that a screen reader user will appreciate.
If you can't use native HTML, then fall back to ARIA, but treat it like salt. A little bit greatly enhances the flavor but too much spoils the meal.
If you can't use a native <h2>, then make sure you use the appropriate role and attributes.
<div role="heading" aria-level="2">this is my custom h2</div>
If you can't use a native <header>, then make sure you use the appropriate role and attributes.
<div role="banner">my header stuff goes in here</div>
I would recommend totally forgetting about JAWS scripts. It doesn't matter if that's what the customer thinks they should focus us. It's not about that customer. It's about that customer's customers. The end users. They should be able to use whatever screen reader they are used to using and most comfortable with. That's the whole purpose of accessibility - making the site usable and accessible by as many people as possible using whatever assistive technology they are used to using.
Following the Web Content Accessibility Guidelines (WCAG) will lead you to that result.
I'm reviewing and recommending changes/fixes to a small web application which was recently enhanced to be more accessible.
The problem I keep running into is that there doesn't seem to be anything which details how screen readers should (or even do) work.
For instance, if you look at the Accessible Rich Internet Applications (WAI-ARIA) 1.0 specification for a TabPanel and the Authoring Practices guide state a basic definition and how it works, but doesn't really answer a question like "should the screenreader speak the contents of the TabPanel when it becomes visible?"
That example is problematic in that I need to convince the business requirements it shouldn't be spoken, yet nothing actually says one way or the other. (The best I can do is point out that the examples from the Authoring Practices guide are not spoken.)
For that, and a half dozen other issues it would be really nice to have a guide that says "This is what a screen reader does (or should do) when it encounters this element/role."
Does that exist?
There are some very simple principles:
Screen readers will default to start reading the page in DOM order from the beginning to the end. This will be preceded by some basic stats of the page such as the title and the number of links, headings etc. However users will generally not simply allow the screen reader to completely read an entire page and will interrupt the reading to start navigating
If a user knows the page, they will choose a way to navigate to the things they know on the page. Common navigation mechanisms are by headings, forms, landmarks, links, tables etc. If the user does not know the page, they may navigate and explore using different strategies similar to the way that a sighted user would scan a page with her eyes.
When the user navigates, they move their virtual cursor. Normally the focus will follow this cursor jumping from focusable element to focusable element as they are encountered (this is configurable). The screen reader will read out whatever it encounters as the user navigates this. This is akin to a sighted user scanning the page for what to read. The key here is that THE USER NEEDS TO CONTROL WHAT IS READ OUT by navigating around. The one caveat for this is that if the user activates a control that causes some other part of the page to be updated and a sighted user would expect to know that it has updated immediately or know its value, then the application should read this out using ARIA-LIVE.
As you will note, that last point is where this crosses from the technical accessibility into the usability realm. Here are some common mis-conceptions that novices hold.
You need to make everything tab focusable for screen readers: NO you do not, the screen reader can see everything without it being tab focusable,
You need to announce every update to the page: NO you do not. If a user is interacting with a tab, they know through experience, that selecting the tab will expose its contents and there are keyboard commands to get to that content. You do not need to even tell them that the tab has been shown, you simply need to update the selected state of the tab.
You don't need to announce anything: NO, you do need to decide which information is important enough to announce automatically. For example, if you are implementing a chat application, it would be dumb if the user had to navigate around to hear that messages have arrived from her friends. These should be announced automatically.
I strongly suggest that you bring a blind screen reader user into your organization and have them demonstrate to your execs how they do things to illustrate these points.
UAAG
You have to look at the User Agent Accessibility Guidelines (UAAG):
http://www.w3.org/TR/UAAG20-Reference/
They are not intended to define what a screenreader might do but what informations must give the user agent to assistive technologies.
For instance, for giving the focus to a tab panel, you can read the following points:
2.1.4 Separate Selection from Activation
3.3.1 Avoid Unpredictable Focus
Guideline 4.1 - Facilitate programmatic access to assistive technology
5.1.1 Comply with WCAG
WCAG
The WCAG defines what a web developper should do to make his content accessible. It wont tell you how the screen-reader will react, but how you should act to provide the needed informations.
For instance, the focus does not have to trigger a change of context
http://www.w3.org/TR/2015/NOTE-WCAG20-TECHS-20150226/G107
But as long as the user ask a change of context, that's ok.
And the position of the focus will then define the data to be read, except the case of aria live regions.
Important : Accessibility and screen-readers are two different things
You can't resume your accessibility policy to screenreaders only.
And you won't find guidelines oriented to screenreaders only. They are made the general way to not forget all kind of people with disabilities.
That being said, a screenreader will chose the way it acts in the most predictable way. The only thing you might do is testing that your application complies with a logical way of doing things. And if a screenreader does not act as normal, it might be a misconception that could be improved either in your code, either in the assistive technology.
This may sound like an opinion answer, but I believe there's no reliable documentation - mainly because each individual accessibility user has particular requirements of their screenreader. Some don't need text to be spoken aloud while others do. Some have selective preference of what is spoken out. You're even able to change the speed at which text is spoken aloud.
Since all of the major screenreaders are highly customizable down to extremely minute details, this is all dealer's choice.
However, by having the standards and requirements set out for developers to follow and produce consistent applications, it allows the screenreader to interpret information consistently so that the user has the best experience possible. How the screenreader relays this experience is purely up to the user.
One small note, I've addressed my answer directly to screen readers and not the typical WCAG/ARIA guidelines which are widely available and specific enough to achieve what you need as a developer.
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