Branching and Focus Behavior
November 4, 2021 12:00 AM
Hello Team!
On an advice from a kind Rockstar, I'm reposting this question in this area with hopes to find a solution for it. My title cannot pass 508 testing until this issue is resolved and I'm stuck! So any help is much much appreciated.
I've a list page that has 4 buttons (attached). Each button navigates to several pages, then the user returns back to the main list page. Visually the list and branched pages run well, but when users return to the list page, the focus goes to the very beginning of the page. So the AT users has to hear the same elements every time they come back to the list page. I can feel it, it's really "annoying"!
508 testers request that the focus would go to the next unselected button directly when the user returns back to the list page. I wonder if there's any resolution for this issue through Java Script. I'm not an expert in Java Script and would appreciate any advice.
Thank you.
Solution
Hello! Has anyone contacted you yet about your issue?
Discussion (4)
Hello! Has anyone contacted you yet about your issue?
You can add an on-click set variable for variable_onReturnSetFocusTo = button2, then on Page Show > Run JavaScript to set focus to the element (variable_onReturnSetFocusTo).
But I am a bit curious about the statement, “My title cannot pass 508 testing until this issue is resolved....508 testers request that the focus would go to the next unselected button directly when the user returns back to the list page.”
Passing 508 testing is a tricky thing as so much depends on the individual tester and their interpretation of the requirements. I think you are referencing WCAG 2.4.3:
- Focusable components need to receive focus in an order that preserves meaning and operability only when navigation sequences affect meaning and operability.
- In those cases where it is required, there may be more than one order that will preserve meaning and operability.
- If there is more than one order that preserves meaning and operability, only one of them needs to be provided.
I don’t see (nor have I experienced or heard of) why the focus would go to the next unselected button. Normally Focus Order is just the navigation order is logical and intuitive and moves to and returns from elements appropriately. Then Focus Visible is visually apparent which element has the current keyboard focus as you tab. Both needing the ability to skip over repetitive items and there shouldn’t be any keyboard “traps”.
I looked at the HHS site to verity their checklist and don’t see any reference to this either. I’m wondering if the testers are just meaning/thinking (or confused about) that the student shouldn’t have to start over again if they leave and come back.
So long story short, I think the tester is confused and if it were me, I would be wanting more clarification on why they are saying that. If this is something that came up after their internal review of what they students need, then I would argue back that we don’t do this for “abled” users either and they are asking for something beyond WCAG.
Hope this helps and sorry I couldn’t give you more/better info! Let me know if you have additional questions. ?
I would also encourage you to join the Lectora Accessibility User Group. We won’t meet again until January 2022 due to the upcoming US holidays, but we meet virtually on the last Thursday of the month January – October from 10:00-11:30 a.m. central time.) – www.thelaug.org
Hi Kristen,
Thanks for the follow-up, but no one has contacted me thus far. I'm still waiting for any help.
Thank you Chris for your detailed response. Could you please list the steps to achieve the results? I'm not a JS expert and I think I did it wrong. Many thanks again!