It depends. But mostly bad 😉
John Colby's from Birmingham City University arguments on why pop-ups are bad:
- Because people are warned about them (http://www.bbc.co.uk/webwise/guides/about-popups)
- Because of their association with scams, viruses, malware, sites using popups are 'less trustworthy'
- Users with sight or cognitive problems (http://soap.stanford.edu/show.php?contentid=47)
- (And personally) if they insist on using popups I'll go away.
Richard from Userite remembers us that:
with Charles McCathieNevile from Opera adding:
...that many users have pop-ups blocked by default now, so won't actually see it even if they are not blind.
Harry Loots of the IEEE has a point when he says:
If it will supply useful information to the user, then don't kick against it, but make sure that the feedback / information so provided is accessible. For example, if the pop-up is used to confirm the product has been added and the user's browser does not support scripting/popups, a physical line of text may be displayed to confirm the product has been added (which can be hidden in the view seen by users who get the popup)
When a client asks for a specific design element, one needs to wonder where this need came from in the first place.
In the case that the client is not satisfied with visibility of system status. Try
- Improving titles and labels
- Adding non-obstructive instructions
- Providing feedback in an alternative way (as Harry pointed out), additional confirmation page always helps
- Keeping elements and its status (e.g. shopping cart belongs to the top right corner) in its user-anticipated location
- Using visual cues to show what just happened
Happy New Year everybody! Hope you are healthy and fully motivated for a new decade of great things to happen. It's going to be great!
Highlights of week 01/2010
Here is what made me happy last week:
- Placebos Are Getting More Effective. Drugmakers Are Desperate to Know Why (by Steve Silberman) - Belief is power, color, shape and labeling are important triggers for effectiveness; good article on wired; applicable to web design as well?!
- WAI initiative: Speak up! Tell organizations if their website is inaccessible - Take a few minutes to encourage web accessibility. Your voice counts.
- Myths & Misconceptions About Grid Systems - I'm a big believer in grid systems, but is it a one fits all? Do grid systems benefit each and every development? Is a website less valuable when not based on a grid system?
- Simple Numbers, Complicated Dates: 49 Innovative Calendars (by Michael Poh) - Start the New Year with some creative calendars.
- Web Design Trends and Resolutions for 2010 - A good collection and reflection by designreviver.com
- More Like This: A Design Pattern (by Greg Nudelman) - Design Patterns like 'More like this' help to speed up development, define a common language and should be part of everybody's toolkit
- Drop-Shadows and Gradients: Be Consistent in Your Visual Metaphors (by Nate Eagle) - How to design them correctly, please have a look, no excuses later!
Spreading the word about WCAG 2.0 is definitely good news. Yesterday Shawn Lawton Henry, WAI Outreach Coordinator and Chair of the WAI Education and Outreach Working Group, announced the publication of the German Authorized Translation of Web Content Accessibility Guidelines (WCAG) 2.0:
Richtlinien für barrierefreie Webinhalte (WCAG) 2.0 (German)
The WCAG 2.0 are also available in
- Brazilian Portuguese: Recomendações de Acessibilidade para Conteúdo Web (WCAG) 2.0
- Dutch (draft): Richtlijnen voor Toegankelijkheid van Webcontent (WCAG) 2.0
- French: Règles pour l'accessibilité des contenus Web (WCAG) 2.0
- Hungarian: Web Akadálymentesítési Útmutató 2.0
- Korean: 웹 콘텐츠 접근성 지침 2.0
- Portuguese: Directrizes de Acessibilidade para o Conteúdo da Web (WCAG) 2.0
- Spanish: Pautas de Accesibilidad de Contenido Web 2.0
So you know what Accessibility is and how it improves your ROI and why everybody benefits. Now what exactly is Section 508 and how does it correlate with W3C's Web Content Accessibility Guidelines (WCAG 1.0)? And most important, how can you create an accessible.htm that complies with these standards?
Overview: WCAG & Section 508
The main institutions involved (as shown in the illustration above) are:
- GSA (U.S. General Services Administration) represented by the IT Accessibility and Workforce (ITAW) who is the governments principal advocate and coordinator for Section 508 implementation. Other agencies and organizations may offer similar information, but ITAW is recognized as the governmentwide policy resource for Section 508.
- World Wide Web Consortium (W3C) represented by the Web Accessibility Initiative (WAI) who developed the Web Content Accessibility Guidelines 1.0 that was approved in May 1999 and is currently the stable and referenceable version.
- Users that visit websites. In the illustration I mention Government websites as the institution with the biggest need, that is because the Accessibility Guidelines are mandatory for governmental implementations.
Before I continue to explain how the WCAG relate to the Section 508 Standards it is important to get a grasp of what the respective guidelines propose and which checkpoints are included.
Checkpoints: Section 508 Standards
The purpose of Section 508 Standards is explained by Authority 29 U.S.C. 794d: “The purpose of this part is to implement section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d). Section 508 requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, Federal employees with disabilities have access to and use of information and data that is comparable to the access and use by Federal employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency. Section 508 also requires that individuals with disabilities, who are members of the public seeking information or services from a Federal agency, have access to and use of information and data that is comparable to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency.”
|Non-text elements||A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).||(a)|
|Multimedia presentation||Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.||(b)|
|Color||Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.||(c)|
|Style Sheets||Documents shall be organized so they are readable without requiring an associated style sheet.||(d)|
|Server-side image maps||Redundant text links shall be provided for each active region of a server-side image map.||(e)|
|Client-side image maps||Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.||(f)|
|Data tables||Row and column headers shall be identified for data tables.||(g)|
|Markup & tables||Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.||(h)|
|Frames||Frames shall be titled with text that facilitates frame identification and navigation.||(i)|
|Flickering||Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.||(j)|
|Text-only page||A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.||(k)|
|Scripting languages||When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.||(l)|
|Applets, plug-ins or other applications||When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l).||(m)|
|Electronic forms||When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.||(n)|
|Navigation links||A method shall be provided that permits users to skip repetitive navigation links.||(o)|
|Timed response||When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.||(p)|
Checkpoints: Web Content Accessibility Guidelines
The guidelines as described by the W3C explain how to make Web content accessible to people with disabilities. “The guidelines are intended for all Web content developers (page authors and site designers) and for developers of authoring tools. The primary goal of these guidelines is to promote accessibility. However, following them will also make Web content more available to all users, whatever user agent they are using (e.g., desktop browser, voice browser, mobile phone, automobile-based personal computer, etc.) or constraints they may be operating under (e.g., noisy surroundings, under- or over-illuminated rooms, in a hands-free environment, etc.). Following these guidelines will also help people find information on the Web more quickly. These guidelines do not discourage content developers from using images, video, etc., but rather explain how to make multimedia content more accessible to a wide audience.”
|01.||Provide equivalent alternatives to auditory and visual content.|
|02.||Don't rely on color alone.|
|03.||Use markup and style sheets and do so properly.|
|04.||Clarify natural language usage.|
|05.||Create tables that transform gracefully.|
|06.||Ensure that pages featuring new technologies transform gracefully.|
|07.||Ensure user control of time-sensitive content changes.|
|08.||Ensure direct accessibility of embedded user interfaces.|
|09.||Design for device-independence.|
|10.||Use interim solutions.|
|11.||Use W3C technologies and guidelines.|
|12.||Provide context and orientation information.|
|13.||Provide clear navigation mechanisms.|
|14.||Ensure that documents are clear and simple.|
Considerations when implementing for Section 508 Compliancy
Section 508 has three Levels of priority: Level 1, Level 2 and Level 3. WCAG has also three levels of priority, but they are slightly different and named A, AA, AAA. This is an important distinction especially when testing with automated tools like Bobby because - and be aware of this - Level A compliancy NOT EQUALS Level 1 compliancy. Here is why:
When the ITAW handed Paragraph 1194.22 to the WAI (step 1) and after the WCAG 1.0 were completed and handed back to the ITAW (step 2) the Access Board released a Note to §1194.22:
- The Board interprets paragraphs (a) through (k) of this section as consistent with the following priority 1 Checkpoints of the Web Content Accessibility Guidelines 1.0 (WCAG 1.0) (May 5, 1999) published by the Web Accessibility Initiative of the World Wide Web Consortium:
Section 1194.22 Paragraph WCAG 1.0 Checkpoint (a) 1.1 (b) 1.4 (c) 2.1 (d) 6.1 (e) 1.2 (f) 9.1 (g) 5.1 (h) 5.2 (i) 12.1 (j) 7.1 (k) 11.4
- Paragraphs (l), (m), (n), (o), and (p) of this section are different from WCAG 1.0. Web pages that conform to WCAG 1.0, level A (i.e., all priority 1 checkpoints) must also meet paragraphs (l), (m), (n), (o), and (p) of this section to comply with this section.
Item 2 is especially important because it means that a discrepancy between WCAG and Section 508 exists that requires a Section 508 Level 1 conformant site has to meet more than just Level A of the WCAG.
Step 3 and step 4 complete the process to create accessible.htm - it is basically up to you to apply the guidelines and produce accessible code.
Best Practices for Accessiblity
Follow my Best Practices blog entries to get more in-depth knowledge on what exactly you need to do to meet all the Section 508 compliancy checkpoints as outlined by the WCAG. Blog entries available so far:
- Section 508 Standards; Authority: 29 U.S.C. 794d; http://www.section508.gov/index.cfm?FuseAction=Content&ID=12
- Chisholm, W., Vanderheiden, G., Jacobs, I. (editors); Web Content Accessibility Guidelines 1.0; http://www.w3.org/TR/WCAG10/