Does anyone know if the aria authoring web page is keyboard accessible(https://www.w3.org/TR/wai-aria-practices-1.1/) ? Looking for keyboard interaction assistance to move focus between the left and right pane.
It'd be nice if browsers took advantage of landmarks so that keyboard users would benefit. Currently, only screen reader users benefit from them. Most applications on a PC allow the F6 key to navigate to different areas. Try it in Word, Excel, browsers, whatever desktop apps. It even sort of works on the authoring practice page, but not completely (at least not in firefox).
We had to implement our own landmarks dialog that we invoked with Ctrl+F6 (so it'd be similar to F6) and we'd query the page for landmark roles and display them in a dialog to allow you to quickly jump to a section of the page.
Skip links are about as close as you can get now, but even that wouldn't help on a page like the authoring practice. If I had tabbed through half the links in the left nav panel and then decided I wanted to move the main contents in the right panel, a skip link wouldn't help. I'd have to navigate back to the skip link in order to jump to the main section. It'd be nice to hit a key while I was in the middle of the left nav to jump me to the right side.
You could use the accesskey attribute to allow a shortkey to move between the two, but those are hard to discover. JAWS will tell you about the accesskey but NVDA and VoiceOver will not. If you don't have any indication on the screen that there's a shortcut/accesskey, then how will people know it's there. Once they know about it, it's great. For example, wikipedia has an accesskey='f' on the search field, but you might not know that. Once you do know it, it's great to be in the middle of a wiki article and hit alt+shift+f (on firefox and chrome) or alt+f (internet explorer) to quickly jump to the search field.
You could do the same with a left panel / right panel configuration if you had an accesskey on an object in the left panel and a different accesskey on an object in the right panel. Just make sure users know about it.
Related
We are trying to improve handicapped accessibility of one of our pages and allow a user to perform all the actions without a mouse. The page contains some buttons and an iframe with a pdf document. In IE11 I can tab through the buttons but when the control goes to the pdf viewer iframe, nothing is highlighted and pressing tab doesn't do anything.
In chrome pressing tab will cycle in through the buttons, than the handful of controls on the pdf and than step out of the viewer and start to cycle again. How do I get IE to do the same thing.
As a side note if I use shift+tab to cycle backwards, IE will ignore the iframe and cycle through the elements correctly. In fact after tabbing into the iframe, I can use shift+tab to get back to the button controls.
Any help would be greatly appreciated.
It sounds like you're trying to test PDF accessibility in the browser, which isn't really how things are done. The PDF viewers in web browsers are inferior to Acrobat, and people who need assistive technology likely won't be using the PDF readers built into IE or Chrome anyway.
As a starting point, I'd recommend opening up the document in Acrobat and making sure that it has tags. If it doesn't, you can try to have Acrobat generate them for you. If you're using any kind of a complex layout (other than simple text, images, and maybe lists), then the tagging will probably require you to manually review and correct them. PDF tags are structured very similar to HTML (but not entirely identical). If you already know HTML, then you'll probably be able to tag PDFs well enough. Otherwise, there's going to be a learning curve.
PDF remediation is an art unto itself that takes some time to master.
Here are some resources that will hopefully point you in the right direction:
https://webaim.org/techniques/acrobat/
https://helpx.adobe.com/acrobat/using/create-verify-pdf-accessibility.html
https://www.washington.edu/accessibility/documents/pdf-acrobat/
I am facing an issue of aria and accessibility aria labels.
That's my problem:
After opens a page, I need that the screen reader reads the title and then stop reading the rest of the page.
I need that the screen reader stops there, and just continue reading after the user uses TABS to navigate.
does anyone know if it is possible?
The screen reader user has complete control over how much information is read. They might have their settings so that nothing is read when the page is loaded except maybe the page title. Or they might have it set so the entire page is read. It's not something you can control, nor should you. It's very user specific.
Adding to the already existing answer:
Of course you could force something like this using aria notifiy (aka on page load aria notify page title, and that's it). this would lead to the screenreader getting interrupted, the page title getting announced and then silence until the user moves (or other notification arrives). But this kind of behaviour would be super confusing to blind people, as it is pretty unnatural.
I myself am blind and believe me: Blind people, especially NVDA or Jaws users (don't know about Window Eyes) have an entire scripting language at the ready if need be. They may choose to make your web page appear completely different for them than it appears for others, react in different ways - and how verbose the page is presented (on braille display and voice) is entirely up to the blind user. Don't bother with that, they'll figure it out themselves
If the talking of the screenreader annoys them, they can always press shift to pause the screenreader or control to silence it altogether. They'll be fine.
I'm working on a site that requires WCAG 2.0 AA adherence, but although we try to make tab navigation usable on our sites, it does detract heavily from the design due to the strange borders and outlines being rendered when you click a focusable element.
My thinking is, hide all focus states until the tab key is actually pressed.
So, my question is, does this pose any potential problems with accessibility technologies for the web?
Remember that sometimes focus is placed on elements without using a keyboard, such as via script or third-party tools (like screen readers prior to page interaction). Also note that even screen reader users do not necessarily use the Tab key (for example, I can navigate the headings on a page by pressing H in most screen readers, and on mobile I can navigate a page elements without using a keyboard at all. Also note that some users with cognitive impairments benefit from focus styles even when using a mouse.
As such, if I were reviewing a site that disabled focus styles only until someone pressed the Tab key, I would still fail it for 2.4.7
Focus Visible. It might be helpful to read the Understanding SC 2.4.7 document for a little more context.
To answer your question, yes, removing it does post potential accessibility problems.
All that being said, I would instead challenge the designer to do what designers tend to do best — work within constraints. Come up with focus styles that are not distracting, with styles that are perceivable, operable, understandable, and robust (so, for example, it meets contrast minimums). It has been done before, so there is no reason it cannot be done again.
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.
I'm newer in Flex and I would like to disable the Navigation Bar and the bookmarks tab cause I need to show a lot of information so I really need to have as much space as it's possible. I do not know what I can do.
Thanks in advance,
Alicia
Do you mean the navigation and bookmarks in the browser?
Depending on the content of your application, you could potentially use full screen mode, but that has some restrictions around keyboard input (only some keys are allowed such as arrow keys, enter key etc)
Otherwise you may just need to prompt the user to turn their browser to full-screen so that they can see as much of the app as possible.
Browser full-screen/maximise is different from Flash full-screen as all keyboard input is still possible.
As far as I know there wouldn't be a way to actually modify the appearance of the browser from within a Flash application.