JavaScript Pop-ups – Good or Bad?
Posted by Michael Gaigg
Having witnessed a recent discussion on the WAI Interest Group list I asked myself, are JavaScript Pop-ups good or bad (or evil)?
Conclusion
It depends. But mostly bad 
Con's
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:
...the pop-up almost certainly takes the focus away from the current window. Blind users will not know this unless you tell them AND provide a clear method to close the pop-up and return the user to the point immediately after where the pop-up activated. Also remember to provide a text based alternative for those who do not have javascripting.
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.
Pro's
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)
My Take
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
Accessibility Events in May
Posted by Michael Gaigg
Jennison Mark Asuncion just posted 4 upcoming accessibility events in North America:
- Ottawa's First Accessibility Unconference, May 6 in Ottawa Ontario (free event) register now at http://www.a11yyow.ca
- John Slatin AccessU 2011, May 17-19, Austin TX http://www.knowbility.org/v/accessu-detail/John-Slatin-AccessU/39/
- Accessibility Camp Seattle, May 20-21 (free event) register now at http://www.AccessibilityCampSeattle.org
- The Guelph Accessibility Conference, May 31-June 1, Guelph ON http://www.accessconf.open.uoguelph.ca/
Missed one? Post it in the comments section.
Voluntary Product Accessibility Template (VPAT)
Posted by Michael Gaigg
The Voluntary Product Accessibility Template (VPAT) is a tool used to document a product's conformance with the accessibility standards under Section 508 of the Rehabilitation Act.
Download
Download VPAT in MS Word format.
Purpose
The purpose of the document is to assist vendors and buyers in assessing the accessibility of a product/website and formalizing a form of accessibility statement. This is not an Section 508 Certification, such a certification doesn't exist!
Format
From Information Technology Industry Council (ITIC): "The first table of the Template provides a summary view of the section 508 Standards. The subsequent tables provide more detailed views of each subsection. There are three columns in each table. Column one of the Summary Table describes the subsections of subparts B and C of the Standards. The second column describes the supporting features of the product or refers you to the corresponding detailed table, "e.g., equivalent facilitation." The third column contains any additional remarks and explanations regarding the product. In the subsequent tables, the first column contains the lettered paragraphs of the subsections. The second column describes the supporting features of the product with regard to that paragraph. The third column contains any additional remarks and explanations regarding the product."
Richtlinien für barrierefreie Webinhalte (WCAG) 2.0 (German)
Posted by Michael Gaigg
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)
http://www.w3.org/Translations/WCAG20-de/
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
I also suggest you to have a look at my blog entries about WCAG 2.0: Overview and Structure and Section 508: WCAG 1.0 or WCAG 2.0?
Best Practices for Accessible Stylesheets
Posted by Michael Gaigg
Cascading Style Sheets (CSS), or short Stylesheets, is a language used to describe the presentation (that is, the look and formatting) of a document written in a markup language like HTML.
The stylesheet language as described in CSS level 2 revision 1 helps to separate presentation from structure and thus adds flexibility to the look and feel of a web page. Stylesheets are useful for the following reasons:
- Can be re-used for many documents
- Saves download times by caching by the browser
- Presentational changes are fast and easy and only in one document
- Development can be done independently from content and logic
- Increases ability to program for device independence
- Application of different styles for different output formats (e.g. print)
Basic Rules
- Add Stylesheets whenever possible (minimize number of stylesheets)
- Use them consistently across all pages
- Use linked stylesheets rather than embedded styles; avoid inline stylesheets
- Stylesheets do not substitute correct and meaningful structure
Best Practices
Level 1
| Description | W3C | 508 | Example |
|---|---|---|---|
| Organize documents so they may be read without style sheets | 6.1 | d | Ensure that important content appears in the document object and is not generated by style sheets (i.e. through :before and :after pseudo-elements). |
Level 2
| Description | W3C | 508 | Example |
|---|---|---|---|
| Use style sheets to control layout and presentation | 3.3 | n/a | <HEAD> <TITLE>Drop caps</TITLE> <EM class="highlight" title="provide STYLE element">STYLE</EM> type="text/css"> .dropcap { font-size : 120%; font-family : Helvetica } </EM class="highlight" title="provide STYLE element">STYLE</EM>> </HEAD> <BODY> <P><SPAN class="dropcap">O</SPAN>nce upon a time... </BODY> |
Level 3
| Description | W3C | 508 | Example |
|---|---|---|---|
| Create a style of presentation that is consistent across pages | 14.3 | n/a | A consistent style of presentation on each page allows users to locate navigation mechanisms more easily but also to skip navigation mechanisms more easily to find important content. |
Template
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
<link rel="stylesheet" type="text/css" href="BaseStyleSheet.css" />
</head>
<body>
Hello World
</body>
</html>
/* Base CSS Document */
/**
Elements
*/
html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-weight: inherit;
font-style: inherit;
font-size: 100%;
font-family: inherit;
vertical-align: baseline;
}
/* remember to define focus styles! */
:focus {
outline: 0;
}
body {
line-height: 1;
color: black;
background: white;
font-family: Arial, Helvetica, sans-serif;
}
ol, ul {
list-style: none;
}
/* tables still need 'cellspacing="0"' in the markup */
table {
border-collapse: separate;
border-spacing: 0;
}
caption, th, td {
text-align: left;
font-weight: normal;
}
blockquote:before, blockquote:after,
q:before, q:after {
content: "";
}
blockquote, q {
quotes: "" "";
}
/**
Classes
*/
/**
IDs
*/
References
- Chisholm. W., Vanderheiden, G., Jacobs, I.; CSS Techniques for Web Content Accessibility Guidelines 1.0; http://www.w3.org/TR/WCAG10-CSS-TECHS/
Question: How can Internet Mapping Applications be made accessible?
Posted by Michael Gaigg
Following I will identify areas that make web-based maps inaccessible as per WCAG 1.0 (please see section: 'Questions and Possible Research Areas').
Shout for Help
Question: How can Internet Mapping Applications be made accessible for users with disabilities?
If you are currently working on resolving any (or all) of these issues, know of somebody that is working on them or even know existing solutions, I would greatly appreciate if you pointed them out to me.
It is absolutely impossible to continue with our current approach to seek exceptions as a 'work-around'!
Background
It is important to note that I'm not talking about simple Google maps like driving directions or locate services that could be described through alternative, textual output.
Many times a map is the means to select, query, mix and eventually analyze data across multiple layers from multiple services. The input requires good vision and motor skills (mouse) and same applies to the output that is highly visual as well.
A simple example that illustrates this fact pretty well is shown in Figure 1, Drive Times from a specific location based on traffic grid.
Figure 1: ESRI Map: Drive Times; produced using ArcGIS JavaScript API, http://mapapps.esri.com/serverdemos/siteselection/index.html
The Law
Section 508 as explained by Authority 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.”
This law is extended and applicable to companies that develop applications for the agency, i.e. ESRI has to adhere to the Section 508 Standards.
The Section 508 Checkpoints were translated into Web Content Accessibility Guidelines which cover most of Section 508 and describe its implementation in terms of HTML & CSS.
Current ‘Solution’
So far, exceptions to this law have been granted for the specific case of online maps. It is believed to impose an ‘undue burden’ to the agency/contractor to make maps accessible. In many cases a 1-800 number was provided that would help the user to get the same information.
Questions and Possible Research Areas
Currently the following WCAG checkpoints are Level 1 (A) show-stoppers and need to be solved/researched/implemented:
Checkpoint 1: Provide equivalent alternatives to auditory and visual content
How to read a map when blind? E.g. redundant text for active regions/content.
Checkpoint 2: Don’t rely on color alone
Map application could provide different color schemes/black&white/shades of gray?!
Checkpoint 6: Ensure that pages featuring new technologies transform gracefully
How to provide a map (or alternative) that can be used when scripts are turned off?
Checkpoint 8: Ensure direct accessibility of embedded user interfaces
Do not write event-handlers that rely on mouse-coordinates (device-independence; see also Checkpoint 9)
Checkpoint 9: Design for device-independence
How to navigate a map without a mouse?
Checkpoint 12: Provide context and orientation information
How to describe the content of a map (especially after a change, e.g. query)?
You know of a solution?
Please get in touch with me if you know of solutions to these problems!
I hope that solutions for these problems can be found and maps become available to everyone. As always, not only users with disabilities will benefit from these efforts but also the applications themselves, e.g. better SEO (search engine optimization), alternative support for mobile user agents, assistance for elderly people, etc.
Best Practices for Accessible Frames
Posted by Michael Gaigg
Frames are hardly used anymore (thanks God) but they can be useful and a good method to organize huge sites with lots of content, e.g. document libraries, API documentation, etc.
The 508 standard has no objection against frames and screen readers can handle frames well even though it might be difficult to comprehend the structure. The following basic rules and best practices outline how one can make frames accessible:
Basic Rules
- Title frameset and frames with meaningful names (descriptive instead of location, i.e. ‘navigation’ instead of ‘left’)
- Provide an alternative (NOFRAMES tag)
Best Practices
Level 1
| Description | W3C | 508 | Example |
|---|---|---|---|
| Provide a text equivalent for every non-text element | 1.1 | a | <FRAMESET cols="50%,50%" title="...">
<FRAME src="sitenavbar.htm" ...> <FRAME src="story.htm" ...> <NOFRAMES> [<A href="sitenavbar.htm" title="...">Table of Contents</A>] [<A href="story.htm" title="...">Story</A>] </NOFRAMES> </FRAMESET> |
| Title each frame to facilitate frame identification and navigation | 12.1 | i | <FRAMESET cols="10%, 90%" title="Our library of electronic documents">
<FRAME src="nav.html" title="Navigation bar"> <FRAME src="doc.html" title="Documents"> </FRAMESET> |
Level 2
| Description | W3C | 508 | Example |
|---|---|---|---|
| Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone | 12.2 | i | <FRAME src="sitenavbar.htm" name="navbar" title="Sitewide navigation bar" longdesc="frameset-desc.htm#navbar">
<FRAME src="story.htm" name="story" title="Selected story - main content" longdesc="frameset-desc.htm#story"> |
Template
<frameset cols="50%,50%" title="Our library of electronic documents">
<frame src="navigation.htm" title="Navigation bar">
<frame src="start.htm" title="Main Content">
<noframes>
[<a href="navigation.htm" title="Navigation bar">Table of Contents</a>]
</noframes>
</frameset>
References
- WebAIM; Creating Accessible Frames; http://webaim.org/techniques/frames/
Section 508: WCAG 1.0 or WCAG 2.0?
Posted by Michael Gaigg
Answer
In short: WCAG 1.0, at least for the next couple of years.
Standards Compliancy - Pro's and Con's.
The Web Content Accessibility Guidelines (WCAG) 2.0 are a final Web Standard "W3C Recommendation" and offer many advantages over WCAG 1.0. Blogs like Opera Developer Network suggest to use WCAG 2.0 rather than 1.0 because "[it] is easier and clearer to use, contains test statements (known as Success Criteria), can be applied to all web technologies (and not just W3C technologies like WCAG 1.0) and comes with lots of supporting documentation".
Standards compliancy will benefit your project in many ways, from code maintenance (faster code review/debugging) and repurpose (separate content from presentation) to bandwidth (master stylesheet helps reducing size of individual pages).
On the flip-side standards add load and thus expenses to projects and developers and are controversial in many cases.
Section 508 is a US law
Philosophy aside, Section 508 is a US law that renders above discussion obsolete and needs to be taken seriously. Not directly related but still a wake-up call is Target's non-compliance with the Unruh Civil Rights Act, California Civil Code §§ 51 et seq., the Disabled Persons Act, California Civil Code §§ 54 et seq., and the Americans with Disabilities Act, 42 U.S.C. §§ 12181 et seq. which resulted in a six million dollars settlement this month. Sorry to get you down to earth so quickly.
Timeline for Section 508 to adapt WCAG 2.0
Gregg Vanderheiden:
508 is undergoing a revision over the next couple years.
The first stage of that was an Advisory committee (TEITAC) that came up with recommendations
http://www.access-board.gov/sec508/update-index.htmThe advisory committee contained several WCAG Working group members and both TEITAC and WCAG worked together to harmonize. And, though they weren't completely harmonized (since both changed a bit at the end) all comments from members to access board were to continue harmonization in further steps.
Jim Tobias:
The Access Board's advisory committee on 255/508 (TEITAC) recommended that any new regs harmonize with WCAG 2.0, and the report's own proposed provisions themselves were pretty well harmonized, as Judy Brewer, Gregg Vanderheiden, and others from WCAG were on TEITAC. Expect Access Board action in 2009. View the report here:
http://www.access-board.gov/sec508/refresh/report/
Scott Plumlee:
Short version is that the recommendation is that 508 be harmonized with WCAG 2.0. You can subscribe to updates from the Access Board (I think, I can't find the link now) at access-board.gov. If you allow 2.5 years from the turning in of the report to the actual date the new guidelines take effect, look for 2011 or so. IIRC, the 2.5 years is how long it took for 508 to really go into effect the first time, but I could be wrong.
Outlook
Don't get me wrong, W3C WAI (and myself) recommends using WCAG 2.0, instead of WCAG 1.0 but to satisfy the law one needs to comply with WCAG 1.0.
That doesn't mean your company shouldn't prepare for the transition, not at all. To help you move to WCAG 2.0, WAI currently offers the following tutorials/articles:
- How WCAG 2.0 Differs from WCAG 1.0
- Comparison of WCAG 1.0 Checkpoints to WCAG 2.0
- How to Update Your Web Site from WCAG 1.0 to WCAG 2.0
What are your experiences?
Best Practices for accessible Images
Posted by Michael Gaigg
Graphics can be of great benefit to the accessibility of a Web page by providing
- Illustrations
- Icons
- Animations
- other visual cues that aid comprehension for sighted individuals
When designing for people with disabilities too often we forget that we are not designing only for the blind. We must consider disabilities of all types. Graphics can be useful especially to individuals with certain reading disabilities, learning disabilities, attention deficit disorders, or cognitive disabilities.
Basic Rules
- Do not use color alone to convey meaning
- Choose contrast so that text is easily distinguishable from the background
- Communicate the purpose of the graphic (not its appearance) through meaningful alternative text
- When graphics require complex descriptions use the longdesc attribute, a link to an alternative page, a description in the context itself, or a “D” link
- Use empty alt text for decorative, transparent, spacer, and redundant images
- Try to limit the amount of text in graphics
- Do not use effects that flicker or produce a strobe-like effect
- Use images as backgrounds only if they do not convey important content (since it is impossible to add alt text to background images)
Best Practices
Level 1
| Description | W3C | 508 | Example |
|---|---|---|---|
| Ensure that all information conveyed with color is also available without color | 2.1 | c | Ensure that information is available through other style effects (e.g., a font effect), through context (e.g,. comprehensive text links) or through mark-up (e.g., the title attribute). |
| Until user agents allow users to control flickering, avoid causing the screen to flicker | 7.1 | j | n/a |
| Provide text equivalent for Images, graphical or animated buttons, spacers, bullets | 1.1 | a | <FORM action="..." method="post">
<INPUT type="button" alt="Click this button to verify form" value="Verify" onclick="verify()"> <INPUT type="image" name="submit" src="button.gif" alt="Submit form"> </FORM> |
Level 2
| Description | W3C | 508 | Example |
|---|---|---|---|
| Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen | 2.2 | c | For more information check the online paper about Effective Color Contrast. |
| When an appropriate markup language exists, use markup rather than images to convey information | 3.1 | n/a | Mark up complex equations with e.g. MathML. |
| Avoid causing content to blink | 7.2 | n/a | n/a |
| Avoid movement in pages | 7.3 | n/a | i.e., hide/show content or change presentation (movement and colors). |
Level 3
| Description | W3C | 508 | Example |
|---|---|---|---|
| Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page | 14.2 | n/a | n/a |
References
- Arditi, Aries PhD. Effective Color Contrast. http://www.lighthouse.org/color_contrast.htm
- Ion, P., Miner, R. (editors); Mathematical Markup Language. http://www.w3.org/TR/REC-MathML/
- WebAIM; Creating Accessible Images. http://webaim.org/techniques/images/
Get started with Screen Readers
Posted by Michael Gaigg
Browsers
The following browsers have support for Accessible Rich Internet Applications (ARIA) and are supported by several screen readers that also offer support for ARIA.
- Firefox 3
- Internet Explorer 8
- Opera (has support for ARIA but isn't supported by screen readers)
Screen Readers
The most popular screen readers for Windows are:
- JAWS (free demo, Standard: $895, Professional: $1,095)
- Window-Eyes (free demo, Standard: $895)
- NVDA (Firefox 3 only, Open Source under GNU 2)
Installation
Please refer to Todd Kloots' fine blog entry on how to 'Configure your machine for testing with a screen reader'. This is a summary of his installation steps:
- Install virtualization software
- Install browsers & take a snapshot of that state
- Install and configure screen readers
- Restart the virtual machine & take a snapshot of that state
Which screen reader are you using? What are your experiences?
About Me
I'm Michael Gaigg, Lead UI Engineer at Esri's Prof. Services.
I have over 8 years of experience in designing map interfaces and can't stop thinking about improving them.
Help me by sharing your thoughts, ideas and comments.
Categories
- Accessibility (16)
- Code Samples & Tips (8)
- Conclusions (4)
- Design Guidelines (11)
- Designing Map Interfaces (3)
- Go figure (9)
- Good News (19)
- Here and there (21)
- Map Applications (7)
- This Week's Highlights (53)
- Usability & UCD (22)
- Web Design (21)
Popular Posts
- ColoRotate – 3D color scheme generator with social component
- Web Content Accessiblity Guidelines (WCAG) 2.0: Overview and Structure
- Powerpoint Wireframe Stencils as Free Download
- Go figure: 10 Comic Strips that have Something in Common
- Job Posting: User Interface (UI) Engineer at ESRI
Latest tweets
- Awesome resources for website designers http://t.co/oB77As8O 2 weeks ago
- I just contacted Rep. Jerry Lewis to oppose #SOPA #PIPA - Join me! http://t.co/BuFcgvqf #wikipediablackout 2 weeks ago
- Awesome #login #form #sample http://t.co/hob6dtvF 3 weeks ago
- Photo: Dude, just don’t pin the place you’ve been… ;) http://t.co/lwf3gIU8 2012-01-09
- Photo: Who wants to buy a church in Los Angeles? http://t.co/0SJrYxCv 2011-12-31
- More updates...
Posting tweet...
