HTML:HTML:CSS:javascript
: Editor's Notice: When I started off this blog page virtually 3 several years in the past, a person of the initially points I did was create a sequence on exhibiting and hiding aspects on the page. The posts had been especially standard, as was my information at the time. At greatest, they demonstrated an incomplete reply for the question of tips on how to selectively reveal subject matter depending on user interaction. At worst, they encouraged a solution not having any regard to accessibility. That is why I was thrilled when I saw an document on the Filament Group blog describing their accessible collapsible information widget. They've graciously accepted my request to re-post that review right here, so free of any further more ado, here it is… Collapsible material areas are frequently presented in web sites and applications as a option to let users to control how subject matter is shown or hidden around the page. Also called collapsibles, spin-downs, toggle panels, twisties, and subject matter disclosures, they're best for selectively displaying optional material — like instructional text or further facts, for example — so users can focus around the task at hand and view this articles only as needed. The collapsible subject material area widget is reasonably simple — a couple of HTML components controlled with minimal CSS and JavaScript — but when we have been researching our book,
Office Pro Plus 2007, Designing with Progressive Enhancement, we discovered that quite a few popular approaches to creating collapsible material fail to incorporate accessibility features. Happily, there is a way for you to build collapsible written content with progressive enhancement so it delivers an optimal available working experience for sighted and screen reader users alike. The code example described in this write-up is one particular from the 12 fully-accessible, project-ready, progressive enhancement-driven widgets that accompanies our new book, Designing with Progressive Enhancement. View a demo Before we dive in for the information, let's take a look on the widget in question. Here's an error dialog we created for a photo page, which appears when a photo upload fails — it provides a high-level summary,
Microsoft Office Professional 2007 Activation, and a collapsible Particulars block with supplemental articles about which photos failed to upload and why: Be aware about the demo's "View low bandwidth" link: This demo runs on our EnhanceJS framework, which adds a "View low-bandwidth version" link to allow users to toggle from a basic to enhanced view, and drops a cookie on change. If you click the link to view the low-bandwidth version of your demo, you'll might need to click it again to view the enhanced version of this web-site on future views. (Study a lot more about EnhanceJS here.) So what's the problem here? When we to begin with set out to build an available collapsible content material widget, we thought that the most effective technique to hide the material and keep it available to screen readers would be to position it off-screen. We didn't appreciate that despite the fact that technically this does make the material accessible, positioning content material off-screen doesn’t actually provide an available experience. People using assistive technologies like screen readers want to be able to interact along with the page just as sighted users do. As accessibility specialist Adam Spencer noted in a recent CBS News story, “True accessibility is giving blind people the same options to access material as sighted ones” (emphasis ours). Despite the fact that it’s true that hiding collapsible subject matter off-screen at least keeps it in the page and accessible at a baseline level, it’s decidedly sub-par compared with all the regular net user’s encounter. For example, when a consumer with a screen reader encounters an accordion widget with ten sections, just like a sighted user they want to hear only the open section,
Windows 7 Ultimate Activation Key, not all content material in every section. Screen reader users also expect to use the keyboard to quickly hear the accordion section headings — the screen reader equivalent of quickly scanning the page. When you simply hide articles off-screen, these actions aren’t possible; instead, the screen reader reads all material in all the hidden panes, and the screen reader consumer has no option but to wade through it all with the order it appears from the markup. Ideally, the practical experience for both sighted and visually impaired users should be as functionally similar as possible. The W3C World wide web Content material Accessibility Group (WCAG) has outlined a set of four principles that must be met to ensure that content material is accessible. Quickly, they say that it should be: Perceivable — Information and person interface parts must be presentable to users in approaches they can perceive. Operable — User interface components and navigation must be operable. Understandable — Advice and the operation of person interface must be understandable. Robust — Information must be robust enough that it can be interpreted reliably by a wide variety of consumer agents, including assistive technologies. That’s all well and good, but these definitions are a little abstract. What does it really mean? WCAG provides extended definitions that give us some helpful clues — for example, Perceivable information “can't be invisible to all of their senses”; an Operable interface “cannot require interaction that a consumer cannot perform”; an Understandable interface’s “content or operation cannot be beyond their understanding”; and it truly is Robust if “as technologies and person agents evolve, the content material should remain accessible”. In light of these principles, a lot of normal techniques for presenting collapsible articles fall quick. Consider these scenarios: Hiding content by default during the CSS, and relying on JavaScript events to let the person display it. If JavaScript is disabled or unavailable, the user has no means of accessing the written content, and may not even know it's there. In this case, subject material is neither perceivable nor operable — or worse, if the design provides a hint (like an openclose icon or "View details" link),
Office Pro 2007 Serial, the hint is perceivable but the subject matter non-functioning. Hiding content material by positioning it off the page (e.g., position: absolute; left: -9999px;). Doing this ensures that the material is out there to screen readers. However, it's always attainable — the consumer has no ability to control exhibiting or hiding, or manage whether it's is read aloud. As collapsible written content it's not operable; and depending about the widget's information, presenting it all simultaneously may not be understandable. Providing only a visual indicator, like an icon, on the clickable element to show that it can manipulate visibility of related information. This works for sighted users, but fails for screen readers. Unless the icon is accompanied by some adequate auditory feedback that content material can be shownhidden, the feature may not be fully perceivable or understandable to your screen reader person. Applying JavaScript events to a non-natively-focusable element (such as a heading) to showhide related subject material. Whereas it works for mouse users, this approach does not guarantee that the widget is navigable for keyboard users (specifically in browsers that don't properly support the tabindex attribute), which are necessary for both screen readers and numerous mobile devices. In other words, it's potentially neither operable nor robust. To design a collapsible information widget that works for everyone — and doesn't compromise the encounter for screen reader users — we had to rethink what "accessibility" means when displaying and hiding content. Our approach We begin the process of by marking up the page with semantic HTML factors for the heading and content blocks. For example, consider the collapsible widget portion of our error dialog,
Office 2010 Pro Plus Product Key, which consists of a heading element immediately followed by an unordered list: This markup provides a usable and natively available primary working experience in all browsers. If JavaScript is present, we use it to apply enhancements that transform this markup into a functioning collapsible widget with a number of accessibility features. The enhancement script appends a few attributes and aspects to the fundamental markup: classes are assigned to your heading element which hide the Particulars subject matter and apply a visual cue (icon) to indicate that it can be expanded or collapsed a span tag is appended on the heading immediately before the text label which contains the word "Show" followed by just one space if the information is hidden by default; when the subject matter is shown, the script dynamically updates this word to "Hide." This span is intended only for screen readers to audibly describe the heading's function as a toggle link (i.e., "Show Details"), so it's hidden from typical browsers with absolute positioning and a large negative left value a common anchor link element is wrapped across the heading content to allow it to receive keyboard focus and be accessed with all the Tab key an aria-hidden attribute is assigned to the unordered list to ensure that it is actually truly hidden from ARIA-enabled screen readers when it is actually hidden from sight (aria-hidden="true"). When display: none; will sufficiently hide the information in current screen readers, future screen readers may not continue to obey visual styles like display, so adding this attribute is considered good, fail-safe practice. classes are also appended to the unordered list to show or hide it visually with CSS. To hide the subject matter, we use the display: none CSS property so that the material is completely hidden from all users The resulting enhanced markup looks like this: And the enhanced classes for providing feedback are structured as follows – recognize that we use a single background image sprite (icon-triangle.png), and simply adjust the background position to show the appropriate state: Note on testing browser capabilities: To ensure that the browser can fully support all enhancements, we recommend using our EnhanceJS framework, which tests browsers' CSS and JavaScript capabilities and applies enhancements only after those tests are passed. Read far more about EnhanceJS here: Introducing EnhanceJS: A smarter, safer solution to apply progressive enhancement. What we accomplish When built as described above, our collapsible subject matter widget incorporates specific features to meet the four accessibility principles outlined by WCAG: To ensure that it’s perceivable and understandable, it includes cues for both visual and screen reader users that indicate the heading element will show and hide associated subject matter. Visual users see an icon that changes orientation depending on the content's state; for screen reader users, the script conditionally appends the word "Show" or "Hide" before the heading text to describe the content's state and provide appropriate language to indicate how the heading is used. In addition, the widget provides feedback to ARIA-enabled screen readers with all the ARIA attribute, aria-hidden; it's set to true when the content material is hidden, and false when shown. To make it operable, we ensure that the widget is fully navigable and controllable together with the keyboard. When CSS and JavaScript enhancements are applied towards the page, the script wraps each heading element's text with an anchor element so that the person can navigate to and focus around the heading using the Tab key, and hide or show related material along with the Enter key. And our progressive enhancement approach helps us ensure it’s robust: The foundation is semantic HTML, which can be accessible and usable on all browsers; only when a browser is capable of enhancements is the markup transformed into a collapsible widget with enhanced styling and behavior. Looking ahead The HTML5 spec includes a new element called facts, which if implemented as proposed, will provide a native collapsible widget that will require no JavaScript and will be accessible with no requiring any extra work. No browsers have adopted the details element at this time, but it does present a potential alternative to this approach that we may be able to use within the future. Bruce Lawson provides an interesting summary of information and an argument in favor of using semantic interactive factors over JavaScript. Methods to use the plugin Download the collapsible content plugin script (see instructions below), and reference it and the jQuery library in your page. You'll also have to have to append the CSS classes listed above for that collapsed state of your widget. Notice: You'll likely demand to edit this CSS to fit with your own project's design. Call the collapsible plugin on the heading or other element that you're using to show related content material; the plugin then assumes that the next element inside source order is the material block to showhide. For example, on DOM ready it is possible to call the plugin on all H2 aspects: Where to download it If you've already purchased Designing with Progressive Enhancement, you are able to download all twelve widgets with the code examples download page. For that collapsible subject matter plugin and all others that happen to be released publicly as open source, download the zip. To know significantly more, check out Designing with Progressive Enhancement's open-source plugin Google Code repository: Help us improve the code We keep track of challenges (feature requests or found defects) within the DWPE Google Code online site. Please take a look at our list, and feel complimentary to add to it if you acquire a bug or have a specific idea about tips on how to improve the plugin that we haven't identified: If you think it is possible to help on a particular issue, please attach a patch and we'll evaluate it as soon as possible. Thoughts? Feedback? We'd love to hear what you think of this plugin. Please leave us a comment on our site!