Skip to main content

Home/ Web Accessibility/ Group items tagged focus

Rss Feed Group items tagged

Vernon Fowler

WebAIM: Keyboard Accessibility - Tabindex - 0 views

  • 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

Understanding Success Criterion 2.4.7: Focus Visible - 0 views

  •  
    "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: Usable and Accessible Form Validation and Error Recovery - 0 views

  • Errors on top
  • As one would guess, the "Errors on top" approach causes the error message to appear before the form. When presented, focus should generally be set directly to this error message. This allows screen reader and keyboard users to immediately access the error message without having to find it amongst the rest of the page contents. The message should also be visually apparent. Focus can be set to the message with client-side scripting using JavaScript focus() or similar, or the server-generated page can include an anchor name in the URI (e.g., http://myserver.com/form.php#errormessage) which will set focus directly to a named anchor or element id located at the beginning of the feedback message.
  • also helpful to inform the user as to the number of errors that were detected
  • ...2 more annotations...
  • provide a link within the error message that will set focus to the appropriate form control
  • Regardless of the mechanism used to identify and recover from form errors, aria-invalid="true" should generally be set on each invalid form control. This attribute causes screen readers to identify the control as being "invalid" or in need of attention.
Vernon Fowler

Inclusively Hidden | scottohara.me - 0 views

  • sometimes content is for decorative purposes only, and it would be optimal to not announce this content to assistive technology.
  • don’t use aria-hidden on focusable content
  • Purposefully Hidden from Assistive Technology
  • ...1 more annotation...
  • using aria-hidden to hide content specifically from screen readers
  •  
    There are various techniques to visually hide content in our web interfaces, but are you aware of the different effects they have on the accessibility of that content? While it would be nice if there was a single, native, solution for hiding content, there are contextual benefits to the various techniques at our disposal. Since there have been many articles already written about these techniques, over the many years they've been in use, the focus of this article will be to highlight the ones that are most appropriate for modern web development. We won't just look at the code behind each of these techniques, instead we'll focus on why each technique has its place, using practical examples to demonstrate their purposes. But before we talk about how to hide content we should ask ourselves a question… Why are we hiding content?
Vernon Fowler

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

  • 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 screen reader interaction modes - Tink - 0 views

  • the screen reader intercepts most keypresses before they reach the browser, triggering an interaction with the virtual document instead
  • up/down keys move focus to the previous/next line instead of scrolling the page
  • space key to select a checkbox
  • ...3 more annotations...
  • enter key is used to activate a link
  • Not all keypresses are captured by the screen reader however. When the tab key is pressed it is automatically passed through to the browser where it causes keyboard focus to move to the next piece of interactive content
  • Although this mode switching may seem unintuitive to someone unused to Windows screen readers, it works well in practice and most screen reader users are unaware of what’s happening “under the hood”.
Sandra Earl

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

  • 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

  • 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.
Sandra Earl

WebAIM: Accessibility of Rich Internet Applications - 0 views

  • 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

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

  • /* * 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

A List Apart: Articles: Now You See Me - 0 views

  • visibility: hidden; Element is hidden from view, but is not removed from the normal flow (i.e., it still takes up the space it normally would) Content is ignored by screen readers display: none; Element is removed from the normal flow and hidden; the space it occupied is collapsed Content is ignored by screen readers height: 0; width: 0; overflow: hidden; Element is collapsed and contents are hidden Content is ignored by screen readers
  • if you want to ensure users have access to content (even if it isn’t displayed visually in the current interface), the final option (positioning content offscreen) is really the way to go.
  • Screen readers have access to the content
  • ...6 more annotations...
  • position: absolute; left: -999em;
  • but links may “focus” oddly and negative indent may not prove long enough to fully hide content
  • limited to text and inline elements
  • Content is removed from the normal flow and shifted off the left-hand edge; the space it occupied is collapsed
    • Vernon Fowler
       
      This is usually my desired effect.
  • If you don’t want your hidden content to be read by a screen reader, those defaults may work for you
  • how profoundly your choice of hiding mechanism can influence the accessibility of your content to assistive technologies like screen readers
Vernon Fowler

Accessible forms using WCAG 2.0 | Web Usability - 0 views

  • The label element is not used for the following because labels for these elements are provided via the value attribute
  • This technique inserts new content into the DOM immediately following the element that was activated to trigger the script. The triggering element must be a link or a button, and the script must be called from its onclick event. These elements are natively focusable, and their onclick event is device independent. Focus remains on the activated element and the new content, inserted after it, becomes the next thing in both the tab order and screen-reader reading order. Note that this technique works for synchronous updates. For asynchronous updates (sometimes called AJAX), an additional technique is needed to inform the assistive technology that the asynchronous content has been inserted.
Sandra Earl

Web Axe - Practical Web Design Accessibility Tips - Podcast and Blog: Fieldsets, Legend... - 0 views

  • Some tips from the article include:Fieldset and Legend tags must be used together, never independently of each other.Keep the content of the Legend tag brief (the Legend may be read when each of the controls contained in a Fieldset receive focus.)In Windows Eyes, the option to read the Legend tag is off by default.Fieldsets may be nested.
Sandra Earl

The order of link pseudo-classes matters | 456 Berea Street - 0 views

  • Common knowledge to most who have been working with CSS for a few years, but perhaps not something that relative newcomers have come across yet: the order in which you define the different link states affects the end result. I prefer the following order: :link, :visited, :hover, :focus, :active.
Sandra Earl

Introducing WysiHat: An eventually better open source WYSIWYG editor - (37signals) - 0 views

  • WysiHat is a WYSIWYG JavaScript framework that provides an extensible foundation to design your own rich text editor. WysiHat stays out of your way and leaves the UI design to you. Although WysiHat lets you get up and running with a few lines of code, the focus is on letting you customize it. We are giving developers early access to the project while we continue to work out the remaining issues. Note: It’s extremely early. Contributors are welcome so please check out the project on GitHub and send us your feedback.
Sandra Earl

Captivate Accessibility Hints | SSB BART Group - 0 views

  • 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.
1 - 20 of 24 Next ›
Showing 20 items per page