I have designed a login page which includes username textbox, password textbox, login button, remember me link & forgot password link but the last two links are not coming proper on higher resolution, how can I align it?
In case you haven't done it yet, you can wrap the links in a div container and align it properly along with the rest of the form.
But I do agree it'd be easier if you showed us what exactly is going on on a smaller and on higher res. Have you tried different browser? Some of the rendering engines interpret certain elements differently and that might cause you troubles later on too.
Cheers!
Related
I have a complex multi-column form that the NVDA screen reader reads perfectly well after the page loads, including aria-labels, fields, order of elements, etc. In this working scenario, the form is fully visible when the page loads.
However, I need to hide this form by default when the page loads. This form should only appear if the user clicks a "Show form" link on the page, setting the form from "display: none" to "display: block".
By default, the reader won't automatically read the form after I click "Show form".
So I added aria-live="polite" to the form. The reader will read the form when I click the "Show form" link, but the reading is very poor - things gets mixed, aria-labels get ignored, the reading flow breaks, etc.
So my question is, using a screen reader like NVDA, how do I get a clean and accurate reading of an element that goes from display: none to display: block (based on some user interaction) after the page is loaded?
As I mentioned above, I get a perfect reading only if the form is visible when the page loads.
Aria live regions are only read in two occasions:
When they are added in the DOM
When their content changes
IN all other cases, it isn't officially specified if they must be read or not. They are with some browsers + screen readers combinations, but not with some others.
IN any way, it isn't a good idea to read an entire form section.
If the user can quite well expect something to appear, it's much more important to make it naturally reachable, than to announce the fact that it appeared. By naturally reachable, I mean both by tab and by browser cursor commands like arrow keys or navigation from form element to form element.
In particular, it means that you should for example avoid adding new content at the end of the body, but rather add it in the DOM where it is really expected instead.
Once this is correctly done, at that moment you may think about announcing that the form section appeared. You shouldn't make the whole new section being read, but stick to a simple general message, like "Personal information section appeared below general information". This kind of message has to be in an aria live region.
If that form section appears quite unexpectedly from the user point of view, this announcement can be really useful. If what happens is quite expected, that announcement is relatively optional, if you have made it appear at the right place.
When I click in the search bar, a blue border appears. Why does this happen in several cases?
https://i.stack.imgur.com/9EO3c.jpg
Short answer: Because the website, or possibly your browser, was set up (using css) to make it appear, because most people prefer it that way so they know which box is active.
Depending on your browser, it is probably possible to set it so that this doesn't happen (from your question, I presume that you are asking about other people's websites, not your own), though I can't give you tips on that without knowing what browser you are using.
I'm enhancing the UI for an application to be more compatible with screen readers. The problem is I keep running into issues and I'm beginning to suspect that it' due to the screen reader itself.
Right now I'm mostly testing JAWS 15 with IE 8 (due to corporate limitations it's basically all I can test with at the moment) and getting some weird behavior, but as near as I can tell the aria markup and html all look correct.
For instance:
In some hidden divs (role="alert") the JAWS does not speak "button" after reading a button's name after the DIV is show. (It does speak "button" once you tab to the button though.)
JAWS is speaking elements with aria-hidden="true," which was fixed according to this thread.
Again with hidden alert divs, in some cases JAWS will repeatedly speak elements. In at least one case it will repeat the header and the first line of text infinitely (or at least until my patience ran out.)
The altText for images in table is not read when the entire page is first read. It does get read when the user navigates through the table with the table commands though. I don't even know what corret behavior is on this one...
I'm basically looking for something where I can find out if these are known issues with JAWS/IE8. And if there's a list of compatibility out there (similar to the HTML5 compatibility list) I'll be able to refer to it whenever people bring these issues up.
http://html5accessibility.com/ is a starting point to discover whether a browser has accessibility support for native elements and attributes.
If you're looking for documentation of screen reader support for ARIA attributes, check out The Paciello Group. For example, Steve Faulkner published a post on role=alert that may be helpful.
I have tried: http://www.w3.org/Style/Examples/007/center.en.html. I am a newbie and still learning. Nothing works. Even tried to no avail. It stays to the left!
I am using Cm4all and do the widgets manually in File Manager with Netfirms. They had me:
Log into the control panel with your account username and password.
Click on ‘FileManager’ under ‘Website’.
Click on ‘Settings’.
Check the checkbox ‘Use Richtext Editor’.
Then:
I also called the number you instructed and they said:
centering big groups of content, or centering groups of one specific object on your site can be done with divs and css.
Here are some hyperlinks to instructions/tutorials for common website operations like this.
They gave me three links but can't post the question with the links, says I need at least 10 reputation to post more than 2 links.
Nothing I do will make it leave the left side!!
Accessibility is important to me as I'm a physically disabled developer. I'd like to make sure I have a good feel for what it takes to make a site accessible while also being pointed in the right direction for the things I'm uncertain with, or just haven't considered. So, here's what I'm comfortable with right now:
Alt text for images with meaning.
Percentage or font-relative measurements (ems) for those who need to re-size their screens.
Colors with good contrast for those with colorblindness.
Textual representation of any audio/visual material.
Questions:
Should I make a link at the top of the site to jump down to content on every page?
How is JavaScript handled by screen readers?
Is there anything major I'm missing?
WebAim.org is a great resource for all things web-accessibly related. Suggest starting off with their WCAG (Web Content Accessibility Guidelines) checklist.
Quick answers to your qu's:
Should I make a link at the top of the site to jump down to content on every page?
This is currently recommended best practice. (Eventually HTML5 semantic tags will remove the need for this, but we're not there yet. One thing to watch for: if you do use a hidden link, be sure to make it visible again when it has focus, so that sighted keyboard users don't get 'lost'.)
How is JavaScript handled by screen readers?
All depends on what you use it for. The main area for problem is if new content appears that the user is supposed to be aware of (eg. popups, expanding blocks); if it doesn't get keyboard focus, a screenreader may not read it out to the user and the user may not realize that anything has changed. This is one area where it may be necessary to test with a real-world screenreader (eg. NVDA or JAWS) to ensure that it's actually usable. A simple approach is to only have UI appear in response to user request: eg user hits return on a menu item to make the menu appear, don't make it appear merely in response to it getting focus. Then when it does appear, set focus to the first item: this is both expected behavior for menus in most UIs, and changing the focus typically also causes the screenreader to read out the new item, which confirms to the user that something has happened. (Also, if using Javascript to add behavior to existing elements - eg. make a link behave like a button - use WAI-ARIA attributes such as role="button" to let the screenreader know what the intent is so it will read out that role to the user, and will say 'button' instead of 'link'.)
Is there anything major I'm missing?
I think you've got most of the key points already covered above; the WCAG checklist should fill in everything else. One major area that is worth mentioning is to use headers (H1, etc) appropriately. For screenreader users, navigating by header is a major way for navigating a page. Typically when navigating to a page that a user hasn't visited before, the user will hit a hot-key to get the screenreader to bring up a list of headings on that page as a way of 'skimming' to get an overview. Having good link text is also important; ideally links should be self-describing, so you don't just hear "click for more", "click for more" as you tab through a page.
For newer browsers, IE8, IE9, Firefox 3?, and Safari 5 (possibly 4), and newer screen readers WAI-ARIA is the way to go. Among other things it has landmark roles which if you have an ARIA reading screen reader, such as JAWS 12 and possibly JAWS 11 and 10, the screen reader can use to jump around. It can get a bit clunky if you want things to be backwards accessible but is the direction the web is going in. Their are many other advantages to ARIA but that's the one relevant to your question. On a related note VoiceOver for the Mac is supposed to be ARIA compliant as well.
I'm not disagreeing with the selected best answer, but I would spend more time learning about WCAG 2.0 than with the original WCAG specification. Both in the United States and internationally, the Web Content Accessibility Guideline 2.0 are quickly becoming the standard. In fact, the Access Board, the group tasked with defining the guidelines for Section 508, are refreshing the standards to be harmonized with WCAG 2.0.
You can find great information by starting here Web Content Accessibility Guidelines (WCAG) 2.0.