Skip to main content

Home/ Web Accessibility/ Group items tagged element

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Vernon Fowler

HTML5 Accessibility Chops: When to use an ARIA role | The Paciello Group Blog - 0 views

www.paciellogroup.com/...chops-when-to-use-an-aria-role

accessibility html5 browser

shared by Vernon Fowler on 24 Nov 12 - No Cached
  • The situation for new HTML5 elements is different and likely to remain so for some time. It will be years before New HTML5 elements get robust accessibility support implemented across browsers and platforms. This is particularly so for non interactive elements such as the new HTML5 structural elements because  accessibility APIs in general do not have defined roles for many non interactive elements. In this case it is recommended to add the appropriate ARIA roles to elements that are meant to convey meaning but are effectively meaningless due to lack of implemented accessibility support. For example, adding role=navigation to a nav element fills the gaps in support for HTML5 semantics as ARIA  is more robustly  supported by most modern browsers and assistive technology:
  • <nav role=”navigation”>
  • Authors/developers can safely assume that any element that has been around since HTML 4.0 is already accessibility supported in browsers that support accessibility. So they do not need a default implicit role added.
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

Accessible forms using WCAG 2.0 | Web Usability - 0 views

usability.com.au/...ccessible-forms-using-wcag-2-0

forms accessibility html

shared by Vernon Fowler on 10 Feb 14 - No Cached
  • 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

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

HTML5 Accessibility Chops: section elements | The Paciello Group Blog - 0 views

www.paciellogroup.com/...ibility-chops-section-elements

accessibility html5

shared by Vernon Fowler on 24 Nov 12 - No Cached
  • The following table illustrates support and interaction features for a number of structural HTML elements. The information is based on support for these elements by the JAWS screen reader.
  • Recommended ARIA role mappings for HTML5 section elements
  • <header role=”banner”>
  • ...1 more annotation...
  • <nav role=”navigation”>
  • Vernon Fowler on 24 Nov 12
     
    "banner"
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.
Vernon Fowler

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

www.alistapart.com/...now-you-see-me

css webdesign accessibility usability content javascript class

shared by Vernon Fowler on 28 Oct 12 - No Cached
  • 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
      Vernon Fowler on 17 Mar 13
       
      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

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

WebAIM: Creating Accessible Forms - Screen Reader Form Accessibility - 0 views

webaim.org/...screen_reader

webdesign forms screen reader form reading usability accessibility

shared by Vernon Fowler on 07 Oct 12 - No Cached
  • This can be solved by associating form labels to form items on the page. The label should almost always be located adjacent to the form item itself. When a screen reader accesses a form item that has a <label> element associated with it, it will read the text within the <label> element and indicate the type of form item it is (e.g., "First Name. Text box" or "Age. Check box"). Labels are needed for all form elements, except for buttons; the screen reader reads the text that is on the button (e.g., "Submit button").
  • Let's hear what the form sounds like to a screen reader:
  • Let's hear what the form sounds like now, with the improvements that we made:
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.
Vernon Fowler

Screenreaders · Bootstrap - 0 views

getbootstrap.com/...screenreaders

accessibility webdesign

shared by Vernon Fowler on 16 Sep 18 - No Cached
  • Hide an element to all devices except screen readers with .sr-only.
  • Combine .sr-only with .sr-only-focusable to show the element again when it’s focused (e.g. by a keyboard-only user).
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

Responsive Design is Too Responsive? - 0 views

www.visionaustralia.org/...sive-design-is-too-responsive-

design responsive design responsive webdesign accessibility css3 media queries mediaqueries

shared by Vernon Fowler on 07 Apr 13 - No Cached
  • When you use browser zoom in Webkit browsers (Chrome and Safari), all elements on the page increase in size and start overlapping content. This is because WebKit browsers zoom to make the content bigger but the width of the browser remains unaffected, which means it doesn’t trigger responsive style sheet elements or address layout issues.
  • This is an accessibility issue as users with vision deficiencies use browser zoom to navigate websites. If they use Google Chrome they will have a lot of issues accessing content.
Sandra Earl

Forget WYSIWYG editors - use WYSIWYM instead | 456 Berea Street - 0 views

www.456bereastreet.com/...yg_editors_use_wysiwym_instead

accessibility WYSIWYG

