I'm working to make a page accessibility compliant. I have a few form elements that I can only reach once I click on an element in that form. If I load the page and hit tab, it cycles between a few links at the top of the page. If I click on one of the form elements, it gets focus, then I can tab to the other form elements. If I tab out of the form, I can't return with out clicking. Any idea what's going on here?
I would try to attach the attribute tabindex to the form inputs.
<input type="text" tabindex="3"></input>
http://www.w3schools.com/tags/att_global_tabindex.asp
Related
I have a requirement where I have an anchor tag in my HTML page.
<a aria-label="Back Button" class="secondary-button btn-font" title="Back" ngClass="btn-font"
ngClass.xl="btn-font-xl" i18n-title='importantFacts##back-button' id="backButton"
i18n="##importantFacts-back-button" routerLink="/apply-for-benefit/verification">
Back
</a>
My requirement is that JAWS 2022 read it as 'Back Button', but JAWS reads it as 'Back Button link'. I know it's an anchor tag and it is supposed to read it as a link, but is there a way where it can read it as just 'Back Button' ?
I have already tried using element and but it does not fulfil some other requirement. Only an anchor tag does. I have also tried giving 'role' value as 'button' to the anchor tag, but again with this other requirement was not getting fulfilled.
Kindly help.
Sounds like you already tried the correct solution - set the role.
<a role="button">Back</a>
You don't need an aria-label because the contents of your link already has the text to announce, "Back". And even if you wanted to have an aria-label, you should not specify the role in the label itself. That is, don't use aria-label="back button" but instead just use aria-label="back".
As a side note, links and buttons are quite different things. Links should be used for navigation purposes - going to a new page or navigating to a different location on the same page. Buttons should be used for "actions".
From a keyboard perspective, links only allow the enter key to select them whereas buttons allow both enter and space. If you press space on a link, it will scroll the page (the default behavior on most browsers is to scroll the page when you press space).
Also, if a screen reader user hears "link", not only will they assume they are being navigated somewhere but they will also expect the browser's "back" button to take them back to where they were previously. Buttons don't have that behavior.
So you really need to think about whether setting a role="button" on a link is the right thing to do instead of using a real <button>. If you do want to use role="button" on a link, then you'll also need a keyboard event handler to allow the space to work as explained above.
I'm trying to prevent autofocus that happens when I put md-button inside md-menu --> md-menu-content element.
On some of the pages inside "md-menu-content" there is a form with some md-input container elements, textArea, etc, and in the end, there is a "Submit" button (md-button).
When I come to this page there is always autofocus on the submit button even though I set a focus on the first drop-down element in the form.
On Firefox I'm even can't click on the input element (in my case email line) because the focus goes straight to the md-button.
Thanks in advance.
My product has an area where we want to display a default value (let's say the name of a document page), but when the user focuses on it and hits the space bar, it becomes an editable field. We are trying to write accessible code, and I was wondering if anyone had guidance about how to indicate to someone using a screen reader that this content is editable?
The way we are currently handling it in the code is to have a div with the name and when the user clicks (or focuses and hits space bar), it turns into an input. (They can hit enter or a button to save.) Are there ARIA values we could leverage for this or some other native solution?
Default:
<div>Page title <button>Click to edit page title</button></div>
When editing:
<input maxlength="500" value="Page title" />
We don't have a button to save right now. You hit enter or remove focus from the input, and it automatically updates.
The ARIA in HTML document defines "Element with contenteditable attribute" as having an implicit aria-readonly="false" attribute. This property is only available for some ARIA roles according to ARIA documentation and the textbox role is the more appropriate in your case. In this case no button is needed.
If your editable section does not contain HTML code (like links), it seems useless to use a contenteditable section and you should use instead standard input or textarea elements with appropriate CSS design, respectful of WCAG standards (i.e. Editable fields have to be distinguishable from text)
If your editable section does contain HTML code, then you would have to use a contenteditable atttribute. You have to identify the section as being a role=textbox element and it must be focusable with tabindex=0 attribute. This can be done on page load (without button), or after clicking a button outside the section (if you need, for instance, to be able to activate the inner links in normal reading context).
It seems Chrome doesn't register tabindex on radio button by default.
If you click on one of the radio button then push tab, chrome will focus the first link in the page.
If you click on another type of input element, he will continue in the form, as expected.
If you put tabindex everywhere, the form will mostly work as expected, except if you select (click on) a radio button, then tabbing will select the first form element.
How could I reproduce the same experience as in IE/FF?
I ran across this issue too. I figured out that if you gave each radio button it's own ~ name=unique ~ name=unique2 ~ name=unique3 that the tabindex would work.
Check out this website:
Form Trick: Set the Tabbing Order
You can see how he has different name values for all the radio buttons.
Hope that helped,
Diana
This is probally small question for a pro.
i want to know if i replace input submit button with button (type=submit), would it still be trigger on enter (keyboard) and if yes, then which browser wont trigger it?
<button type="submit"><span>i was replaced from input button</span></button>
span was added just for css fancy button style
It should be triggered in all standard compliant browsers, since type="submit" creates a submit button:
Buttons created with the BUTTON
element function just like buttons
created with the INPUT element, but
they offer richer rendering
possibilities:
same thing, the button allows you to put content, like text or images