Mixing
Best way to focus element of any kind
I have the following requirements:
On my webpage there are anchor links for navigation (thinks like skip to content etc.). These anchors are supposed to bring the target element into view and focus it. (Focus is important, because else screenreaders don't get positioned correctly. so far my code looks like this:
<a href="#content" class="navbtn">Skip to content</a>
<!-- somewhere else...-->
<div id="content" tabindex="-1">
Lorem ipsum...
</div>
<script>
$(".navbtn").click(function(e) {
e.preventDefault();
$("#content").focus();
});
</script>
Please note that I'm aware this is hardcoded and I'll change that in the future, but for test purposes I left it to this.
OK, so what does this do?
In this post
the method above was said to focus the div element. Visually I cannot judge, but my screenreader won't move to the element (I'm using VoiceOver in Safari on an iPhone). If the target is a button, a link or any other element which has a tabindex by default, it works fine.
Any ideas?
EDIT: I got it to wolk with my braille display when pressing the left mode key. I usually use the right mode key to send a double tap event to the phone, but the right one doesn't work. The left one, however, does. I don't know why, to be honest. Double tap onscreen still doesn't work... Either way, no JavaScript needed.
javascript jquery html focus accessibility
asked Dec 30 '18 at 13:41
TimBTimB
1949
add a comment |
I have the following requirements:
On my webpage there are anchor links for navigation (thinks like skip to content etc.). These anchors are supposed to bring the target element into view and focus it. (Focus is important, because else screenreaders don't get positioned correctly. so far my code looks like this:
<a href="#content" class="navbtn">Skip to content</a>
<!-- somewhere else...-->
<div id="content" tabindex="-1">
Lorem ipsum...
</div>
<script>
$(".navbtn").click(function(e) {
e.preventDefault();
$("#content").focus();
});
</script>
Please note that I'm aware this is hardcoded and I'll change that in the future, but for test purposes I left it to this.
OK, so what does this do?
In this post
the method above was said to focus the div element. Visually I cannot judge, but my screenreader won't move to the element (I'm using VoiceOver in Safari on an iPhone). If the target is a button, a link or any other element which has a tabindex by default, it works fine.
Any ideas?
EDIT: I got it to wolk with my braille display when pressing the left mode key. I usually use the right mode key to send a double tap event to the phone, but the right one doesn't work. The left one, however, does. I don't know why, to be honest. Double tap onscreen still doesn't work... Either way, no JavaScript needed.
javascript jquery html focus accessibility
asked Dec 30 '18 at 13:41
TimBTimB
1949
add a comment |
I have the following requirements:
On my webpage there are anchor links for navigation (thinks like skip to content etc.). These anchors are supposed to bring the target element into view and focus it. (Focus is important, because else screenreaders don't get positioned correctly. so far my code looks like this:
<a href="#content" class="navbtn">Skip to content</a>
<!-- somewhere else...-->
<div id="content" tabindex="-1">
Lorem ipsum...
</div>
<script>
$(".navbtn").click(function(e) {
e.preventDefault();
$("#content").focus();
});
</script>
Please note that I'm aware this is hardcoded and I'll change that in the future, but for test purposes I left it to this.
OK, so what does this do?
In this post
the method above was said to focus the div element. Visually I cannot judge, but my screenreader won't move to the element (I'm using VoiceOver in Safari on an iPhone). If the target is a button, a link or any other element which has a tabindex by default, it works fine.
Any ideas?
EDIT: I got it to wolk with my braille display when pressing the left mode key. I usually use the right mode key to send a double tap event to the phone, but the right one doesn't work. The left one, however, does. I don't know why, to be honest. Double tap onscreen still doesn't work... Either way, no JavaScript needed.
javascript jquery html focus accessibility
asked Dec 30 '18 at 13:41
TimBTimB
1949
I have the following requirements:
On my webpage there are anchor links for navigation (thinks like skip to content etc.). These anchors are supposed to bring the target element into view and focus it. (Focus is important, because else screenreaders don't get positioned correctly. so far my code looks like this:
<a href="#content" class="navbtn">Skip to content</a>
<!-- somewhere else...-->
<div id="content" tabindex="-1">
Lorem ipsum...
</div>
<script>
$(".navbtn").click(function(e) {
e.preventDefault();
$("#content").focus();
});
</script>
Please note that I'm aware this is hardcoded and I'll change that in the future, but for test purposes I left it to this.
OK, so what does this do?
In this post
the method above was said to focus the div element. Visually I cannot judge, but my screenreader won't move to the element (I'm using VoiceOver in Safari on an iPhone). If the target is a button, a link or any other element which has a tabindex by default, it works fine.
Any ideas?
EDIT: I got it to wolk with my braille display when pressing the left mode key. I usually use the right mode key to send a double tap event to the phone, but the right one doesn't work. The left one, however, does. I don't know why, to be honest. Double tap onscreen still doesn't work... Either way, no JavaScript needed.
javascript jquery html focus accessibility
javascript jquery html focus accessibility
asked Dec 30 '18 at 13:41
TimBTimB
1949
asked Dec 30 '18 at 13:41
TimBTimB
1949
edited Jan 1 at 12:52
TimB
asked Dec 30 '18 at 13:41
TimBTimB
1949
asked Dec 30 '18 at 13:41
TimBTimB
1949
asked Dec 30 '18 at 13:41
TimBTimB
1949
1949
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
I've just tested the following (with no JavaScript) on an iPhone running iOS12, with VoiceOver in Safari:
<a href="#content">Skip to content</a>
...
<div id="content" tabindex="-1">Target content...</div>
It worked as expected, with focus moving to the target content and VoiceOver announcing "Target content...". Can you describe the steps you're taking when you test in more detail?
answered Jan 1 at 11:18
Léonie WatsonLéonie Watson
1063
My code looks exactly like yours. I navigate to the link with my braille display, then press the braille display key that equals a double tap. Focus does not move. I'll test using the screen only, however.
– TimB
Jan 1 at 12:25
Even when just using the screen, it doesn't work. If I doubletap the link it says "reader available" and that's it, focus does not move (using VO, Safari, iOS 12.1.2)
– TimB
Jan 1 at 12:31
Based on the fact you're hearing "Reader available", it may be that the page you're testing on is triggering Safari's Reader feature, and it's getting in the way of your interaction?
– Léonie Watson
Jan 2 at 13:30
Is there some way of avoiding this?
– TimB
Jan 2 at 13:34
It's a browser feature, so it'll be up to the user to dismiss it I think.
– Léonie Watson
Jan 4 at 19:58
|
show 1 more comment
You're doing too much work. By default, an <a> will move the focus for you. However, if the destination element is not a natively focusable element, then it must also have tabindex="-1" for some browsers (mainly Internet Explorer). See "Accessible HTML Elements" in "About Active Accessibility Support" for the reason why.
So your above example will work with simply:
<a href="#content" class="navbtn">Skip to content</a>
<!-- somewhere else...-->
<div id="content" tabindex="-1">
Lorem ipsum...
</div>
No javascript is needed. You can test it by using the keyboard to tab to the "Skip to content" link then pressing enter. If you then press tab again, the focus should move to whatever focusable element is after your <div>.
If you then shift+tab, you will not go back to the <div> (which is the behavior you want) because it has tabindex="-1" instead of tabindex="0".
I use this pattern all the time in my accessible websites.
However (and this is a big "however" and I think is the main point of your question), VoiceOver on iOS (not sure about the Mac) will not honor the focus change. That's a bug (in my opinion) with Apple. Go to any website that has in-page links and the VoiceOver focus won't move the destination element. You can see one reference to this problem at https://www.applevis.com/forum/ios-ios-app-discussion/skip-link-issue
Unfortunately, you should write your code using the simple example (no javascript required) and VoiceOver users on iOS will continue to have a problem like they have on all other sites.
answered Dec 31 '18 at 6:02
slugoliciousslugolicious
5,38911320
What confuses me (and lead me to the assumption there was a way to work around this), is that on certain pages (for example SELFHTML) focus movement on Anchor links appears to work...
– TimB
Dec 31 '18 at 7:52
Hmm, that is strange. I tried wiki (en.wikipedia.org/wiki/Puppy) and when I selected "Development" (the first item under the table of contents), it moved my VoiceOver focus to the development section correctly. Wiki does not usetabindex="-1"so their page does not move the focus properly on Internet Explorer. Perhaps thetabindex="-1"is what's causing the problem for VoiceOver. (Note: If you try the wiki url in this comment from iOS, it might take you to the mobile version. Go to the last link on the page, "desktop", to go to the deskop version to test.)
– slugolicious
Jan 1 at 19:13
I now have divs with and without tabindex and currently none work, regardless whether I doubletap onscreen or use my braille display. But a while ago it definitely worked (with tabindex) when I used the left mode key...
– TimB
Jan 1 at 19:20
add a comment |
Use tabindex="-1" on the div instead of tabindex="0". It will make the div programmatically focusable, whereas tabindex="0" makes it user focusable (as someone uses the tab key to move through the content). More on Using the tabindex attribute
answered Dec 30 '18 at 22:04
Léonie WatsonLéonie Watson
1063
I read the article you posted and also did more research, but whether it's tabindex="0" or tabindex="-1" - if I click the link, nothing happens. If the target is a button, or link, or the like focus gets moved appropriately... but not if it's a div.
– TimB
Dec 31 '18 at 0:01
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53978096%2fbest-way-to-focus-element-of-any-kind%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
I've just tested the following (with no JavaScript) on an iPhone running iOS12, with VoiceOver in Safari:
<a href="#content">Skip to content</a>
...
<div id="content" tabindex="-1">Target content...</div>
It worked as expected, with focus moving to the target content and VoiceOver announcing "Target content...". Can you describe the steps you're taking when you test in more detail?
answered Jan 1 at 11:18
Léonie WatsonLéonie Watson
1063
My code looks exactly like yours. I navigate to the link with my braille display, then press the braille display key that equals a double tap. Focus does not move. I'll test using the screen only, however.
– TimB
Jan 1 at 12:25
Even when just using the screen, it doesn't work. If I doubletap the link it says "reader available" and that's it, focus does not move (using VO, Safari, iOS 12.1.2)
– TimB
Jan 1 at 12:31
Based on the fact you're hearing "Reader available", it may be that the page you're testing on is triggering Safari's Reader feature, and it's getting in the way of your interaction?
– Léonie Watson
Jan 2 at 13:30
Is there some way of avoiding this?
– TimB
Jan 2 at 13:34
It's a browser feature, so it'll be up to the user to dismiss it I think.
– Léonie Watson
Jan 4 at 19:58
|
show 1 more comment
I've just tested the following (with no JavaScript) on an iPhone running iOS12, with VoiceOver in Safari:
<a href="#content">Skip to content</a>
...
<div id="content" tabindex="-1">Target content...</div>
It worked as expected, with focus moving to the target content and VoiceOver announcing "Target content...". Can you describe the steps you're taking when you test in more detail?
answered Jan 1 at 11:18
Léonie WatsonLéonie Watson
1063
My code looks exactly like yours. I navigate to the link with my braille display, then press the braille display key that equals a double tap. Focus does not move. I'll test using the screen only, however.
– TimB
Jan 1 at 12:25
Even when just using the screen, it doesn't work. If I doubletap the link it says "reader available" and that's it, focus does not move (using VO, Safari, iOS 12.1.2)
– TimB
Jan 1 at 12:31
Based on the fact you're hearing "Reader available", it may be that the page you're testing on is triggering Safari's Reader feature, and it's getting in the way of your interaction?
– Léonie Watson
Jan 2 at 13:30
Is there some way of avoiding this?
– TimB
Jan 2 at 13:34
It's a browser feature, so it'll be up to the user to dismiss it I think.
– Léonie Watson
Jan 4 at 19:58
|
show 1 more comment
I've just tested the following (with no JavaScript) on an iPhone running iOS12, with VoiceOver in Safari:
<a href="#content">Skip to content</a>
...
<div id="content" tabindex="-1">Target content...</div>
It worked as expected, with focus moving to the target content and VoiceOver announcing "Target content...". Can you describe the steps you're taking when you test in more detail?
answered Jan 1 at 11:18
Léonie WatsonLéonie Watson
1063
I've just tested the following (with no JavaScript) on an iPhone running iOS12, with VoiceOver in Safari:
<a href="#content">Skip to content</a>
...
<div id="content" tabindex="-1">Target content...</div>
It worked as expected, with focus moving to the target content and VoiceOver announcing "Target content...". Can you describe the steps you're taking when you test in more detail?
answered Jan 1 at 11:18
Léonie WatsonLéonie Watson
1063
answered Jan 1 at 11:18
Léonie WatsonLéonie Watson
1063
answered Jan 1 at 11:18
Léonie WatsonLéonie Watson
1063
answered Jan 1 at 11:18
Léonie WatsonLéonie Watson
1063
1063
My code looks exactly like yours. I navigate to the link with my braille display, then press the braille display key that equals a double tap. Focus does not move. I'll test using the screen only, however.
– TimB
Jan 1 at 12:25
Even when just using the screen, it doesn't work. If I doubletap the link it says "reader available" and that's it, focus does not move (using VO, Safari, iOS 12.1.2)
– TimB
Jan 1 at 12:31
Based on the fact you're hearing "Reader available", it may be that the page you're testing on is triggering Safari's Reader feature, and it's getting in the way of your interaction?
– Léonie Watson
Jan 2 at 13:30
Is there some way of avoiding this?
– TimB
Jan 2 at 13:34
It's a browser feature, so it'll be up to the user to dismiss it I think.
– Léonie Watson
Jan 4 at 19:58
|
show 1 more comment
My code looks exactly like yours. I navigate to the link with my braille display, then press the braille display key that equals a double tap. Focus does not move. I'll test using the screen only, however.
– TimB
Jan 1 at 12:25
Even when just using the screen, it doesn't work. If I doubletap the link it says "reader available" and that's it, focus does not move (using VO, Safari, iOS 12.1.2)
– TimB
Jan 1 at 12:31
Based on the fact you're hearing "Reader available", it may be that the page you're testing on is triggering Safari's Reader feature, and it's getting in the way of your interaction?
– Léonie Watson
Jan 2 at 13:30
Is there some way of avoiding this?
– TimB
Jan 2 at 13:34
It's a browser feature, so it'll be up to the user to dismiss it I think.
– Léonie Watson
Jan 4 at 19:58
My code looks exactly like yours. I navigate to the link with my braille display, then press the braille display key that equals a double tap. Focus does not move. I'll test using the screen only, however.
– TimB
Jan 1 at 12:25
My code looks exactly like yours. I navigate to the link with my braille display, then press the braille display key that equals a double tap. Focus does not move. I'll test using the screen only, however.
– TimB
Jan 1 at 12:25
Even when just using the screen, it doesn't work. If I doubletap the link it says "reader available" and that's it, focus does not move (using VO, Safari, iOS 12.1.2)
– TimB
Jan 1 at 12:31
Even when just using the screen, it doesn't work. If I doubletap the link it says "reader available" and that's it, focus does not move (using VO, Safari, iOS 12.1.2)
– TimB
Jan 1 at 12:31
Based on the fact you're hearing "Reader available", it may be that the page you're testing on is triggering Safari's Reader feature, and it's getting in the way of your interaction?
– Léonie Watson
Jan 2 at 13:30
Based on the fact you're hearing "Reader available", it may be that the page you're testing on is triggering Safari's Reader feature, and it's getting in the way of your interaction?
– Léonie Watson
Jan 2 at 13:30
Is there some way of avoiding this?
– TimB
Jan 2 at 13:34
Is there some way of avoiding this?
– TimB
Jan 2 at 13:34
It's a browser feature, so it'll be up to the user to dismiss it I think.
– Léonie Watson
Jan 4 at 19:58
It's a browser feature, so it'll be up to the user to dismiss it I think.
– Léonie Watson
Jan 4 at 19:58
|
show 1 more comment
You're doing too much work. By default, an <a> will move the focus for you. However, if the destination element is not a natively focusable element, then it must also have tabindex="-1" for some browsers (mainly Internet Explorer). See "Accessible HTML Elements" in "About Active Accessibility Support" for the reason why.
So your above example will work with simply:
<a href="#content" class="navbtn">Skip to content</a>
<!-- somewhere else...-->
<div id="content" tabindex="-1">
Lorem ipsum...
</div>
No javascript is needed. You can test it by using the keyboard to tab to the "Skip to content" link then pressing enter. If you then press tab again, the focus should move to whatever focusable element is after your <div>.
If you then shift+tab, you will not go back to the <div> (which is the behavior you want) because it has tabindex="-1" instead of tabindex="0".
I use this pattern all the time in my accessible websites.
However (and this is a big "however" and I think is the main point of your question), VoiceOver on iOS (not sure about the Mac) will not honor the focus change. That's a bug (in my opinion) with Apple. Go to any website that has in-page links and the VoiceOver focus won't move the destination element. You can see one reference to this problem at https://www.applevis.com/forum/ios-ios-app-discussion/skip-link-issue
Unfortunately, you should write your code using the simple example (no javascript required) and VoiceOver users on iOS will continue to have a problem like they have on all other sites.
answered Dec 31 '18 at 6:02
slugoliciousslugolicious
5,38911320
What confuses me (and lead me to the assumption there was a way to work around this), is that on certain pages (for example SELFHTML) focus movement on Anchor links appears to work...
– TimB
Dec 31 '18 at 7:52
Hmm, that is strange. I tried wiki (en.wikipedia.org/wiki/Puppy) and when I selected "Development" (the first item under the table of contents), it moved my VoiceOver focus to the development section correctly. Wiki does not usetabindex="-1"so their page does not move the focus properly on Internet Explorer. Perhaps thetabindex="-1"is what's causing the problem for VoiceOver. (Note: If you try the wiki url in this comment from iOS, it might take you to the mobile version. Go to the last link on the page, "desktop", to go to the deskop version to test.)
– slugolicious
Jan 1 at 19:13
I now have divs with and without tabindex and currently none work, regardless whether I doubletap onscreen or use my braille display. But a while ago it definitely worked (with tabindex) when I used the left mode key...
– TimB
Jan 1 at 19:20
add a comment |
You're doing too much work. By default, an <a> will move the focus for you. However, if the destination element is not a natively focusable element, then it must also have tabindex="-1" for some browsers (mainly Internet Explorer). See "Accessible HTML Elements" in "About Active Accessibility Support" for the reason why.
So your above example will work with simply:
<a href="#content" class="navbtn">Skip to content</a>
<!-- somewhere else...-->
<div id="content" tabindex="-1">
Lorem ipsum...
</div>
No javascript is needed. You can test it by using the keyboard to tab to the "Skip to content" link then pressing enter. If you then press tab again, the focus should move to whatever focusable element is after your <div>.
If you then shift+tab, you will not go back to the <div> (which is the behavior you want) because it has tabindex="-1" instead of tabindex="0".
I use this pattern all the time in my accessible websites.
However (and this is a big "however" and I think is the main point of your question), VoiceOver on iOS (not sure about the Mac) will not honor the focus change. That's a bug (in my opinion) with Apple. Go to any website that has in-page links and the VoiceOver focus won't move the destination element. You can see one reference to this problem at https://www.applevis.com/forum/ios-ios-app-discussion/skip-link-issue
Unfortunately, you should write your code using the simple example (no javascript required) and VoiceOver users on iOS will continue to have a problem like they have on all other sites.
answered Dec 31 '18 at 6:02
slugoliciousslugolicious
5,38911320
What confuses me (and lead me to the assumption there was a way to work around this), is that on certain pages (for example SELFHTML) focus movement on Anchor links appears to work...
– TimB
Dec 31 '18 at 7:52
Hmm, that is strange. I tried wiki (en.wikipedia.org/wiki/Puppy) and when I selected "Development" (the first item under the table of contents), it moved my VoiceOver focus to the development section correctly. Wiki does not usetabindex="-1"so their page does not move the focus properly on Internet Explorer. Perhaps thetabindex="-1"is what's causing the problem for VoiceOver. (Note: If you try the wiki url in this comment from iOS, it might take you to the mobile version. Go to the last link on the page, "desktop", to go to the deskop version to test.)
– slugolicious
Jan 1 at 19:13
I now have divs with and without tabindex and currently none work, regardless whether I doubletap onscreen or use my braille display. But a while ago it definitely worked (with tabindex) when I used the left mode key...
– TimB
Jan 1 at 19:20
add a comment |
You're doing too much work. By default, an <a> will move the focus for you. However, if the destination element is not a natively focusable element, then it must also have tabindex="-1" for some browsers (mainly Internet Explorer). See "Accessible HTML Elements" in "About Active Accessibility Support" for the reason why.
So your above example will work with simply:
<a href="#content" class="navbtn">Skip to content</a>
<!-- somewhere else...-->
<div id="content" tabindex="-1">
Lorem ipsum...
</div>
No javascript is needed. You can test it by using the keyboard to tab to the "Skip to content" link then pressing enter. If you then press tab again, the focus should move to whatever focusable element is after your <div>.
If you then shift+tab, you will not go back to the <div> (which is the behavior you want) because it has tabindex="-1" instead of tabindex="0".
I use this pattern all the time in my accessible websites.
However (and this is a big "however" and I think is the main point of your question), VoiceOver on iOS (not sure about the Mac) will not honor the focus change. That's a bug (in my opinion) with Apple. Go to any website that has in-page links and the VoiceOver focus won't move the destination element. You can see one reference to this problem at https://www.applevis.com/forum/ios-ios-app-discussion/skip-link-issue
Unfortunately, you should write your code using the simple example (no javascript required) and VoiceOver users on iOS will continue to have a problem like they have on all other sites.
answered Dec 31 '18 at 6:02
slugoliciousslugolicious
5,38911320
You're doing too much work. By default, an <a> will move the focus for you. However, if the destination element is not a natively focusable element, then it must also have tabindex="-1" for some browsers (mainly Internet Explorer). See "Accessible HTML Elements" in "About Active Accessibility Support" for the reason why.
So your above example will work with simply:
<a href="#content" class="navbtn">Skip to content</a>
<!-- somewhere else...-->
<div id="content" tabindex="-1">
Lorem ipsum...
</div>
No javascript is needed. You can test it by using the keyboard to tab to the "Skip to content" link then pressing enter. If you then press tab again, the focus should move to whatever focusable element is after your <div>.
If you then shift+tab, you will not go back to the <div> (which is the behavior you want) because it has tabindex="-1" instead of tabindex="0".
I use this pattern all the time in my accessible websites.
However (and this is a big "however" and I think is the main point of your question), VoiceOver on iOS (not sure about the Mac) will not honor the focus change. That's a bug (in my opinion) with Apple. Go to any website that has in-page links and the VoiceOver focus won't move the destination element. You can see one reference to this problem at https://www.applevis.com/forum/ios-ios-app-discussion/skip-link-issue
Unfortunately, you should write your code using the simple example (no javascript required) and VoiceOver users on iOS will continue to have a problem like they have on all other sites.
answered Dec 31 '18 at 6:02
slugoliciousslugolicious
5,38911320
answered Dec 31 '18 at 6:02
slugoliciousslugolicious
5,38911320
answered Dec 31 '18 at 6:02
slugoliciousslugolicious
5,38911320
answered Dec 31 '18 at 6:02
slugoliciousslugolicious
5,38911320
5,38911320
What confuses me (and lead me to the assumption there was a way to work around this), is that on certain pages (for example SELFHTML) focus movement on Anchor links appears to work...
– TimB
Dec 31 '18 at 7:52
Hmm, that is strange. I tried wiki (en.wikipedia.org/wiki/Puppy) and when I selected "Development" (the first item under the table of contents), it moved my VoiceOver focus to the development section correctly. Wiki does not usetabindex="-1"so their page does not move the focus properly on Internet Explorer. Perhaps thetabindex="-1"is what's causing the problem for VoiceOver. (Note: If you try the wiki url in this comment from iOS, it might take you to the mobile version. Go to the last link on the page, "desktop", to go to the deskop version to test.)
– slugolicious
Jan 1 at 19:13
I now have divs with and without tabindex and currently none work, regardless whether I doubletap onscreen or use my braille display. But a while ago it definitely worked (with tabindex) when I used the left mode key...
– TimB
Jan 1 at 19:20
add a comment |
What confuses me (and lead me to the assumption there was a way to work around this), is that on certain pages (for example SELFHTML) focus movement on Anchor links appears to work...
– TimB
Dec 31 '18 at 7:52
Hmm, that is strange. I tried wiki (en.wikipedia.org/wiki/Puppy) and when I selected "Development" (the first item under the table of contents), it moved my VoiceOver focus to the development section correctly. Wiki does not usetabindex="-1"so their page does not move the focus properly on Internet Explorer. Perhaps thetabindex="-1"is what's causing the problem for VoiceOver. (Note: If you try the wiki url in this comment from iOS, it might take you to the mobile version. Go to the last link on the page, "desktop", to go to the deskop version to test.)
– slugolicious
Jan 1 at 19:13
I now have divs with and without tabindex and currently none work, regardless whether I doubletap onscreen or use my braille display. But a while ago it definitely worked (with tabindex) when I used the left mode key...
– TimB
Jan 1 at 19:20
What confuses me (and lead me to the assumption there was a way to work around this), is that on certain pages (for example SELFHTML) focus movement on Anchor links appears to work...
– TimB
Dec 31 '18 at 7:52
What confuses me (and lead me to the assumption there was a way to work around this), is that on certain pages (for example SELFHTML) focus movement on Anchor links appears to work...
– TimB
Dec 31 '18 at 7:52
Hmm, that is strange. I tried wiki (en.wikipedia.org/wiki/Puppy) and when I selected "Development" (the first item under the table of contents), it moved my VoiceOver focus to the development section correctly. Wiki does not use
tabindex="-1" so their page does not move the focus properly on Internet Explorer. Perhaps the tabindex="-1" is what's causing the problem for VoiceOver. (Note: If you try the wiki url in this comment from iOS, it might take you to the mobile version. Go to the last link on the page, "desktop", to go to the deskop version to test.)– slugolicious
Jan 1 at 19:13
Hmm, that is strange. I tried wiki (en.wikipedia.org/wiki/Puppy) and when I selected "Development" (the first item under the table of contents), it moved my VoiceOver focus to the development section correctly. Wiki does not use
tabindex="-1" so their page does not move the focus properly on Internet Explorer. Perhaps the tabindex="-1" is what's causing the problem for VoiceOver. (Note: If you try the wiki url in this comment from iOS, it might take you to the mobile version. Go to the last link on the page, "desktop", to go to the deskop version to test.)– slugolicious
Jan 1 at 19:13
I now have divs with and without tabindex and currently none work, regardless whether I doubletap onscreen or use my braille display. But a while ago it definitely worked (with tabindex) when I used the left mode key...
– TimB
Jan 1 at 19:20
I now have divs with and without tabindex and currently none work, regardless whether I doubletap onscreen or use my braille display. But a while ago it definitely worked (with tabindex) when I used the left mode key...
– TimB
Jan 1 at 19:20
add a comment |
Use tabindex="-1" on the div instead of tabindex="0". It will make the div programmatically focusable, whereas tabindex="0" makes it user focusable (as someone uses the tab key to move through the content). More on Using the tabindex attribute
answered Dec 30 '18 at 22:04
Léonie WatsonLéonie Watson
1063
I read the article you posted and also did more research, but whether it's tabindex="0" or tabindex="-1" - if I click the link, nothing happens. If the target is a button, or link, or the like focus gets moved appropriately... but not if it's a div.
– TimB
Dec 31 '18 at 0:01
add a comment |
Use tabindex="-1" on the div instead of tabindex="0". It will make the div programmatically focusable, whereas tabindex="0" makes it user focusable (as someone uses the tab key to move through the content). More on Using the tabindex attribute
answered Dec 30 '18 at 22:04
Léonie WatsonLéonie Watson
1063
I read the article you posted and also did more research, but whether it's tabindex="0" or tabindex="-1" - if I click the link, nothing happens. If the target is a button, or link, or the like focus gets moved appropriately... but not if it's a div.
– TimB
Dec 31 '18 at 0:01
add a comment |
Use tabindex="-1" on the div instead of tabindex="0". It will make the div programmatically focusable, whereas tabindex="0" makes it user focusable (as someone uses the tab key to move through the content). More on Using the tabindex attribute
answered Dec 30 '18 at 22:04
Léonie WatsonLéonie Watson
1063
Use tabindex="-1" on the div instead of tabindex="0". It will make the div programmatically focusable, whereas tabindex="0" makes it user focusable (as someone uses the tab key to move through the content). More on Using the tabindex attribute
answered Dec 30 '18 at 22:04
Léonie WatsonLéonie Watson
1063
answered Dec 30 '18 at 22:04
Léonie WatsonLéonie Watson
1063
answered Dec 30 '18 at 22:04
Léonie WatsonLéonie Watson
1063
answered Dec 30 '18 at 22:04
Léonie WatsonLéonie Watson
1063
1063
I read the article you posted and also did more research, but whether it's tabindex="0" or tabindex="-1" - if I click the link, nothing happens. If the target is a button, or link, or the like focus gets moved appropriately... but not if it's a div.
– TimB
Dec 31 '18 at 0:01
add a comment |
I read the article you posted and also did more research, but whether it's tabindex="0" or tabindex="-1" - if I click the link, nothing happens. If the target is a button, or link, or the like focus gets moved appropriately... but not if it's a div.
– TimB
Dec 31 '18 at 0:01
I read the article you posted and also did more research, but whether it's tabindex="0" or tabindex="-1" - if I click the link, nothing happens. If the target is a button, or link, or the like focus gets moved appropriately... but not if it's a div.
– TimB
Dec 31 '18 at 0:01
I read the article you posted and also did more research, but whether it's tabindex="0" or tabindex="-1" - if I click the link, nothing happens. If the target is a button, or link, or the like focus gets moved appropriately... but not if it's a div.
– TimB
Dec 31 '18 at 0:01
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53978096%2fbest-way-to-focus-element-of-any-kind%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
