Skip to main content

Home/ Web Accessibility/ Group items tagged fields

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Sandra Earl

Digital Web Magazine - Understanding Disabilities when Designing a Website - 0 views

www.digital-web.com/...ities_when_designing_a_website

accessibility design standards general development FUSION09

shared by Sandra Earl on 12 Oct 10 - Cached
  • In the UK In the US 2m people have a vision impairment3 10m people have a vision impairment4 8.2m people have mild to moderate deafness5, 688,000 people have severe to profound deafness6 28m people have a hearing impairment7 3.4m people have a physical disability8 8m people have a physical disability9 1.5m people have a learning disability10 6.8m people have a learning disability11 6m people have dyslexia12 25m people have dyslexia13
  • Most people who are blind will rely on screen reading software such as
  • JAWS or Windows-Eyes
  • ...41 more annotations...
  • refreshable Braille device which converts the text on the website into Braille.
  • Place form instructions before the form field
  • To improve accessibility and usability for screen reader users, form field requirements must be placed before the form field itself.
  • Provide a ‘skip to main content’ link Screen reader users benefit from a ‘skip to main content’ link as it enables them to jump over lengthy navigation to the main content of the web page, reducing the amount of content they have to listen to.
  • Ensure link text is descriptive Screen reader users using software such as JAWS can listen to the links on a web page through functionality known as a links list. If link text is not descriptive—solely using phrases such as “click here” or “more information”, for example—there is no way for screen reader users to determine where the link will take them.
  • Provide descriptive web page titles The first piece of information a screen reader user will listen to when they open a web page is the <title> assigned to the page. It is important, therefore, to use a title which reflects the content of the web page.
  • Provide descriptive headings It is important to provide descriptive headings
  • Screen reader users often listen to headings out of context from the main content
  • Provide audio descriptions and transcripts of video content Screen reader users depend on audio descriptions to provide additional information about important visual content displayed within a video.
  • Transcripts are written accounts of the video or audio content and can include additional information such as comments and descriptions
  • screen reader users cannot use a mouse
  • People with low vision will tend to use magnification software to make reading a website easier. Depending on the severity of their vision impairment, these users may combine magnification and screen reading software by using software products such as Supernova or ZoomText. For milder vision impairments, users may just increase the default size of text within their browser settings or change the colors to make the content more comfortable to read.
  • Avoid using images of text
  • Ensure text can be resized
  • Place key information in specific locations of the screen
  • ebsite search functionality is often located in the top-right corner of the web page
  • Juicy Studio color contrast analyzer.
  • it is possible to determine whether the colors chosen meet the minimum requirements specified in the WCAG Guidelines.
  • People with a hearing impairment tend not to use assistive software to improve their web browsing experience. Instead, they rely on the website being accessible by providing any audio content in alternative formats, such as captioning or transcripts.
  • By making audio content accessible for users with a hearing impairment, it also makes the content accessible for other users who find themselves in an environment where audio cannot be heard.
  • library with the sound turned down; they may be in a noisy environment where it is difficult to hear the audio; or they may be using a computer without speakers.
  • Provide captions for any video content
  • Provide transcripts of the spoken audio Where content is spoken without video, such as in a podcast, it is important to provide a transcript. It is recommended that the transcript be provided in plain accessible HTML to allow access by the widest possible audience, as opposed to a Microsoft Word or Adobe PDF document.
  • Physical disabilities range in severity from those who are temporarily disabled, for example having a broken arm, to those who are quadriplegic and have no use of any limbs. Depending on the severity of the physical disability, these users may access websites through voice recognition software such as Dragon Naturally Speaking.
  • However, what all users with a physical disability have in common is limited or no ability to use a mouse. This means that content within the website that requires a mouse click or fine motor control cannot be accessed by these users.
  • Ensure all content can be accessed via the keyboard
  • Users with a physical disability will have limited or no ability to use a mouse and as such will navigate websites using the keyboard.
  • Provide a focus state for links
  • Provide visible skip links Skip links are links that become visible when they receive focus, and are helpful for users with a physical disability. Keyboard users must tab through the web page to reach the particular link they are interested in—skip links allow lengthy navigation to be bypassed and reduce the number of key presses required to activate links in the main content.
  • Avoid moving targets Avoid using moving targets such as tickers, as users with a physical disability can find them very difficult to use.
  • Provide large clickable areas
  • provide sufficient whitespace between links
  • People with a cognitive or learning disability may have difficulties with memory, problem solving, perception, and conceptualization. In addition, people with a learning disability may have issues with reading and comprehension such as dyslexia.
  • To enhance the usability of the website for these users it is important that content is written in plain English, page layouts are simple in design, navigation is clear and consistent and there is no moving content to impede comprehension.
  • Provide the same look and feel throughout all pages of the website. Ensure that the navigation and main content are located in the same area of every page. Additionally, consider color coding different sections within the website. Users with cognitive or learning disabilities tend to find it easier to navigate around sections which are color coded.
  • Provide a site map A site map will enable users with a cognitive or learning disability to have a clear idea of the breadth of content contained within the website. The site map also enables users to directly access any page on the website, and helps if the user becomes lost.
  • Use a resizable sans-serif font which is left-aligned To increase readability for users with a cognitive or learning disability, use a sans-serif font which can be resized. Additionally, left-align content—justified text is more difficult to read due to the uneven spacing between words. Italicized and capitalized text should also be kept to a minimum to aid readability.
  • Provide helpful error messages
  • Offer speech output Organizations such as Browse Aloud and Textic enable content from a website to be spoken when highlighting the words on a web page. Offering this functionality is especially helpful for users who find it difficult to read large amounts of text.
  • Provide an Easy Read Version Consider providing an ‘easy read’ version of complex content. This combines plain text with images to aid understanding of the information. For an example of an easy read document see the Department of Health’s Making Lives Better for People with a Learning Disability.
  • Provide different color schemes People with cognitive or learning disabilities may benefit from different color scheme options. It is helpful if an easy read scheme such as a lemon background with dark text, and a hi-viz scheme such as a black background with yellow text, are provided.
