Building a better, accessible web
Detailing why accessibility matters, the types of disabilities there are/how to cater for them, and how to write good, semantic HTML and utilise ARIA to create accessible, robust web applications
Slide deck at source…
Adaptable, interactive and coherent prototypes for users with disabilities. Covering accessibility in the prototyping phase of web and app design.
Pay close attention to color, contrast and visual hierarchy
Make your interactive UI elements more interactive
Don’t crowd me!
Make your app accessible by being adaptable
“Flexibility is the key to ensuring that your website is accessible to everyone.” Shaun Anderson, Hobo Web
Prototyping responsive design is actually pretty easy. With Justinmind prototyping tool, it really only involves creating a set of screens of different sizes (to represent the different screens sizes that your users use), adding the content to each screen, and adding linking events between the screens. In fact, we’ve created a nifty tutorial in our Support section to teach you step by step.
Don’t forget the user testing
Curated by (Lifekludger)
Read full article at Source: Prototyping accessibility in web and mobile UI design
Websites with standards-compliant code all follow the typical W3C standards. But there’s a whole different level of compliance when it comes to WCAG, also known as the Web Content Accessibility Guidelines.
The same people who produce the HTML5/CSS3 specs organize and officiate these guidelines, so it’s truly an international system of coding standards. Most web developers never bother with WCAG accessibility, but it’s becoming a huge aspect of the internet.
If you’re looking to understand accessibility or just want to delve a bit deeper into the subject, then this guide is for you. I’ll explain some basics of WCAG conformance for a beginner, along with all the tools and resources you’ll need to keep learning along the way.
Curated by (Lifekludger)
Read full article at Source: The ultimate guide to web content accessibility – InVision Blog
Accessibility QA starts with broadening your frame of reference and understanding what it’s like to use a computer in unfamiliar ways. With that understanding, we can dive into actual testing.
The usual starting point is to read the Web Content Accessibility Guidelines (aka WCAG), which define the current accessibility standard. (The older Section 508 standard is relevant only for government sites.) But good luck understanding WCAG on first glance.
WCAG is broken into three levels (A, AA, AAA); four principles; 12 guidelines; and 61 success criteria. It’s hard to make sense of WCAG’s multi-layered categorization, jargon, and sheer number of items.
The good news: You don’t have to worry about all that to get started. Instead, I find it easier to think in terms of these broad goals:
- Goal 1: People who don’t use a mouse should be able to use and understand a site.
- Goal 2: People who don’t look at a screen should be able to use and understand a site.
- Goal 3: A site’s content should be visually legible.
- Goal 4: People should have access to alternate versions of video and audio content.
- Goal 5: People should have control over automatic changes to the page.
If you’re nervous about doing accessibility QA for the first time, I’m with you. Thanks to Jeremy Fields and others, I had multiple background sessions — but I still felt lost when it came time for real testing.
Don’t sweat it; a11y testing is straightforward once you understand a few foundational concepts. Here’s my two-part guide to accessibility testing so you can help make your sites as inclusive as possible. (Here’s Part 2.)
Start by experiencing how people use a computer differently than you: with a keyboard (no mouse) and screen reader.
Compared to other public spaces, the internet provides us with choices for how we consume and interact. We can use various devices, browsers and operating systems; we can change the size and colour of text; we can navigate with a mouse, keyboard, finger or mouthpiece; or we can use a screen reader to convert words to sounds.
Whatever your needs or preferences, there’s almost certainly a way to access the web.
Theoretically.In reality, the web is a mess.
These accessibility options tend to be forgotten or stripped away, even though accessible websites and apps can absolutely still be beautiful, innovative and user-friendly.
This is more than an inconvenience. This is a human rights issue. Disabled people need these options in order to access the web.
Here are my thoughts on how we got into this mess, and what we can do.
A Web for Everyone: Accessibility as a Design Challenge
Date: This event took place live on January 21 2014
Presented by: Whitney Quesenbery
Duration: Approximately 60 minutes.
Curated by (Lifekludger)
Read full article at Source: A Web for Everyone: Accessibility as a Design Challenge – O’Reilly Media Free, Live Events
. Although accessibility is mainly a developer task, sometimes the technical requirements required to preserve or enhance accessibility will affect the appearance of the website.
That means that design, copy, user experience and development all need to collaborate to make sure that navigation controls, forms, buttons, headings, buttons, links, and more are accessible.
People who are blind, visually impaired, illiterate or learning disabled use assistive technologies to navigate the Internet. Screen readers are the most common assistive technology for the web, these software programs attempt to interpret what is displayed on the web page and convey it to the user, usually through converting the text to speech but sometimes through a Braille output device. Screen magnifiers are also often used in conjunction with a screen reader. Typically a screen reader will attempt to parse the HTML from the top of the HTML file to the bottom and speak relevant elements to the user. Ideally the screen reader will allow the user to successfully move a virtual cursor down the page in order to fill out form fields, click buttons and make selections from drop-down menus and other controls.
To test thoroughly for accessibility you’ll need to ensure that the website or app performs well on each of the many screen readers available. There are several popular free and/or open source screen readers on each platform including JAWS, and NVDA.
Most web accessibility problems occur when the screen reader’s virtual cursor becomes trapped in a poorly designed form or skips over an important control or an important piece of textual information. Verifying that websites are indeed usable is similar to browser testing because each screen reader has different requirements and limitations. This is why understanding the behavior of each screen-reader is important. The needs of various screen readers can be accommodated by adding various special HTML tags to the important elements of the page.
This fall, the Department of Justice postponed its proceeding to adopt regulations on web accessibility for a few more years.
The prolonged delay in those regulations has created a perfect storm for more litigation under the Americans with Disabilities Act (ADA). As a result, many companies should be adding web accessibility to their list of top priorities for 2016.