Aug 6, 2010 0
Here’s Another Free PowerPoint E-Learning Template http://ping.fm/dMDNP
Aug 6, 2010 0
Here’s Another Free PowerPoint E-Learning Template http://ping.fm/dMDNP
Aug 6, 2010 0
Bloom’s According to Pirates of the Caribbean http://ping.fm/wqH4F
Mar 18, 2010 0
This is an incident that clearly shows how cut-throat and competitive the eLearning industry has become in India. As smaller companies fight to survive and retain clients, some are resorting to questionable practices in their quest for a share of the pie. Mr. Samir Inamdar is not a stranger to this industry, having first worked with Maximize Learning (subsequently aquired by Techbooks/Aptara) and then having joined Brainvisa (subsequently aquired by Indecomm Global Services) before moving on to start his own eLearning company by the name of Enthuse Technologies.
"The cyber crime cell of the city police on Saturday arrested Samir Inamdar on charges of violation of copyright laws allegedly leading to a loss of Rs 100 cr to a city-based e-learning firm.
According to a press release by the police, Inamdar had been dismissed from Brainvisa in 2006 and formed his own e-learning company subsequently. However, he illegally retained possession of Brainvisa's product demonstrations and their source codes, and later tried to pass these off as his company's products to potential clients.
Inamdar's lawyer and friend refuted the charges, saying that he was "innocent" and was "being framed".
According to a press release issued by Brainvisa, Inamdar was employed in key positions in Brainvisa Technologies Pvt Ltd, Pune and Brainvisa Inc, US. During his stint in the company, he had access to its products, demonstrations, source codes, proprietary data and confidential information. After being dismissed from service, he illegally copied this data and information.
The press release further said that Inamdar then started his own e-learning company, Enthuse Technologies Pvt Ltd. The Brainvisa management recently learnt that Inamdar and his associates had uploaded product demonstrations originally developed by them, along with their source code, on Enthuse's official website. Inamdar was allegedly soliciting clients by passing off the products as Enthuse's own, the press release stated.
Brainvisa expects to potentially suffer business losses to the tune of US $ 9.5 million annually as a result, the release added. The company has pegged the value of the intellectual property and confidential information allegedly in Inamdar's possession at US $ 500,000."
UPDATE – 24, JUNE, 2009 – Asma Thorve, ex-Vice President of Brainvisa also arrested by Pune police for providing Brainvisa data to Samir Inamdar. More here.
Here are highlights of the many great links relating to web accessibility going around Twitter this past month:
Several years ago I read an article by Garrett Dimon titled “User preferences are for sissies” (available at archive.org, also see this 37signals article). The general idea is that when you present preferences to the end user it typically indicates that you screwed up or are a sissy – either you are forcing the user to account for a poor design or usability decision, or you are too indecisive to make the decision to begin with and thus place the burden to decide upon the user.
In general, I believe that web accessibility preferences are no different.
I’ve found that some have misinterpreted the message of this post to suggest that those who implement web accessibility preferences, or even web accessibility at all, are literally sissies. This is not at all what I am suggesting – I would not have devoted my life’s work to this effort if I viewed implementers of web accessibility this way. Such preferences obviously have their place, particularly on sites that target people with disabilities (see the comments below). However, implementing them as a method of avoiding native accessibility in content is not acceptable and certainly a cop-out approach to accessibility. My primary goal is that developers will consider the impact on ALL users when implementing such widgets and preferences for a particular group of users.
The term “sissies” comes from the original article that inspired this. We do not intend offense by reusing it here, no more so than “Dummies” books literally mean that someone who reads them is a “dummy”. I have rephrased the article title as a question, to perhaps clarify that this is not a literal, blanket statement, but an invitation to question the motivations and the overall impact of implementing such preferences. I apologize to any who took offense at the general theme of this post. This post has also generated a good deal of respectful and interesting dialog which I hope will continue.
There may be places where accessibility preferences, widgets, or controls are justified. My point is that they always come at a very steep cost – and that developers should balance the possible advantages of web accessibility preferences with the significant disadvantages.
Consider font resizing widgets – the stack of letter A’s that allow one to increase or decrease the font size for a particular web page or site. First, if your font size is too small, why not simply make it adequately sized rather than forcing the user to make it bigger? But assuming that your page’s font sizing is already adequate, who would benefit from a font resizing widget? Users with poor vision, right? But users with more extreme low vision will already be using a screen enlarger or some other mechanism for zooming the page or increasing the font size, so your widget does them little good. Many users who prefer or need larger text will be using the zoom function that is available in all major browsers to provide the larger text on all web pages they encounter. The more accurate response to the question is users who have low vision or who might prefer larger text, but who are not already using technology or browser functionality to provide it. This is a rather small body of users.
Now, who gains no benefit from or could be potentially disadvantaged by a font resizing widget? The short answer is EVERYBODY ELSE!
As noted above, many users with low vision will already have larger text. Users who are blind generally don’t care how big the text is, yet they must listen to and navigate through the widget controls on every page. Users with motor disabilities who use only the keyboard must also ‘tab’ through these controls while gaining no benefit from them. Users with auditory disabilities gain no benefit. Users with cognitive disabilities must handle the additional cognitive load of these controls (what does a stack of increasingly sized A’s mean anyway?). And most notably, users with adequate vision gain no utility from the widget (again, assuming your default font size is adequate), yet are still presented with the control on each and every page.
So, while the font resizing widget has potential to provide some benefit for a small number of users, it serves no benefit and can only make the experience less accessible for everybody else.
The same can be said for nearly every other type of accessibility preference. A preference to enable a high contrast view is provided to either account for poor default contrast or to provide accessibility to a small group of users at the cost of burdening all other users with the contrast control. Text-only versions are typically provided to account for poor accessibility of a main page and may benefit some users (though our surveys indicate they are rarely accessed by these users anyway), but they increase the complexity of the page to everybody else. Even something as seemingly innocuous as an accessibility statement link or badges stating your compliance with standards come at a cost while providing negligible benefit to end users. The cost and benefit of each of these should be considered.
There may be exceptions to the “web accessibility preferences are for sissies” rule, but they are few. “Skip” links are one possible exception, but their days are numbered. They remain necessary only because most browsers have yet to provide meaningful methods of keyboard navigation within pages. Sites that target people with disabilities may find such preferences to be acceptable.
Universal design, like most aspects of web accessibility (consider alternative text for images), is about making solid decisions that are enforced upon users to ensure a highly effective user experience. These decisions must be informed and are often difficult to make. The idea that using accessibility preferences, widgets, or controls to account for poor accessibility or design decisions is a dangerous one that rarely results in overall improvements to accessibility.
The folks here at WebAIM are pleased to be attending The 25th Annual International Technology & Persons with Disabilities Conference, more commonly known as the CSUN conference. This conference is one of the highlights of our year. We love interacting with and being educated and invigorated by so many people that are passionate about accessibility.
We’ll be presenting the following sessions:
If you’re interested in attending, be sure to reserve your seat now.
WebAIM, in conjunction with several other fine organizations, is also sponsoring a CSUN Tweetup. We hope to see you there.
It may be trite, but this is a season of thanksgiving and of reflection. While many of us experienced our yearly turkey-laden thanks this past week with family and friends, WebAIM is celebrating 10 years of thankfulness for our work, and for your participation in the web accessibility community.
Few know that this past year marked WebAIM’s 10th birthday. Frankly, we have been so busy we almost missed it ourselves. What began in 1999 as a small federal grant (Department of Education – FIPSE) to provide awareness of the need for web accessibility and a few resources has grown to become one of the most trusted names in web accessibility.
I chuckle when I use the Internet Archive to look at where we began (please – do it, it is hysterical), and I am amazed at the traffic our current web resources receive. I continue to be humbled that we are consistently listed in the top few Google results for “web accessibility” and many other web accessibility related terms. The WAVE evaluation tool is used to evaluate nearly a million web pages per year. We hope to continue providing excellent resources.
While I want to point to the excellence and constancy of the staff here at WebAIM, you of course have made our articles and resources popular. Moreover, you also provided translations of many of these into other languages, broadening our impact. A number of our best ideas for resources have come from your suggestions. So please keep those ideas coming!
WebAIM’s discussion forum was started in 1999. In the beginning, we had to respond to ourselves to get any semblance of discussion going. Now, in the last year, over two million distinct e-mails were sent to the over 1000 list subscribers. In 2004, we expanded our WebAIM community and began our monthly newsletter. Then in June of 2006 we began this blog as a way to keep short ideas and opinions flowing. A runaway and unforeseen hit was Aaron’s “History of the browser user-agent string”. If you have never read it, you owe yourself this chuckle.
In the past 10 years we have had the privilege of providing training and technical assistance to thousands of individuals; many of them during site-based workshops at college campuses, governmental agencies, and businesses across the nation. And beginning in 2007, many right in our own backyard as we began to offer 2-day workshops here in Logan, Utah three times a year.
We are also thankful for the businesses, including several fortune 500 corporations, that contract with us for web accessibility evaluation and design work. This keeps us busy and on our toes in the most current technical dialogues.
We have seen shifts in the field over the past decade – web accessibility guidelines and standards refreshed (WCAG 1 to 2; 508 soon to refresh), legal consequences ignored and upheld, and an international climate welcoming and desirous of web accessibility. We continue to focus on our original goal of increasing awareness and knowledge so we all can make the web a better place for everyone. We recognize that you are the reason that we continue to thrive. We are thankful for what you do, and thankful that we are part of your journey. While we reflect over the past decade and on the accomplishments of WebAIM and those we serve, we also look forward to the next 10 years.
Screen readers treat data tables differently than layout tables. Layout tables are not identified and are read linearly as standard page content. Data tables, however, will be identified, the number or rows and columns read, and functionality provided for users to navigate through the table by cell.
While tables have never been intended to control layout, they often are used this way. The problem is that there is not a clear way to identify whether a table is being used for tabular data or for controlling layout. Screen readers, therefore, apply heuristics to determine the type of table encountered. The heuristics in the popular JAWS screen reader are very poor.
UPDATE: In response to the details provided here, Freedom Scientific reports that JAWS 11.0.756 released Dec. 17, 2009 resolves many of these issues and now accounts for the presence of table headers in it’s consideration of table type.
Data tables should typically be assigned table headers (the <th> element) for all header cells. The presence of a <th> element in a table should be a dead giveaway that a table is intended for data. I’ve seen very few instances of the <th> element inappropriately used in layout tables. However, JAWS does not consider table headers or any other markup commonly used in data tables to determine the table type.
Instead, JAWS assumes the presence of a data table if it has at least 2 rows and 2 columns AND at least 4 cells in the table are between 200 and 16000 square pixels in size. 16000 square pixels is not much – a long sentence of default text or a small 200X80 pixel image.
Additionally, JAWS will treat tables with the DataTable=true or DataTable=1 attributes as data tables. Because this attribute is neither commonly used nor standards compliant, this will not be discussed as a viable solution to the problem, though it could be implemented as a ‘hack’ if need be.
This logic leaves much to be desired. It results in many data tables being incorrectly treated as layout tables, even if those data tables have appropriate header or other accessibility markup. Likewise, layout tables may be identified as data tables.
Consider the following simple table:
Note: Joe was born on February 29th of a leap year, so he really is older than Fred even though he only celebrates his birthday every 4 years.
This is clearly a data table. Table headers and a caption have been provided. However, in JAWS this table is not read as a data table because there are only 3 cells (those in the left hand column) that are less than 16000 square pixels (at least at standard resolutions and settings). The sentence of text in the last cell makes that cell and all other cells in that column more than 16000 square pixels. JAWS users navigating this table will not get additional accessibility functionality.
Similarly, the following simple layout table which has no headers identified will be identified by JAWS as a data table simply because more than 4 cells are between 200 and 16000 square pixels in size.
To compound this issue, JAWS analyzes the rendered size of the cell only, regardless of the cell contents making it virtually impossible for developers to control JAWS behavior. This means that users who increase their font size or zoom the page contents in their browser are more likely to have data tables be interpreted as layout tables because they are more likely to have cells over 16000 square pixels. This is particularly concerning because JAWS users with low vision are very likely to have enlarged content.
ARIA does provide some assistance. Adding role="presentation" to the table causes it to always be treated as a layout table and adding ARIA role="grid" causes any table to be treated as a data table (note that with JAWS’ updated table detection heuristics, role="grid" is likely not necessary, and it could potentially cause confusion). This is supported in JAWS 10+.
Screen readers need heuristics to handle tables that are not coded with accessibility in mind, but no screen reader should ever treat a table with proper header markup as a layout table just because cells in that table happen to be big. Likewise, a layout table should not be treated as a data table just because none of the cells happen to be big. Hopefully Freedom Scientific will address this issue,
though this is rather unlikely considering their responsiveness to such issues in the past (update – this issue has been at least partially resolved in JAWS 11.0.756). There’s little that developers can do about this issue. They should continue marking up data tables for accessibility as best as they can and transition away from using tables for layout. Additionally, screen reader users can use NVDA or another screen reader that handles tables appropriately.
We’ve reported over the last several years about the target.com lawsuit and eventual settlement. The $6,000,000 settlement required that Target would implement accessibility for users with visual disabilities, among other things. We’re happy to report that the target.com web site is now quite accessible. Sporting a new design and accessibility features, the site can be considered a wonderful model of an accessible corporate e-commerce site. The National Federation of the Blind considers the site equally accessible to blind and sighted users. While you may not agree with the lawsuit or may have concerns about the impact it has ultimately had on people with disabilities, it’s clear that this site is more accessible now than it likely would have been otherwise.
While we will likely never know the cost of implementing accessibility on this site (and indeed we shouldn’t treat the price of accessibility as something separate from site design and development anyway), I suspect it cost them much less to implement the current levels of accessibility than it did for them to fight and settle the original lawsuit. The new site maintains a clean and stylistic design with nearly all accessibility happening naturally through the structure and presentation of the site pages. Their implementation of “skip” links is fantastic – try tabbing through the page. There is certainly room for some improvement, particularly in other areas of accessibility not addressed by the NFB settlement, but the point is that the site is functional, looks good, and is quite accessible.
Target, along with Amazon.com and a few other innovators in the e-commerce arena, is showing that accessibility of large, complex sites is not only possible, but beneficial to all potential customers and to the corporations themselves.
WCAG 2.0 requires that the foreground and background colors have a 4.5:1 contrast ratio at Level AA and a 7:1 contrast ratio at Level AAA. You can use our contrast checker tool to determine what the ratio is between any foreground and background color.
WCAG 2.0 also requires (at Level A) that color not be used as the sole method of conveying content or distinguishing visual elements. They further define this requirement for links with Technique G183, which states, “Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues on focus for links or controls where color alone is used to identify them.” This means that if you do not underline your links (or provide some other non-color designator for links), that the links must be sufficiently different in contrast from the surrounding text.
So if you combine these two requirements, in order to be Level AA conformant, your page must have all of the following:
In other words, your link color has to be significantly different from the background color AND the surrounding text color, which also has to be significantly different from the background color.
If you start exploring this, you’ll find that this requirement leaves only a small window of available page and link colors. For example, if your page has black text on a white background and you use the standard blue color for links, the link color must be between approximately this color of blue (#6e5eff) and this color of blue (#531fff). Any lighter or darker and it will not have sufficient contrast to the adjacent black text or to the white background, respectively.
And if your text/background colors aren’t pure black and white, this significantly narrows or eliminates the window of colors with sufficient contrast.
This becomes more complicated if you want to provide various link states (hover/focus, visited, active) colors. If you go with the traditional blue, red, and purple colors for link states, each of these three colors would have to fit into the narrow window of available contrasts.
Some testing shows that this is possible… barely. The following colors for link states meet these requirements for a black on white page:
But there’s not much wiggle room – if you change any of these colors much you’ll break either the 3:1 requirement to black or the 4.5:1 requirement to white. The W3C does provide a list of web-safe colors that fit within these contrast requirements. But if your page doesn’t have black on white (or vice versa), it quickly becomes impossible to get any one color to work, let alone two or three colors for the various link states.
To complicate things further, if you’re looking for AAA conformance, which requires foreground/background contrast of 7:1, you have virtually no choice in the color combinations. You must have black text on a white background and your blue/red/purple colors must be VERY close to #3344dd, #b50010, and #804180. These work out exactly to 3:1 to black and 7:1 to white, the very minimal levels allowed.
It’s important to note that according to G183, focus/hover states for links must have a non-color designator. This typically means that you would add the underline style to the link when it is hovered or tabbed to. This is a Level A requirement.
Because links that have current focus or are being activated will be visually apparent through the non-color designator, not to mention the fact the user has manually focused them, I believe the 3:1 contrast rule does not (or should not) apply to the hover, focus, or active states. In other words, it’s acceptable to have the hover, focus, and active link be very similar in contrast to the surrounding text color because the user must have done something with the link to activate that state AND the non-color designator must be present if they’ve done so. The 4.5:1 (or 7:1) contrast requirement to the background does apply to all link states.
Because of the WCAG 2.0 contrast requirements, if you don’t underline your links, there’s not much flexibility if you want to be Level AA, let alone Level AAA conformant. WCAG recognizes that meeting these contrast requirements “is not the preferred technique to differentiate link text”. Of course the easy solution to this is to simply underline links in their default state. Interestingly, underlined links can be the exact same color as their surrounding text, though this is far from optimal.
The contrast requirements for non-underlined links is a Level A guideline, which might suggest that they are of more importance than having high levels of contrast for non-linked content (which, interestingly, is only addressed at Level AA and AAA – white text on a white background with white underlined links is seemingly allowed at Level A). Regardless of conformance, it is vital for accessibility that there be good contrast for text and that links be discernible.
So, are the WCAG contrast requirements too stringent and inflexible? Or is it optimal for accessibility for WCAG 2.0 to limit non-underlined links to this narrow contrast window?