Sandra Earl

Multiple form labels and screen readers | 456 Berea Street - 0 views

www.456bereastreet.com/...form_labels_and_screen_readers

accessibility forms labels JavaScript alerts

shared by Sandra Earl on 12 Oct 10 - Cached
  • Well, it turns out you can do that. From The LABEL element in the HTML 4.01 specification: The LABEL element may be used to attach information to controls. Each LABEL element is associated with exactly one form control. The for attribute associates a label with another control explicitly: the value of the for attribute must be the same as the value of the id attribute of the associated control element. More than one LABEL may be associated with the same control by creating multiple references via the for attribute. Sounds great, doesn’t it? A quick check in graphical web browsers shows that they associate multiple labels with the input field (as evidenced by the input field gaining focus when either label is clicked). But what about screen readers? It would be so useful if this would work… Unfortunately, and perhaps unsurprisingly, it looks like it doesn’t quite work as well as you’d hope. I mentioned this briefly in Use the label element to make your HTML forms accessible, but I think it’s worth bringing up again since full support for multiple labels would help us make forms more accessible to screen reader users while keeping visual designers happy. I am far from an expert user when it comes to screen readers, but I’ve done some limited testing with mostly disappointing results. Apple VoiceOver does not recognise more than one label element associated with a form control and reads only the label that comes first in the document’s source order. JAWS and Window-Eyes both do the opposite and read only the last label when an input field gains focus. The only screen reader of those that I tested that does handle multiple labels is Fire Vox. The exact results may obviously depend on user configuration and reading modes, and there may be other screen readers that get it right, but these results indicate that screen reader behaviour is too inconsistent for multiple labels to be a reliable technique.
Vernon Fowler

WebAIM: Blog - 10 Easy Accessibility Tips Anyone Can Use - 0 views

webaim.org/...10-easy-accessibility-tips

accessibility html css tips and tricks

