Click here to download the Website Accessibility PowerPoint presentation
Click here to download the Website Accessibility PowerPoint presentation
On January 18, 2017, the United States Access Board, also known as the Architectural and Transportation Barriers Compliance Board, updated two acts related to making technology accessible to people with disabilities. The first modification is to the Electronic and Information Technology Accessibility Standards within Section 508 of the Rehabilitation Act of 1973.
Section 508 stipulates requirements on how federally funded entities develop, procure, maintain, or otherwise use information technology. The impetus for the action was a desire to “refresh” the nearly 20-year-old, static accessibility standards within each act, adopting a more modern and internationally recognized standard. It was determined that the Web Content Accessibility Guidelines (WCAG) 2.0 was best suited to fulfill this requirement.
In “Section 508 Refresh: How WCAG Impacts Federal Website Accessibility Requirements,” Microassist’s Hiram Kuykendall summarizes and maps the Section 508 references to the internationally recognized WCAG, including multiple links to the new federal Information and Communication Technology (ICT) Standards and Guidelines and to WCAG’s success criteria.
We live in an era when information is readily available no matter where we go, thanks to mobile phones and the proliferation of apps for every possible need or interest.
Yet one of the largest audiences for mobile apps is still often overlooked.
In the United States, one out of every five adults has a disability, according to a 2015 study published by the Centers for Disease Control and Prevention. That’s about 22% of the population.
What’s more about 10% of the world’s total population, or roughly 650 million people, live with a disability. Looked at another way – people with disabilities are the world’s largest minority group.
Designing universally accessible mobile apps, however, remains an afterthought in many cases.
Search online for discussions about designing mobile apps to be accessible for those with disabilities and there’s only a smattering of recent, authoritative articles.
Even on college and university campuses, the issue of universal design of mobile apps remains an emerging area of focus by and large.
While the higher education community has made great strides with regard to the accessibility of educational materials and general technology, mobile apps have not yet caught up.
The Current Landscape
The Americans with Disabilities Act and Section 508 of the Rehabilitation Act of 1973 require federally funded institutions to ensure all individuals with disabilities can use online content as effectively as other individuals.
But when it comes to mobile apps and accessibility, there’s much work to be done.
A 2016 article in Digital Information Gazette points out that in terms of making information technology accessible to people with disabilities, websites have received the lion’s share of attention.
“The accessibility of mobile devices and apps is particularly pressing,” according to Dana Marlowe, principal partner at Accessibility Partners, “because of their rampant popularity.” Smartphones are everywhere, as are tablets. At the end of 2015, the Pew Research Center reported that 68% of Americans have smartphones and 45% have tablet computers.
“Mobile technology has sparked a new era of opportunity for people of all ages and abilities, yet many mobile apps have design flaws that prevent people with disabilities and the elderly from using them effectively,” stated IBM Chief Accessibility Officer Frances West in a press release issued by the company when recently releasing its own technology to identify and correct usability issues.
Accessibility in an App
Accessibility in app design can take a variety of approaches. Accessibility Partners recommends the following advice:
An Early Trailblazer
California State University, Northridge has been one of the early leaders in this arena. The school has made a concerted effort to ensure that all information technology resources and services are accessible to all students, regardless of disability. And that effort includes the school’s mobile properties.
What’s more, for the past three decades, the school has been hosting a one-of-a-kind conference on the subject – the CSUN Assistive Technology Conference.
Dedicated to presenting and exploring new ways technology can assist people with disabilities, the “CSUN Conference,” as it has become known, is the only one of its kind sponsored by a university.
“Disability is something that interferes with one or more major life activities. And ten to 15 percent of people meet that definition,” Cal State Northridge’s Kate Sharron pointed out during a talk on the subject at the 2016 Kurogo Higher Ed Mobile Conference.
A senior analyst for web services, Sharron helped launch the CSUN mobile app and spoke at the conference about the importance of universal design that is inclusive of mobile apps.
Some of her design suggestions for mobile apps included putting the app in grayscale, changing how touch works on the phone and also making text larger.
“Universal design will help you reach all students, meeting your students where they are,” added Sharron. “At CSU we take accessibility and universal design seriously.”
The Task Ahead
“Building accessible apps doesn’t have to be tremendously time consuming,” notes a mobile expert to Digital Innovation Gazzette. In fact, many devices have accessibility features available within the operating system.
By many accounts, a small amount of additional design and development time, over what is normally required, can result in a highly usable and accessible app.
In addition, remember to build accessibility into any refreshes, redesigns, or new rollouts of websites or mobile apps.
The big take away here is that universal design and accessibility should no longer be an afterthought or something that’s merely squeezed in during the testing phase.
“Factor accessibility in from the beginning,” urged Sharron at the Kurogo conference. “It shouldn’t be one of the last steps, it should be one of the first.”
When well planned and executed, assistive technology, even something as seemingly straightforward as a mobile app, can transform the lives of people with disabilities.
Reposted from Modo Labs Team
The U.S. Architectural and Transportation Barriers Compliance Board (Access Board) finalized a regulation this week that will make the Web Content Accessibility Guidelines 2.0 (WCAG 2.0) Level AA the design standard when interpreting and implementing Section 508 of the Rehabilitation Act of 1973, which requires federal agencies and contractors to make their websites accessible to disabled individuals. Affected federal agencies and contractors will have one year from the publication of the final rule to comply with the revised 508 standards, which would place the compliance deadline sometime in early 2018.
The Access Board’s adoption of WCAG 2.0 Level AA strongly suggests that the U.S. Department of Justice (DOJ) will likewise adopt that standard when it finally issues its regulations. The process to issue its final regulations is not even projected to start until late 2018. As we have noted in the past, the DOJ and many courts have ruled that the Americans with Disabilities Act (ADA) requires accessibility for the websites of most private businesses even in the absence of DOJ regulations.
In the meantime, the DOJ and federal Department of Education’s Office of Civil Rights have also continued to reach private settlements with various parties that likewise make WCAG 2.0 Level AA the applicable standard for ADA compliance. The takeaway for private sector businesses looking to bring their websites into ADA compliance is that WCAG 2.0 Level AA has now gained further prominence as the most likely standard that a court will look to in determining a website’s compliance with the ADA.
© 2017, Ogletree, Deakins, Nash, Smoak & Stewart, P.C., All Rights Reserved.
According to Google, 1 billion people in the world have disabilities – visually impaired & hearing disabled – who would benefit from an accessibility compliant web site. In addition, people who are not fluent in English, people who have trouble using a mouse, people with temporary disabilities, older people and new users can all benefit from adherence to web accessibility standards.
On January 18, 2017, the United States Access Board published a final rule that updates requirements for information and communication technology covered by Section 508 of the Rehabilitation Act and Section 255 of the Communication Act. To see if your company is at risk, visit the official website: Section508.gov – these new rules go into effect in 2018.
With the potential for increased market share, increased search engine performance, enhanced usability and the positive impact on brand reputation, your company can gain a competitive advantage. Combined with the reduced risk of class action suits, government fines, legal costs and the resulting PR loss, the case for making your web site accessibility compliant is compelling.
Reposted from Morgan Catlin’s blog
Welcome to the third installment of SSB’s four-part review of the differences between ARIA 1.0 and 1.1. In the last post – Differences between ARIA 1.0 and 1.1: Additions to “role” – we explored the additions to “role”. Today, we review the changes that were made to various attributes.
The most recent version of the Accessible Rich Internet Applications (WAI-ARIA) guidelines was published on October 27, 2016. You can view the full document on the W3 website.
The aria-owns attribute can be used to change the order of the accessibility tree, which is important when the DOM element structure of a widget does not match the correct parent-child relationship necessary to make such a structure work correctly. In such cases, the aria-owns attribute can be used to reference the IDs of the elements that are meant to be children of that container element.
The aria-owns attribute will cause the accessibility tree to be reordered, which will be recognized by assistive technologies that support the use of ARIA. In contrast, the use of the aria-owns attribute will not in any way reorder the element structure within the DOM, it only affects the order of the accessibility tree that is perceivable by assistive technologies.
The aria-owns attribute is a global attribute and may be added to any element. However, it is important to note that aria-owns must not be used on elements or roles that do not support children, such as HTML input elements or img elements. The same is true for combobox widgets that use role=”combobox” on an HTML input element, or any use of an HTML input+type=”text” or HTML textarea element, none of which should include the use of aria-owns. This is equally true for active elements such as links or buttons which should never include aria-owns to reference other active elements or container elements that include active elements.
The aria-owns attribute is often confused with the aria-controls attribute, though both are very different. The aria-controls attribute simply conveys an association between one or more elements that are controlled by the first, however, there is no parent-child relationship between these elements. Also, the use of aria-controls does not ever reorder the accessibility tree, only aria-owns can be used to reorder the accessibility tree.
In ARIA 1.0, the use of aria-activedescendant was defined as referencing the ID of a descendant child element to convey the child element as having focus in the accessibility tree, which required a parent child relationship in the accessibility tree according to spec.
In ARIA 1.1 however, the use of aria-activedescendant has been widened in scope to also allow for the referencing of any other element that is not a direct descendant of the focused element, meaning that aria-activedescendant can be used to convey that focus has moved to any other widget type regardless where that element actually is located in the DOM. The caveat being, that aria-activedescendant must point to an element that has an implicit or explicit widget role.
This change is especially important for interactive widgets such as autosuggest comboboxes, where the use of aria-activedescendant on the input control can allow the perceived focus in the accessibility tree to move into an associated Listbox control so that the up and down arrow keys can then change the highlighted option by dynamically updating the aria-activedescendant attribute on the HTML input field. This technique can also be used to traverse associated controls such as date pickers by referencing the date links using aria-activedescendant, which then controls the movement of the date picker using various keys all of which simply update the aria-activedescendant attribute on the focused input element. The same is true when using aria-activedescendant on an input to reference the various role=”treeitem” nodes within an ARIA Tree, so that the arrow keys when pressed will dynamically update the aria-activedescendantattribute on the input in order to convey that accessibility tree focus has moved into the tree even though literal DOM focus remains on the input element.
It’s important to note the difference between accessibility tree focus and literal DOM focus, which are not the same thing.
Literal DOM focus occurs when focus is set to a focusable element in the DOM, such as an active element like a link or form field. The accessibility tree focus however, is what is reported in the accessibility tree as currently having focus. To put this another way, the literal DOM focus reflects the currently focused element in the DOM, whereas the accessibility tree focus reflects only the accessibility tree object that is reported as presently having focus. In the DOM, only one element is allowed to have focus, which is also true in the accessibility tree, where only one accessibility tree object is allowed to be set as focused.
Assistive technologies like screen readers announce the accessibility tree object that has focus, not the DOM element that literally has focus. In practice, both the literal DOM focus and the accessibility tree focus always match, so that the element that has literal focus in the DOM is the same as the accessibility tree object that is announced to screen reader users as having focus.
The aria-activedescendant attribute however, can be used to override this automatic behavior in the browser and instead point to a different accessibility tree object to report as being focused, even though literal focus in the DOM has not moved.
In ARIA 1.0, the use of aria-haspopup could be either set to “true” or ““false”, and its only purpose was to convey the presence of an attached menu when set to “true”. The use of aria-haspopup was only valid when used for this purpose.
In ARIA 1.1 however, the use of aria-haspopup was extended to support a list of token values that can be used to fit a number of different circumstances. These include all of the following:
Also, in ARIA 1.0, the aria-haspopup attribute was not specifically called out as needing to be placed on a focusable keyboard accessible element, however this has been tightened up in 1.1 where it now specifies that the use of aria-haspopup should be placed on a keyboard accessible element where it can be triggered properly.
It’s important to note that none of the token values are supported within browsers or assistive technologies as yet, and likely won’t until the end of 2017 at the earliest.
In both ARIA 1.0 and 1.1, role=”form” is declared as a landmark. However, the assistive technology mappings were changed in 1.1 to cause role=”form” to behave as a landmark, whereas before they did not. This also impacts the implicit role mappings for the HTML form element, which historically do not map to the ARIA form role as expected.
This lack of implicit role mapping for the HTML form element is intended, however, because if it were otherwise, all form elements would be declared as landmarks on all web pages, which would be extremely confusing and non-intuitive. So a compromise was reached, where an HTML form element will only be mapped to the ARIA form landmark role if it includes an explicit name using either aria-labelledby or aria-label. Otherwise, the HTML form element will not be mapped to the ARIA form role as a landmark.
This is the third of a four-part series on the Differences between ARIA 1.0 and 1.1. Please click here for part one and part two. In the next installment, I’ll delve into role=”combobox”. It’s a bit complicated, so it deserves its own post.
Mark Lasser has sued producers of the show, claiming Hamilton is denying blind and visually impaired fans equal access to performances across the U.S. because the show doesn’t offer audio description technology. The service provides patrons with a small receiver that connects to headphones and plays audio narration that describes visual elements of the scenes.
“Many individuals who are blind or visually-impaired enjoy watching musicals in theatres and engaging in this classic part of American cultural life,” writes attorney C.K. Lee in the complaint. “Audio description technology is essential to the live musical experience for blind individuals, so that they will know what is happening in scenes without dialogue or scenes that include significant visual elements.”
Lasser says he contacted the box office at the Richard Rodgers Theatre in New York to inquire about services for the blind and visually impaired and was told none were available. He also claims he tried to resolve the issue without a lawsuit but producers were not responsive.
Nederlander Organization, which owns the theater Lasser contacted; the show’s producer, Hamilton Uptown LLC; and its manager, Baseline Theatrical LLC, are named as defendants in the lawsuit. None of the companies have responded to a request for comment in response to the suit.
Lasser is asking the court to order defendants to provide audio description equipment and live narration services once each week with 25 audio sets available for the show.
A California blind man has won a disabled-rights case against a Colorado-based luggage retailer accused of failing to make its commercial website accessible to the visually impaired.
Lawyers for the plaintiff said the ruling broke new ground in an expanding litigation area.
Edward Davis last year sued Colorado Bag’n Baggage in California court claiming he couldn’t shop online for the retailer’s products because its website lacked features, like screen-reading software, for aiding the disabled. The suit claimed violations of the federal Americans with Disabilities Act and a California anti-discrimination law.
Before any trial, the judge this week ruled for the plaintiff. Mr. Davis “presented sufficient evidence that he was denied full and equal enjoyment of the goods, services, privileges, and accommodations offered by Defendant because of his disability,” wrote Judge Bryan F. Foster of San Bernardino Superior Court.
He ordered the retailer to make changes to its website and to pay $4,000. Lawyers for Mr. Davis are also entitled to attorneys’ fees, which they expect to exceed $100,000.
The lead counsel for the plaintiff told Law Blog that the ruling marked the first time in such a lawsuit that a court has entered a judgment in favor of a plaintiff over a defendant’s objections. “It’s pretty groundbreaking,” said Scott Ferrell, founding partner of litigation boutique Newport Trial Group.
Law Blog has sought comment from an attorney representing the retailer.
Such disability-rights cases have grown more common in the last couple of years.
As WSJ has reported, litigation in the area picked up steam in 2014 when the Department of Justice laid out a set of compliance standards for accessibility on commercial websites as part of a legal agreement with H&R Block Inc. in a case originally brought by the National Federation of the Blind.
Another turning point came in 2008 in a case against retailer Target Corp. when a federal district judge ruled that ADA applies to websites when they act as a gateway to a brick-and-mortar store. That case resulted in a $6 million settlement.
Crystal N. Skelton, a California attorney who advises clients in complying with disability laws, says companies can expect these lawsuits to continue.
“If you aren’t sure whether the ADA applies to your site or whether it’s accessible to the blind, now may be the time to find out,” she and a firm colleague wrote in a blog post about the case.
The most recent Candidate Recommendation of the Accessible Rich Internet Applications (WAI-ARIA) specification was published on October 27, 2016. You can view the full document on the W3 website.
It’s important to note that this document is still subject to change with future publications and that these observations are meant to provide a high-level overview of broad level changes that will be important to be aware of going forward. As such, these details are likely to remain valid regardless. Also, many of these additions are minimally supported or not supported at all by browsers and assistive technologies as yet.
role=table and role=cell
The table roles are meant to handle constructs where a non-interactive data table is needed when the underlying markup does not use a standard HTML table element. This construct is static and is not meant to be interactive in the same way that role=grid is used.
The cell role is only valid within a role=table construct and is not valid within any other construct such as role=grid. The use of the roles table and cell are only valid within a construct that simulates a standard data table.
The role ‘term’ is meant to accompany and explicitly associate role=definition, which was missing in ARIA 1.0.
The attribute role=”term” must never be used on an interactive element, but instead must be used on container elements that include textual content or container elements that surround an interactive element (e.g., a link or button).
When role=definition is used, it must include aria-labelledby to point to the ID of the role=”term” element to explicitly associate the term to which the definition refers.
The role ‘figure’ is meant to surround user-navigable information, which may contain content ranging from graphical images to textual code fragments to mathematical equations. As such, the content of a figure is navigable in the same manner as a named region or landmark.
A figure may be explicitly named using either aria-labelledby or aria-label, or even reference an external caption using aria-describedby.
The role ‘feed’ was added in ARIA 1.1 to provide a mechanism for handling infinite scrolling regions within dynamic feed environments.
The role=feed container acts much like a named region or landmark, though it must only include first-level child roles with role=”article”. The Article role may of course, include any number of other roles and active elements.
Programmatic focus handling must be used to move focus between each role=article element within the role=feed container, and new role=article containers must be dynamically added to the beginning or end of the role=feed container when rendered.
The use of aria-describedby may be added onto each focusable role=article container to automatically announce the desired content within that article when it receives focus.
A focusable button should also be available at the end of the role=feed container that will dynamically load additional role=article elements when activated. This is needed for touchscreen devices and screen readers that use off-screen browse modes.
The role ‘searchbox’ was added to represent the same element type as an HTML input element that includes type=”search”.
The use of role=searchbox must be the only focusable element. This differs from role=”search”, which is meant to be a landmark that includes focusable active elements.
When role=searchbox is used, focus must be set to the role=searchbox element and the content of that element must then be directly editable. Since role=searchbox is a form field in the same manner as role=textbox, it must include an explicit label using either aria-labelledby or aria-label.
The role ‘switch’ was added as a type of simplified checkbox that can only handle two values, ‘false’ or ‘true’ (On or Off). The ‘switch’ role does not support aria-checked=”mixed”, which will default to ‘false’ if detected.
The use of role=switch must never include focusable active elements, but must instead be the only focusable element.
When role=switch is used, focus must be set to the role=switch element, and the spacebar (in addition to onClick) must be available to toggle aria-checked between “false” or “true”.
Since role=switch is a form field in the same manner as role=checkbox, it must include an explicit label using either aria-labelledby or aria-label.
The role ‘none’ was added to act as an alias for role=presentation, and both are the same and perform the same action. This was meant to provide clarity for those who were confused by the word “presentation.”
It was also proposed that role=”” also be available to perform the same behavior as role=”none” and role=”presentation”. However, this presented too many implicit role conflicts within browsers, assistive technologies, and framework development, so role=”” should never be used in place of role=”none” or role=”presentation”.
My Personal Restaurant Reviews
Accelerating XPages Development
Understanding website accessibility and how to achieve compliance under the ADA or Section 508 guidelines
Understanding website accessibility and how to achieve compliance under the ADA or Section 508 guidelines
Looking at emerging technology, mostly O365 right now
Exploring the code that runs the web...xPages and beyond.
An exploration of IBM Notes Xpages development
Stay in Wonderland, and I'll show you how deep the rabbit hole goes...
Vancouver, Washington / Portland, Oregon