I am using Firefox web developer tools to look at accessibility of our app, and it is reporting that none of our text fields or drop downs meet WCAG guidelines. The error reported is: "Clickable elements must be focusable and should have interactive semantics". Here is an example:
<TextField
autoFocus
fullWidth
required
id="username"
label="Username"
name="username"
onChange={handleChange('username')}
/>
According to MUI documentation, "If you are using the TextField component, you just have to provide a unique id...", which I am doing everywhere. I am new to the accessibility stuff - what am I missing??
Related
I'm using the ComboBox from the AjaxControlToolkit v4.1.50731. When it displays on the page, the dropdown list renders well below the origin of the control. Unfortunately, I can't post an image due to SO restrictions.
I kept the code to a minimum on the page to avoid any possible conflicts:
<AjaxToolKit:ComboBox ID="ComboBox1" runat="server">
<asp:ListItem Text="Mild" Value="0" />
<asp:ListItem Text="Medium" Value="1" />
<asp:ListItem Text="Hot" Value="2" />
</AjaxToolKit:ComboBox>
Any idea why this is happening or how it can be corrected?
The issue was caused by CSS styling but I couldn't isolate it the exact cause. To resolve the problem, I created a new page with no styling and only the combo box control, calling it "PlainComboBox.aspx". Then I used an iframe tag in the page where I wanted to display the combo box, as seen below:
<iframe src="PlainComboBox.aspx" frameborder="0" height="130" >
<p>Your browser does not support iframes.</p>
</iframe>
This isolated the combo box from any styling issues elsewhere on the page and rendered correctly.
When I'm focus on an input field on an iPhone, the Shift key is turned on to make sure that the input starts with upper case. Is there a way to turn off this functionality and not have the Shift key when I focus on a field?
I understand why this might be good in some cases but in my case this is a user name or email field, most of which don't start with upper case letter.
Update: The answer lead me to Safari Web Content Guide page which I'll be referencing more often from now on.
You can solve it by setting autocapitalize as off
<input type="text" name="test1" autocapitalize="off"/>
and also Set the autocorrect attribute of your textbox as off to turn off the auto correct feature.
<input type="text" name="test1" autocorrect="off"/>
There is a proprietary attribute for that: autocapitalize (on/off)
<input type="email" name="username" autocapitalize="off">
Please note that this is not a W3C standard and will result in invalid code.
I'm implementing my own autocompletion on an <input> field inside a UIWebView, and the built-in keyboard autocompletion interferes with the user experience. Is there a way to use HTML or Javascript to signal to iOS that it shouldn't try to autocomplete?
In my comments I mentioned using the html attribute autocomplete but I tested it, and it doesn't address your issue. However, there is an attribute specific to Mobile Safari which may help. You could try turning off autocorrect like so:
<input type="text" id="your-field" autocorrect="off" />
I've noticed navigating in websites like Dell or Google, that typing in their search text box with iPhone, in the keyboard appears a blue button 'Search' instead of the standard 'Go' button that appears on any normal form.
What should you do to display the search button?
having type="search" is usually all you need to make software Search keyboard appear however in iOS8 it is mandatory to have a wrapping form with action attribute.
So the following code would have a software keyboard with “Return” button
<form>
<input type="search" />
</form>
But this code should have blue “Search” button instead
<form action=".">
<input type="search" />
</form>
You can influence this behaviour with:
<input type="search" />
JS Bin demo
Ignore the submit button's text being 'kettle,' I just wanted to be sure that it wasn't the submit button influencing the text of the iOS keyboard...
This is, of course, backwards compatible since a browser that doesn't understand type="search" will default to type="text", which is useful for creating forward-planning html5 forms.
I was not able to get the search button with
<input type="search" />
However, I did get it to appear with
<form>
<input name="search" />
</form>
On iOS 8 you can enable the blue "Search"-button on the keyboard by doing one of:
add input name=search
add input type=search
add id to input with the case sensitive word "search" in the ID, for
example the-search or thesearchgod
In HTML5 standard, adding enterkeyhint attribute on the input is the proper way to change the label on the virtual keyboard
<input enterkeyhint="search" />
If no enterkeyhint attribute is provided, the user agent might use contextual information from the inputmode, type, or pattern attributes to display a suitable enter key label (or icon).
See MDN Docs about enterkeyhint
When using #Anton Bielousov suggested solution, this also changes the styling of Android Devices. To counter this I had to:
Add form around input.
Add type="search"
Add name containing search
Add styling to counter the unwanted android styling
Android styling:
input[type=search] { -webkit-appearance: none; }
/* clears the ‘X’ from Internet Explorer */
input[type=search]::-ms-clear { display: none; width : 0; height: 0; }
input[type=search]::-ms-reveal { display: none; width : 0; height: 0; }
/* clears the ‘X’ from Chrome */
input[type="search"]::-webkit-search-decoration,
input[type="search"]::-webkit-search-cancel-button,
input[type="search"]::-webkit-search-results-button,
input[type="search"]::-webkit-search-results-decoration { display: none; }
<form action="" class="search-bar__form-form">
<input
class="search-bar__input"
name="search-bar"
type="search"
/>
</form>
The keyboard is handled by the operating system (iOS) and cannot be directly altered. The type of input required determines the type of keyboard to display.
If the website in question is HTML5, then #David's answer is valid.
I've searched high & low for an answer on this and I can't seem to find an answer or anybody else having the same issue. Hope some one can assist?
I have a web page for signup which I'm viewing in an iPhone UIWebView. A user is asking if we can stop capitalization on the first letter of the email address being entered. I thought this didn't matter, but apparently it can for the local-part on some email systems (apparently it's only the domain that is only case insensitive).
It seems autocomplete is the culprit.
I've tried adding autocomplete="off" to the input element in the html, but iOS is obviously ignoring it:
Can auto-complete be turned off on a html input text field within a UIWebView?
Thanks
Add autocorrect="off" attribute to your input text field.
Seems like Apple have some documentation now:
Although the UIWebView class does not support the UITextInputTraits
protocol directly, you can configure some keyboard attributes for text
input elements. For example, you can include autocorrect and
auto-capitalization attributes in the definition of an input element
to specify the keyboard’s behaviors, as shown in the following
example.
<input type="text" size="30" autocorrect="off" autocapitalize="off">
You can also control which type of keyboard
is displayed when a user touches a text field in a web page. To
display a telephone keypad, an email keyboard, or a URL keyboard, use
the tel, email, or url keywords for the type attribute on an input
element, respectively. To display a numeric keyboard, set the value of
the pattern attribute to "[0-9]" or "\d".
These keywords and the pattern attribute are part of HTML 5, and are
available in iOS 3.1 and later. The following list shows how to
display each type of keyboard, including the standard keyboard.
Text: <input type="text"></input>
Telephone: <input type="tel"></input>
URL: <input type="url"></input>
Email: <input type="email"></input>
Zip code: <input type="text" pattern="[0-9]*"></input>
http://developer.apple.com/library/ios/#documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/KeyboardManagement/KeyboardManagement.html#Configuring the Keyboard for Web Views