Skip to main content

Home/ Web Accessibility/ Group items tagged keyboard

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Vernon Fowler

WebAIM: Keyboard Accessibility - 0 views

webaim.org/keyboard

accessibility testing keyboard

shared by Vernon Fowler on 02 Jun 17 - No Cached
  • Long lists of links or other navigable items may pose a burden for keyboard-only users.
  • The following best practices can facilitate efficient keyboard navigation: Provide a "skip to main content" link on the page. Use a proper heading structure. Provide ARIA landmarks or HTML5 structural elements (<main>, <nav>, etc.)
  • Vernon Fowler on 02 Jun 17
     
    "when testing with a keyboard, you are not just trying to interact with the page successfully, you also want to ensure all interactions are predictable. This requires an understanding of common keyboard interactions."
Vernon Fowler

WebAIM: Keyboard Accessibility - Tabindex - 0 views

webaim.org/...tabindex

DIG252 keyboard accessibility navigation focus html

shared by Vernon Fowler on 20 Aug 14 - No Cached
  • tabindex="0" and tabindex="-1" have special meaning and provide distinct functionality in HTML. A value of 0 indicates that the element should be placed in the default navigation order. This allows elements that are not natively focusable (such as <div>, <span>, and <p>) to receive keyboard focus. Of course one should generally use links and form controls for all interactive elements, but this does allow other elements to be focusable and trigger interaction.
  • A value of 0 indicates that the element should be placed in the default navigation order. This allows elements that are not natively focusable (such as <div>, <span>, and <p>) to receive keyboard focus.
  • A tabindex="-1" value removes the element from the default navigation flow (i.e., a user cannot tab to it), but it allows it to receive programmatic focus, meaning focus can be set to it from a link or with scripting. This can be very useful for elements that should not be tabbed to, but that may need to have focus set to them. A good example is a modal dialog window - when opened, focus should be set to the dialog so a screen reader will begin reading and the keyboard will begin navigating within the dialog. Because the dialog (probably just a <div> element) is not focusable by default, assigning it tabindex="-1" allows focus to be set to it with scripting when it is presented.
  • ...1 more annotation...
  • A value of -1 can also be useful in complex widgets and menus that utilize arrow keys or other shortcut keys to ensure that only one element within the widget is navigable with the tab key, but still allow focus to be set on other components within the widget.
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.
Vernon Fowler

Understanding Success Criterion 2.4.7: Focus Visible - 0 views

www.w3.org/...focus-visible.html

accessibility focus

shared by Vernon Fowler on 01 Oct 19 - No Cached
  • Vernon Fowler on 01 Oct 19
     
    "Success Criterion 2.4.7 Focus Visible (Level AA): Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible."
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."
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

Unobtrusive and keyboard accessible connected select boxes | 456 Berea Street - 0 views

www.456bereastreet.com/...essible_connected_select_boxes

accessibility multiple select elements

shared by Sandra Earl on 12 Oct 10 - Cached
  • Any web developer who has created a reasonably complex form is probably aware of the concept of multiple select elements that are connected – choosing something from one select box either makes a new select box appear or changes the options of one that is already visible. There are usually two problems with this approach. One is that most implementations are completely dependent on JavaScript being available. Often there either is no submit button at all, or there is a submit button but without JavaScript there is no way to access the options that appear only as a result of changing the first select box. The other problem is that in some browsers, using the cursor keys to change the selected option triggers the onchange event immediately, so you can never get past the first option unless you know how to use your keyboard to display all options. I normally work around these problems by requiring users to submit the form to get the next set of options from the server. Obviously that isn’t an ideal solution either. So what other options do we have? One option that looks promising is described by Christian Heilmann in Unobtrusive connected select boxes - yet another solution approach. It involves using optgroup elements to create a two-level select box, which is then split into two separate select boxes if JavaScript is available. Neat. The solution Chris describes solves (or at least mitigates) the keyboard access problem since it doesn’t reload the page when the onchange event is triggered. And if JavaScript is unavailable, there is a single select box with option groups. The catch is that nested optgroup elements are not allowed in current versions of HTML, so this will not work when more than two connected select boxes are needed. Nested optgroup elements are allowed in the current Web Forms 2.0 Working Draft, so I guess there is a reasonable chance of that change making it into HTML 5.
Sandra Earl

WebAIM: Accessibility of Rich Internet Applications - 0 views

