I have one form which has scrollbar associated with it . page reads properly element by element but focus does not move with voiceover.
I am testing this html form in iphone 5 with ios 8.1.
The focus only moves to elements that are tab focusable. These are elements like links, buttons and input fields or elements that have an explicit tabindex attribute greater than or equal to 0. Voiceover and other screen readers will read out intervening text, but leave the focus on the most recently visited focusable element until the next focusable element is encountered, at which point the focus will jump to that element as it gets read out. This is the way it should work and there is nothing "wrong" with this behavior.
Related
I have a situation where when a div is in focus, NVDA screen reader reads aria labels of all elements in the div.
Here is a code pen which I created to recreate this Codepen - NVDA Screen reader
There are three main div's in the HTML with class names - first-row, separator and second-row.
The div with class second-row has tabindex="0" to make it focusable. This is part of the requirement.
This div also contains 3 child div's with class - header, content and footer each one which has focusable elements with aria-label. The footer child div also has tabindex="0" which again is part of the requirement.
When the focus is on second-row or footer, the NVDA screen reader announces all contents of the div as shown below
second-row - Announced text below
footer - Announced text below
Our requirement was to not let the NVDA announce the div contents which adds to the confusion of the users.
Questions
Is this behavior correct ? Should the NVDA screen reader announce contents of a focusable div ?
I can try using aria-hidden="true" on these focusable div's but this also chains down to child elements, hence when the focus is on the child elements, the screen reader does not announce them. I can write focus-in and focus-out events to update the flag for aria-hidden, but is there any other workaround for this ?
Most of the times, when the focus reaches the first focusable element of a focusable div, NVDA does not announce anything. In the codepen example, the first input element of footer div. What could be going wrong here?
The behavior you observe is absolutely correct. When an element is focused, the accessible content has to be read entirely by the screen reader.
It's the core of its functioning, tell the user what's under focus right now.
Your fundamental problem is that you have overlapping focusable elements.
Focusable elements must never be overlapping, or otherwise said, a focusable element must never be inside another focusable element.
Doing so creates several problems, such as what you observe with confusing content read twice. But also, when the focus is in the inner element, should keyboard events still be sent to both elements ? IN which order ?
Same question when clicking on it, which element(s) should take the focus and/or send events ? One, the other, or both, will arrange you in turn depending on the situation. There is no universal good and correct answer.
Knowing if being on the inside or outside element isn't always super clear either: is it the exact shape of the text or image, taking into account transparent parts or not, or is it the entire rectangular zone ? It depends on CSS background ? And so on.
IN short, it's too easy to make insanely confusing things for the users, so you must really avoid it.
The good news for you is that your tabindex=0 appear totally useless here. You should just remove them.
An element must be focusable if, and only if interactions are possible with that element. If the element doesn't provide any interaction, then it shouldn't be focusable.
Would you focus something which you can't do anything with ? At best it's a waste of energy/efficiency/time because you have to tab once more for nothing, and at worst it's only confusion for the user, who may not realize immediately that the focused element does nothing useful. What's more annoying than writing in the void ?
Here, your divs don't provide any interaction, so they shouldn't be focusable. Remove these totally useless tabindex=0 and voilà, problem solved.
I have a website that displays content based on items checked in a menu list. If the screen width gets too small the menu is rotated and hidden. Additionally, a burger button is displayed. If the burger button gets activated (checkbox as well), the menu is unhidden and the content is hidden.
Neither the content nor the menu have access to the checkbox behind the burger button, because they are children of a sibling of the burger button.
As a result, if a menu item was checked, the burger button is not unchecked, and the visitor needs to click on the burger button again to close the menu and see the content.
Somehow I need to find a hack to uncheck the burger button, if a different menu item was selected, or if a menu item was clicked.
JavaScript is not required yet and shall never be used.
I hope someone knows a hack to fix this - I am clueless in this case...
Thank you for your numerous comments.
The answer is quite simple: CSS3 can't do what I tried to achieve. There was no trick at all to get this done, not even involving the :target pseudo-class, because CSS can't manipulate and reset the URL anchor, neither can it untick the checkbox. That caused the menu staying visible after selecting the content as mentioned above.
As a result, I have rewritten the whole website (well, not the content to be precise).
There is a theoretically simple solution: Using sibling radio buttons for all controls.
This means:
I have one radio button for the burger menu. It accesses the following (sibling) <div> element with the adjacent sibling combinator (+) and toggles the burger menu on and off. (Which results in a changed visibility property.)
I have multiple radio buttons for the content. Succeeded by their respective content div analogously to (1.).
I have multiple labels all over the place that address these radio buttons by using their for attribute. Fortunately, the for attribute has multiplicity 1:n, so that it was possible to address the content <div>s by both, the <nav>-bar, displayed for high resolution devices, as well as the burger menu, displayed on low resolution devices on click on the burger button which is not visible for high resolution displays.
So as a result, I don't do any menu transformations, but have just duplicated the <label>s for these toggles and display either the <nav> bar or the burger button.
Downsides:
I lost the ability to keep the style of the <label>s for the currently active content changed while this content is displayed, since these <label> elements are not siblings of their corresponding checkbox/radio anymore, but on :hover there is an effect.
It is not possible to have the burger menu displayed leaving the current content displayed as well in the background. Both are and need to be in the same radio button group, which means that the burger menu is displayed instead of other content until a label is clicked in the burger menu.
Why am I even doing this (Benefits):
From my perspective, running scripts on a visitors machine is like highjacking their compute power on their device in their sphere and by forcing them to activate JavaScript or other stuff, exposing them to serious risks that could be avoided. So as a result, I consider the unnecessary use of JavaScript as an unethical act.
With this hiding technique of the content I am able to transfer all the content to the visitor a single time and allow for a perfect experience once the content is loaded.
I have a container div whose first child element is another div which acts as a button. The container has one or more additional child elements.
The inner button div is always in the tab order. Our application has a "screen reader mode", and when that is enabled, we also include the outer container div in the tab order. The motivation for this is that we want screen reader users to be able to tab to the whole container, and hear all of the contents read out in order.
The problem is - if the user tabs to the container div and presses the spacebar, the screen reader moves the focus to the child button div, and executes the click action. This happens whether or not the button div has a role of "button". (I'm seeing this happen with JAWS and NVDA. It only happens when the screen reader is running).
Suffice it to say -- we have a complicated UI, and this introduces problems that we'd like to avoid.
Why is this happening? Is there anything I can do to prevent it from happening? I'm open to hacky workarounds.
<div class="container" tabindex="0">
<div role="button" title="tooltip" sys:command="command" tabindex="0">
//Main Content
</div>
<div tabindex=0>
//Secondary Content
</div>
</div>
You need not and must not set the tabindex on this div. Screenreaders have other shortcuts than the tab key (which normally read through focusable elements only) to read non focusable elements.
For instance the description of the browse mode states that
In browse mode, the screen reader cursor can be placed on every element on a website, even on those which aren't inherently focusable, for example headings (<h1>, <h2>, etc.) or paragraphs (<p>).
This wasn't happening previously for me, but I updated to iOS 9.3 two weeks ago and now hidden elements on my web page are hidden when the keyboard is displayed or another input is selected.
Annoyingly a top fixed element is only hidden if the page is scrolled, and the bottom is always hidden. This seems to be a way to 'solve' the issues encountered with fixed elements being left in random positions on the screen when the keyboard is displayed, but now I've got a situation where the elements don't reappear reliably, meaning I lose my main navigation bar for my app.
Is there any way to disable this auto-hiding behaviour? I've created a barebones page that shows the behaviour here: http://128.199.171.247/test.html
Situation:
iOS 7.1
VoiceOver is Enabled
Hyperlink (<a href="#content">) points to:
target element on the page (<div id="content">page contents</div> or <a id="content"></a>)
URL I'm investigating: http://www.yooralla.com.au/whats-on/yooralla-media-awards/yooralla-media-awards-judges-pack
What happens:
Select and activate the link
A border appears on the target element (which is halfway down the screen)
The page scrolls so that the target element is at the top of the screen, but the border stays halfway down the screen.
The closest element to the border is then selected and bordered, so reading starts halfway down the page instead of at the target element.
Closest reference that I can find to this issue is item 1 here, so maybe it is fixed in iOS 8.
But I'm trying to work out why it's happening and how to avoid it on as many devices possible. I've tried linking both to the main content div (which fills most of the page), and inserting an empty a tag, both of which behave the same.
EDIT:
I've tried to force the reading position by setting focus or scrolling with JavaScript, but VoiceOver still ignores this and reads from the wrong place.