shared by Vernon Fowler on 13 May 13 - No Cached
  • add the appropriate landmark role attribute (role="main", role="navigation", or role="search". If your site uses HTML5 <main> or <nav>, add the role to these elements.
  • Sighted keyboard users generally navigate through the links and form fields on a web page using the Tab and Shift+Tab keys on the keyboard. To help ensure they can visually identify which link or form field they have navigated to, you can add the following to your CSS file: a:focus { outline:1px solid red; background:yellow; } The colors may need to be customized to fit your site design, but they should be fairly distinctive. To take this tip one step further, you can search your CSS files for a:hover and in each instance change it to a:hover, a:focus. This will ensure that keyboard users get the same visual highlighting when they navigate to items as mouse users get when they hover over an item.
  • Vernon Fowler on 13 May 13
     
    "Today is Global Accessibility Awareness Day (GAAD). To celebrate and to help promote accessibility, here are 10 simple accessibility tips that most anyone can implement today into their web site's HTML and CSS to make it more accessible."
Vernon Fowler

WordPress › WP Accessibility Plugin « Make WordPress Accessible - 0 views

make.wordpress.org/...wp-accessibility-plugin

accessibility cms webdesign plugin WordPress checklist

shared by Vernon Fowler on 07 Jan 14 - No Cached
  • These title attributes have exactly the same value as the text of the link — if the text of the link is “Joe’s Blue Widgets”, then the title attribute is also “Joe’s Blue Widgets”. In the best case scenario, where a screen reader is set up to ignore title attributes, having this set makes little difference. In the worst case scenario, where a screen reader reads all attributes, it’s awful: the screen reader reads the title attribute and the link text, meaning that every link is, effectively, read twice.
  • Skiplinks provide a means to leap from the very top of a page to an alternate section of that page — one principle use being to leap over the main navigation to the main page content.
  • It does *not* remove it from other fields, because a common technique to grant keyboard focusability to normally non-focusable elements is to define a negative tabindex: this places the element into the focus sequence but does not force it into a particular place in that sequence.
  • ...5 more annotations...
  • Removing those attributes usually makes keyboard navigation much more linear and predictable. The intention behind tabindex was to create a logical tab sequence when it would otherwise have been unnatural; but in practice, that required absolutely insane degrees of maintenance to use in a real-life web site.
  • Links opened in new windows can break web site flow (creating a change of context) and disorient users who don’t realize they’ve moved to a new window. Also, it takes away the option of opening in the same window/tab
  • Remove title attribute from inserted post images/featured images
  • for accessibility, all links should make sense without requiring context, to grant screen readers the ability to scan the page and have information. This plug-in adds the title of the post into this pattern
  • Many designs do not provide a design for the view of links or other focusable fields when a keyboard user brings focus to that element. This makes it very difficult for visual users who are keyboard dependent to keep track of where they are. A common pattern for this is to change the appearance of the element on keyboard focus; and this item adds an outline.
Sandra Earl

WebAIM: Screen Reader Survey Results - 0 views

webaim.org/...screenreadersurvey

accessibility vision blindness screen reader WebAIM general FUSION09

shared by Sandra Earl on 12 Oct 10 - Cached
  • We received 1121 valid responses to the screen reader survey, which was conducted Dec. 2008 - Jan. 2009.
  • Skip to content22% Skip to main content28%
  • 33 respondents (2.9%) reported being both deaf and blind.
  • ...33 more annotations...
  • Please rate your computer proficiency Response% of Respondents Expert22% Advanced44% Intermediate27% Beginner8%
  • Please rate your screen reader proficiency Response% of Respondents Expert17% Advanced41% Intermediate32% Beginner9%
  • Screen Reader Usage
  • Of the 1121 respondents, 74% use JAWS, 23% use Window-Eyes, 8% use NVDA, and 6% use VoiceOver. While several other screen readers were reported, these were the most prominently reported. Individual versions of screen readers are not yet computed, but generally the majority of users are using the most up-to-date version of their screen reader.
  • How soon do you update your screen reader after a new version is released? Upgrade Window% of Respondents Immediately41% First 6 months25% 6-12 months9% 1-2 years9% 2-3 years4% 3+ years6% No response6%
  • How customized are your screen reader settings? (e.g., changed verbosity, installed scripts, etc.) Response% of Respondents A lot29% Somewhat40% Slightly21% Not at all7% No response4%
  • a lot or some customization was reported by only 27.6% of respondents with no disability versus 71.4% for those that reported blindness.
  • 78% of respondents reported using a screen reader on a desktop computer, 54% use a screen reader on a laptop, and 12% use a screen reader on a mobile phone.
  • No respondents who use screen readers for evaluation reported using a screen reader on a mobile device.
  • Which web browser(s) do you currently use with a screen reader? Browser% of Respondents IE633% IE768% IE82% Firefox39% Safari6%
  • Respondents with no disability were nearly twice as likely to list Firefox as blind respondents - 66% to 37%.
  • The percentage of Safari users is over double that of the overall population - this may be due in part to the fact that some in the Mac community actively solicited survey participation and encouraged respondents to indicate their Safari use, perhaps partially due to feeling snubbed because we didn't list them with IE and Firefox as direct choices.
  • When first accessing a new, unfamiliar home page, I'm most likely to... Response% of Respondents Read through the home page46% Navigate through or listen to the links on the page35% Use the Search to find what I'm looking for13% Look for a site map or site index3% No Response2%
  • Interestingly, the more proficient screen reader users are more likely to read through the home page and use links less often than less proficient screen reader users. This may be due to faster reading speeds for more experienced users. The home page strategies used were very similar regardless of proficiency, disability, or amount of screen reader use.
  • I use "skip to content" or "skip navigation" links... Response% of Respondents Whenever they're available22% Often16% Sometimes28% Seldom19% Never10% No Response4%
  • Some questions were of a technical nature and we understand that many participants may not have been very technically savvy. Responses may also be based upon user experiences with web content that is generally inaccessible. We cannot help but wonder if responses may have been different if screen reader interactions with web content were typically very positive.
  • I use Access keys... Response% of Respondents Whenever they're available22% Often16% Sometimes28% Seldom19% Never10%
  • I navigate by headings... Response% of Respondents Whenever they're available52% Often24%
  • 76% always or often navigating by headings when they are available.
  • I use site search functionality... Response% of Respondents Whenever it's available26% Often25% Sometimes31%
  • Find the word "Search"18% Jump to the first text/edit field on the page25%
  • Jump to the first form element in a page36%
  • Proficient screen reader users were more than twice as likely to jump directly to the form or text/edit field than less proficient users. Less proficient users were nearly three times more likely to use more manual methods (reading, tabbing, or finding) than more proficient users.
  • a majority of respondents seldom or never use site maps. There was no marked difference in the use of site maps across screen reader proficiency or disability. In general, it appears that site maps may be beneficial, but are not commonly accessed by screen reader users.
  • Text-only versions are always used by many and never used by many. As such, it is very difficult to interpret the value they have for screen reader users. More proficient screen reader users were much less likely to use text-only versions than less proficient users. This may suggest that proficient users employ sufficient techniques to render the main version acceptable to them. Or, it may suggest that proficient users do not gain value in using text-only versions, which are often less than optimal.
  • If content is identified as being "for screen reader users", how often do you use it? Response% of Respondents Whenever it's available38% Often15% Sometimes25% Seldom13%
  • A closer analysis, however, reveals that pop-up windows are reported as very difficult twice as often by less proficient screen reader users than with higher proficiency. Alternatively, more proficient users were three times more likely to indicate that pop-up windows are not at all difficult. This shows that less proficient screen reader users (which represent 41% of respondents) have more difficult experiences with pop-up windows.
  • Firefox users were much more likely to give a favorable response, perhaps a reflection of Firefox support for ARIA, etc. Evaluators and those without disabilities were nearly twice as likely to indicate that these applications are not very or not at all accessible than those that always use screen readers or have disabilities. This may suggest that these applications are actually more accessible than evaluators believe them to be, or alternatively, that screen reader users with disabilities are less knowledgeable about the true inaccessibility of these technologies.
  • 66% of evaluators preferred that the image be ignored, compared to only 28% of those that always user a screen reader. Similarly, 65% of those with no disability preferred that the image be ignored, compared to 29% of those with disabilities.
  • If a web page contains a photo of the White House, I prefer that the image be identified as... Response% of Respondents Photo of the White House80%
  • 69.4% of evaluators found them difficult compared to only 42.6% of those that always use a screen reader. Those with higher screen reader proficiency naturally found these links easier.
  • 71.5% of screen reader users reported that Flash is difficult
  • While the majority (58%) of users reported that frames are easy, those that are blind were 3 1/2 times more likely to indicate that they are easy than those with no disability. Similarly, those that always use a screen reader reported frames as easy nearly 3 times more often than evaluators. This perhaps suggests a misconception among those that do not have disabilities that frames are very inaccessible when in fact those with disabilities find them easy.
Vernon Fowler

Places It's Tempting To Use Display: None; But Don't | CSS-Tricks - 0 views

css-tricks.com/g-to-use-display-none-but-dont

webdesign accessibility usability screen reader reading

shared by Vernon Fowler on 07 Oct 12 - No Cached
  • I recently heard a heartbreaking story about a blind girl trying to apply for college and the form had missing labels so she had no idea what to put in what fields.
  • @media queries Turning on Voice Over in OS X and using Safari is a screen reader. Now imagine that Safari window was open to a very narrow width and the page had some @media queries for handling smaller viewports. And say that @media query hides some things with display: none in order to better visually accomodate the space. This could be good or bad for accessibility. Are you hiding a bunch of crap that isn't important to the page? Or are you hiding useful things that a person using a screen reader should have access to like they normally would.
Vernon Fowler

WebAIM: Creating Accessible Forms - General Form Accessibility - 0 views

webaim.org/forms

forms accessibility form labels fields general

shared by Vernon Fowler on 03 Feb 14 - No Cached
  • Screen reader users generally navigate through a form using the Tab key to jump from form control to form control. Associated form labels are read for each form control when the user navigates to them. Any non-label text content between the form controls is usually skipped over. Be sure to include important cues or instructions in associated labels or at the beginning of the form.
Sandra Earl

Designing and Developing mobile web sites in the real world, part 2 - Opera Developer C... - 0 views

dev.opera.com/...d-developing-mobile-web-site-1

accessibility mobile opera best practices reading

shared by Sandra Earl on 12 Oct 10 - Cached
  • In tandem with the launch of their 3G mobile website, Siminn also launched a slightly lighter version of the same site - a 2G-optimized mobile presence to serve less powerful phones. Both sites are anchored to the same reservoir of information, but the 3G site makes less-restricted use of CSS, images, and other coding ornamentations.
  • The only distinction Siminn makes concerning the dimensionality of the user-experience is whether the device is 2G or 3G enabled. As stated before, 2G devices are sent to a slightly lighter version of the 3G site
  • This is exactly what Siminn are doing. By detecting the type of phone, they are presenting the customer with the most appropriate version of the page – either the 3G enhanced or the more basic design.
  • ...19 more annotations...
  • e chose not to try and replicate the entire Icelandair website, but rather to cleave from it four or five of its most crucial elements.
  • This page contains the only form on the mobile site. In general, forms should be avoided because form input via a mobile device can be a tricky endeavor. However, there are certain coding practices that can simplify form input. For example, if your form field should only accept numeric input, then you should make use of the -wap-input-format property of WAP CSS. The Apple iPhone will automatically set the input to numeric if the name of the input element is set to certain values - phone or zip for example.
  • Mobile users only need to be shown news items that have some inherent urgency.
  • Much like your desktop browser recognizes a mailto: link as an email address, mobile devices recognize tel: links and phone numbers.
  • Do not assume that just because the UA string is not in your enumerated list of “Accepted strings”, it is not possible to view the site.
  • This is where you build in progressive enhancements to the website experience.
  • WURFL is an open source list of known phones and their capabilities. This can be put into a database and when a mobile device visits the your site you can sniff the UA, look-up the capabilities of that device (including screen-dimensions, default browser, etc) and serve them the best possible experience.
  • The RDF vocabulary is a standard across many mobile devices. Vendors that use this approach allow mobile sites to keep up-to-date with any new devices, without having to keep their own database of device types.
  • ou can find more details about standards support in Opera Mini/Mobile 4 here: Designing with Opera Mini 4 in mind JavaScript support in Opera Mini 4
  • There are a few basic coding items to avoid in the mobile web space. Chief among these, at least for now (now being 10/2007), is client-side scripting.
  • While it's tempting to try and port that elegant bit of AJAX from your conventional web to your mobile web, you will only create headaches for yourself.
  • ome browsers do support various levels of JavaScript, but as a developer you should not expect it to work across all devices.
  • retty heavy processor hog, so continuous scripting can drain a battery fast
  • mobile browser support for stylesheets varies greatly.
  • keep things simple.
  • most mobile devices default to their own font sizes and families regardless of styling. Thus, when working on the Siminn project we made no attempt to influence font size or family. In cases where we wanted a larger font, we simply relied on the generic XHTML heading elements.
  • he inclusion of font-size=smaller in the body tag worked as a kind of global reset for font sizes in every device we tested. With this little bit of code we were able to sufficiently reduce the default font size and thus more faithfully reproduce the design that we had been tasked with coding.
  • XHTML-MP - the mobile web subset of XHTML - is fully supported on most modern devices.
  • You can't read 2 books and several articles about mobile web development and cover everything. Much of the effort is trial and error. When starting out, emulators are a good way to get a rough idea of how the site will work. It gives you some feel for the navigation, architecture and flow of the site, but the look and feel varies from the emulator to the real device. The best thing you can do is get a few real phones to test on. I'm sure between yourself, co-workers and a few friends, you can manage to test your site on a good cross-section of the phones out there. Finally, there is some help. The W3C mobile web initiative does have a checklist to see how well your site is doing and so does dev.mobi - if you take heed of these two lists, your site should give a quality experience to most customers.
Sandra Earl

Captivate Accessibility Hints | SSB BART Group - 0 views

www.ssbbartgroup.com/...captivate-accessibility-hints

accessibility tips and tricks captivate elearning general content creation

shared by Sandra Earl on 12 Oct 10 - No Cached
  • Captivate has a number of accessibility features in version 3 and 4 although there are some issues that Adobe is working on.
  • Ensure that the “enable accessibility” checkbox is checked under the File > Publish settings in order for accessibility to be exposed to assistive technologies.
  • Slide Accessibility Text Each slide can contain accessibility text. This can be added by going to the slide properties, activating the Accessibility button and entering text in the text field.
  • ...6 more annotations...
  • Closed Captioning Closed captioning can be added to all audio files. From the record audio dialog, closed caption text can be added under the Caption tab. The playback bar contains a CC button which allows the closed captioning to be displayed or hidden.
  • Button Accessibility Text buttons can be made accessible. The text that appears on-screen becomes the button’s accessible name. To make the buttons keyboard accessible, the “Set Keystroke: Select Keys” button should be used and the keystroke of “enter” should be set in the object’s properties dialog. Other shortcuts can be assigned but enter/space will then not work to activate the button after tabbing to it. The keystroke of “enter” can be assigned to multiple buttons and the button with focus will be activated when Enter is pressed.
  • Audio recordings can be associated with click boxes and thus authors can associate descriptive text to be announced when a shortcut keystroke is pressed to assist users with visual impairments.
  • Text from PowerPoint Much of the text from PowerPoint will come through as text in Microsoft Active Accessibility (MSAA) and will be exposed to users of screen readers. Currently there isn’t a method to change the order or edit this text.
  • Quiz Questions There is some accessibility support for quiz questions. Simple types of questions such as true and false and multiple choice provide accessible names for the radio buttons and the text of the question appears as text in the accessible MSAA structure and is exposed to screen readers.
  • Accessibility Differences Between Captivate 3 and 4 The text in the “text caption” object does not show up as accessible text in Captivate 3 but does in Captivate 4. In addition, it is not possible to set accessible text for specific images in Captivate 3 but it is possible in Captivate 4.
shalani mujer

Gain Computer Help Fast Today - 2 views

I usually depend on wireless internet access. Everywhere I go my laptop is always with me so I can use the internet everywhere and anytime. However, there was a time when my laptop got infected by ...

computer help

started by shalani mujer on 06 Oct 11 no follow-up yet
Vernon Fowler

Bruce Lawson's personal site  : The practical value of semantic HTML - 0 views

www.brucelawson.co.uk/...actical-value-of-semantic-html

accessibility html mobile navigation

shared by Vernon Fowler on 25 Feb 19 - No Cached
  • styles each header element differently depending on the value of its itemprop attribute. Using itemprop, we’re able to ensure that the author, publication date, title, and subheading are prominently featured.
  • If you plan to put things into microdata, please note that Apple, being Apple, go their own way, and don’t use a schema.org vocabulary here. Le sigh. See my article Content needs a publication date! for more. Or view source on this page to see how I’m using microdata on this article.
  • Apple WatchOS also optimises display of items wrapped in <figure> elements
  • ...4 more annotations...
  • First, choose the appropriate type attribute and element tag for your form controls. WebKit supports a variety of form control types including passwords, numeric and telephone fields, date, time, and select menus. Choosing the most relevant type attribute allows WebKit to present the most appropriate interface to handle user input.
  • unlike iOS and macOS, input methods on watchOS require full-screen interaction. Label your form controls or specify aria label or placeholder attributes to provide additional context in the status bar when a full-screen input view is presented.
  • By choosing the right semantics now, a machine that I don’t know about yet can understand my content and display it in the best way for its users.
  • Semantic HTML will give usability benefits to many users, help to future-proof your work, potentially boost your search engine results, and help people with disabilities use your site.
Vernon Fowler

Quick Fix: Disable or Tweak Autocorrect, Autocapitalize, and Autocomplete - UXcellence - 0 views

uxcellence.com/...tweaking-automatic-form-input

shared by Vernon Fowler on 18 Sep 19 - No Cached
  • Autocorrect is on by default.
    • Vernon Fowler
      Vernon Fowler on 18 Sep 19
       
      Should we be turning autocorrect off for most forms using ?
  • Or an entire form like this:
  • Any field that expects a proper name (such as first, last, or city name) can also be problematic with autocorrect enabled.
1 - 13 of 13
Showing 20▼ items per page