webaim.org/aria

accessibility ARIA WebAIM

shared by Sandra Earl on 12 Oct 10 - Cached
  • WAI-ARIA (Accessible Rich Internet Applications or ARIA) is a W3C protocol for enhancing and supporting accessibility of scripted and dynamic content.
  • ARIA provides accessible interactive controls (such as tree menus, drag and drop, sliders, sort controls, etc.), content roles for identifying page structure (navigation, search, main content, etc.), areas that can be dynamically updated (called "live regions" in ARIA), better support for keyboard accessibility and interactivity, and much more.
  • WAI-ARIA provides the ability for developers to specify roles for document areas (and many other things).
  • ...2 more annotations...
  • accessibility issues with rich internet applications can be characterized as: Providing the semantic structure of page areas and functionality (e.g., navigation, main content, search, etc.) Maintaining accessibility of content that is dynamic and may change within the page (e.g., AJAX content updates) Allowing certain non-focusable page elements to receive keyboard focus (e.g., setting focus to an error message within the page) Providing keyboard and screen reader accessibility with complex widgets and navigation elements (e.g., sliders, menu trees, etc.)
  • ARIA is being implemented into many scripting libraries (such as jQuery, Dojo, YUI, and GWT). While developers can certainly implement ARIA into their advanced widgets and applications, using ARIA-supported libraries greatly simplifies the process of providing this level of accessibility.
Vernon Fowler

Examples of 'skip links' on some bank sites | The Paciello Group Blog - 0 views

www.paciellogroup.com/...-skip-links-on-some-bank-sites

accessibility skip links examples webdesign

shared by Vernon Fowler on 24 Nov 12 - No Cached
  • Currently browsers do not support keyboard navigation via landmark roles, so for keyboard users who do not also use assistive tech, a visible skip link is needed.
Vernon Fowler

NV Access - 0 views

www.nvaccess.org

testing tool accessibility NVDA software screenreader screen reader free

shared by Vernon Fowler on 16 Mar 14 - No Cached
  • Vernon Fowler on 16 Mar 14
     
    "NVDA (NonVisual Desktop Access) is a free "screen reader" which enables blind and vision impaired people to use computers. It reads the text on the screen in a computerised voice. You can control what is read to you by moving the cursor to the relevant area of text with a mouse or the arrows on your keyboard."
Sandra Earl

How did you get into Web accessibility? | 456 Berea Street - 0 views

www.456bereastreet.com/...you_get_into_web_accessibility

accessibility reflection testimonial

shared by Sandra Earl on 12 Oct 10 - Cached
  • Personally I have several reasons for advocating Web accessibility. First of all an idealistic one: I want everybody to be able to use the Web. I am not disabled (yet), so I can (and am often forced to) muddle through sites that are badly built, but a person with a disability may not be able to. Since it is possible to build sites that almost everybody can use, I don’t see why we shouldn’t. Then a few reasons that some may call selfish: I do not have any problems related to motor skills, but I have a really hard time using dropdown and flyout menus, especially hierarchical ones, as well as phony Flash or JavaScript scrollbar imitations. Accessible sites in general either do not contain such obstacles or provide ways around them. Despite having no substantial eyesight problems, I find reading tiny text (below 11px is tiny to me), low contrast text, and reading any size high contrast, light-on-dark text to be very straining. A website designed with accessibility in mind is less likely to cause legibility problems for me. I like being able to use my keyboard to navigate websites. Accessible sites are keyboard friendly since they do not force people to use a mouse.
Vernon Fowler

Don't Use The Placeholder Attribute - Smashing Magazine - 0 views

www.smashingmagazine.com/...placeholder-attribute

inclusive input formdesign aria forms inclusivedesign hint accessibility form html

shared by Vernon Fowler on 27 Jun 18 - No Cached
  • To recap, the placeholder attribute: Can’t be automatically translated; Is oftentimes used in place of a label, locking out assistive technology; Can hide important information when content is entered; Can be too light-colored to be legible; Has limited styling options; May look like pre-filled information and be skipped over.
  • Move the placeholder content above the input, but below the label:
  • Development Here’s how to translate our designed example to code:
  • ...4 more annotations...
  • aria-describedby ensures that the p content will be described last, after the label’s content and the kind of input it is associated with.
  • By using aria-describedby to programmatically associate the input with the p element, we are creating a priority of information for screen readers that has parity with what a person browsing without a screen reader would experience.
  • The floating label effect, a close cousin to this phenomenon, oftentimes utilizes the placeholder attribute in place of a label, as well.
  • Content hidden by an on-screen keyboard. 3rd party keyboards with larger heights may have a greater risk of blocking important content.
  • Vernon Fowler on 27 Jun 18
     
    Not only argues for not using the placeholder attribute but also describes an inclusive input hint and how to code it.