shared by Sandra Earl on 12 Oct 10 - Cached
  • A huge problem with almost every CMS in existence is the extremely poor quality of the code produced by their WYSIWYG editors.
  • Since visual gadgetry like WYSIWYG editors sells, every CMS has to have one.
  • That, in turn, makes it necessary for Web professionals who want to reduce the risk of clients unknowingly ruining the website’s semantics and accessibility to disable features and implement more or less advanced code cleaning procedures. It is a mess.
  • ...4 more annotations...
  • Because of the problems caused by WYSIWYG editors I have toyed with the idea of providing a much simpler interface for content editors. Markdown, BBCode, and Textile are a few possible solutions that ensure valid markup and increase the likelihood of it being semantic. The problem would be making clients accept working that way, directly editing pseudo markup. Most clients wouldn’t, so that option is ruled out.
  • But there is another kind of editor that is better suited than WYSIWYG for content-driven, client-edited sites - the WYSIWYM (What You See Is What You Mean) editor. In Visually Editing Semantics - What You See Is What You Mean, Peter Krantz mentions one such editor: WYMeditor.
  • From the WYMeditor site: Our goal is to create a XHTML strict web-based editor which will be usable on many platforms, whith the help of the Open Source Community.
  • There are a few limitations, of course. This is an early version, after all. Besides the issues Peter notes in his post about WYMeditor, here are a few more things I noticed: Table accessibility. There is no way to add elements and attributes (th, caption, scope, etc) needed for accessibility to data tables. Table resizing. It is possible to size tables by dragging handles. Doing so is reflected in the markup. That needs to be filtered out at some stage before saving the page to the database. Incorrect nesting of lists. When you create nested lists, the current list element is closed before the next level ul or ol is inserted.
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.
  • 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.)
  • ...2 more annotations...
  • WAI-ARIA provides the ability for developers to specify roles for document areas (and many other things).
  • 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.
Sandra Earl

WebAIM: Accessibility of AJAX Applications - Accessibility Issues - 0 views

webaim.org/ajax

accessibility AJAX ARIA WebAIM

shared by Sandra Earl on 12 Oct 10 - Cached
  • AJAX is
  • a smorgasbord of web technologies put together to allow dynamic client-server interactions to occur in web applications without requiring pages to reload or refresh.
  • AJAX uses the following:
  • ...13 more annotations...
  • The XHTML and CSS elements can be dynamically modified to display new information or styling. These changes are typically done using the Document Object Model.
  • XHTML (or HTML) and CSS to create an interface and visually style information.
  • JavaScript is used to manipulate the interface elements and is also used to establish a communication with a web server through XMLHttpRequest. This allows data (typically in XML format) to be transmitted between the client and the web server without requiring page reloads or refreshes.
  • standard type of client-server interaction
  • A web page interface is presented. User information is collected (via forms, links, etc.). The user submits information (submits form, activates link, etc.). The server processes submitted information. A new web page interface is sent to the user.
  • With AJAX, all of these steps can be handled in one interface.
  • The types of web applications and interactions allowed by using AJAX has given rise to the term "Web 2.0"
  • AJAX allows feature-rich, dynamic web applications which use server-side processing without requiring the traditional "submit data — retrieve web page"
  • allows more streamlined applications that require less processing and data transmission
  • higher levels of interactivity
  • current solution to these problems is to either provide a non-AJAX alternative to your application or to allow your AJAX application to continue to function if JavaScript and XMLHttpRequest are not supported. Such a requirement may be very difficult to achieve
  • Another issue with AJAX is how the application interface is updated. When updates to the interface occur, it may not be visually apparent that a change has occurred. The problem is even more troublesome for screen reader users. Screen readers typically read in a linear fashion. When changes happen in the interface, the screen reader user may not be aware of the change and the new content will likely not be read.
  • to allow dynamic interface changes to be accessible, the application must alert the user that a change has occurred, allow direct access to the new content, and then allow continued functionality of the web application. This process, while difficult to achieve, especially for screen reader users, is possible to achieve in many AJAX applications.
Vernon Fowler

WebAIM: Color Contrast Checker - 0 views

webaim.org/...contrastchecker

accessibility contrast webdesign tool standards color colour colors colours text links DIG252 WEB300 checker

shared by Vernon Fowler on 12 Mar 14 - No Cached
  • WAVE can analyze contrast ratios for all page elements at once.
  • Colorzilla is an excellent tool for extracting the color value from any page element.
  • You can append ?fcolor=0000ff&bcolor=ff0000 (where the fcolor value is the foreground color and the bcolor value is the background color) to the URL of this page to analyze colors directly from a link or URL (link example).
Vernon Fowler

Accessible Breadcrumb Navigation - 0 views

scottaohara.github.io/a11y_breadcrumbs

navigation accessible accessibility markup

shared by Vernon Fowler on 17 Jul 19 - No Cached
  • Being that a breadcrumb is contained within a nav element, it will be surfaced as a landmark to screen readers. Providing it an accessible name of "breadcrumb" (or whatever term may be more meaningful to your site) will help differentiate it from any other navigation landmarks in the current document, such as the primary navigation
  • using aria-label to provide an accessible name, and aria-current to indicate the currently active link
  • screen reader support for aria-current is rather good
  • ...2 more annotations...
  • Some other breadcrumb patterns remove the <a> element, or at least the href from the link. These examples retain the a href for current link, as without it, people using a screen reader and navigating by links, or via focusable content with the tab key would not come across the currently active link.
  • Breadcrumbs are useful on large websites where pages have clearly defined hierarchy.
1 - 20 of 35 Next ›
Showing 20▼ items per page