Vernon Fowler

Customise radio buttons without compromising accessibility - 0 views

www.chenhuijing.com/...out-compromising-accessibility

accessibility webdesign input buttons inclusivedesign

shared by Vernon Fowler on 16 Sep 18 - No Cached
  • go with option 3, a good ole’ opacity: 0 coupled with a position: absolute. Hidden but still focusable, well-supported across browsers. Just what we’re looking for.
  • opacity: 0
  • the label has to come after the input element in the source order
  • ...1 more annotation...
  • sad state of affairs when it comes to browser support for clip-path.
  • Vernon Fowler on 16 Sep 18
     
    "Customised radio buttons and checkboxes are a common design pattern found on the web, and it doesn't take too much to ensure that your beautifully designed toggles are still navigable via keyboard."
Vernon Fowler

Don't Rely on Default Browser Error Messages - Intopia - 0 views

intopia.digital/...default-browser-error-messages

accessibility forms validation HTML5

shared by Vernon Fowler on 06 Feb 19 - No Cached
  • Another issue is that the messages are temporary. As soon as you put focus on the input with mouse, keyboard or touch, the message disappears. People with cognitive impairments will find it difficult to use these, and I think anyone trying to fill in the form while they’re distracted will have trouble as well. People who rely on the keyboard for navigation (which includes both sighted users and screen reader users) will also lose these messages as they move around the form.
  • If you’re confident of your error messages, you can remove the browser validation by adding the novalidate attribute to the wrapping form element, like this: <form novalidate>...</form>
  • You can style this with CSS, using the :valid and :invalid pseudo-classes
  • ...2 more annotations...
  • Only the first error is noted with a message.
  • The rest rely on a change of border colour, which is, again, not evident to screen reader users.
  • Vernon Fowler on 06 Feb 19
     
    "When I found out the major browsers were beginning to include error validation into their support for forms, I was pretty excited. Form validation is always a fiddly part of accessibility, so I'm always looking out for ways to make it easier for developers to do properly. I read MDN's form data validation tutorial and a CSS Tricks article on client-side form validation and immediately made some test forms. Sadly, I was disappointed with the results. The default error validation in browsers is almost completely inaccessible. I was hoping we'd get default "you've forgotten to fill this in" messages that could be customised. I might have been a bit too optimistic! Validation at the browser level has many of the same issues we find at the website level."
Vernon Fowler

html5-boilerplate/css/main.css at master · h5bp/html5-boilerplate · GitHub - 0 views

github.com/...main.css

css html5 boilerplate screen reader reading usability webdesign accessibility

shared by Vernon Fowler on 07 Oct 12 - No Cached
  • /* * Hide from both screenreaders and browsers: h5bp.com/u */.hidden {    display: none !important;    visibility: hidden;}/* * Hide only visually, but have it available for screenreaders: h5bp.com/v */.visuallyhidden {    border: 0;    clip: rect(0 0 0 0);    height: 1px;    margin: -1px;    overflow: hidden;    padding: 0;    position: absolute;    width: 1px;}/* * Extends the .visuallyhidden class to allow the element to be focusable * when navigated to via the keyboard: h5bp.com/p */.visuallyhidden.focusable:active,.visuallyhidden.focusable:focus {    clip: auto;    height: auto;    margin: 0;    overflow: visible;    position: static;    width: auto;}/* * Hide visually and from screenreaders, but maintain layout */.invisible {    visibility: hidden;}
Vernon Fowler

WebAIM: "Skip Navigation" Links - 0 views

webaim.org/skipnav

skip navigation links accessibility

shared by Vernon Fowler on 20 Jan 14 - No Cached
  • In most cases, this is not necessary. Remember, the purpose of "skip navigation" links is to reduce the clutter of lists of links. Adding more links increases link-clutter.
1 - 20 of 32 Next ›
Showing 20▼ items per page