Continued from Part 1.
Part 2: How to Conduct a Basic Accessibility Audit on Your Site
In case you missed it, catch up on Part 1 of How to Conduct a Basic Accessibility Audit on Your Site.
In this post, we are going to learn how to do keyboard, screen reader and automated code testing.
Testing with a keyboardUnderstanding how people might be using your site with assistive technology is a great way to gain empathy and insight into the impacts of poor accessibility.
Remember that some people may not be able (or not want to!) use a mouse, due to motor impairments or personal preferences. Navigating by keyboard takes some practice. The basics are:The tab key moves forward through interactive elements on the page and shift tab moves backwards.Using the enter key should select a link or button.The arrow keys should navigate within dropdowns.
The space bar works with form controls for example checking or unchecking a checkbox.Gov.uk has a skip to main content link and a clear visual focus state when using a keyboard.
To run a keyboard test on your site:Go to your site.
Unplug your mouse – you are not allowed to use it. No cheating!
Hit the tab key to get started.
Do interactive elements have the same functionality as they do when using a mouse?
Is the order of the focus states logical?
As you get the hang of keyboard navigation, you will learn how important the order of focus states is, as well as discovering interactive elements which don’t function well. A common problem is a ‘keyboard trap’ – where you cannot move away from an interactive element using the keyboard alone.
Curated by (Lifekludger)
Read full article at Source: Part 2: How to Conduct a Basic Accessibility Audit on Your Site : Adobe Dreamweaver Team Blog
Part 1: Visual Accessibility and Manual Code Inspection
Accessibility is really important: Accessibility benefits everyone. By paying attention to accessibility you will improve the UX of your site for all of your users.Making sure your site is accessible expands your customer base. People with a range of disabilities make up a significant portion of the buying power.It’s the right thing to do – designing and developing with an eye to inclusivity means that we value and respect all users and people equally.
There are legal imperatives. More and more legislation is coming into play that mandates accessibility, particularly in the transportation and technology sectors.
It can seem overwhelming, but there are a few simple things you can do to evaluate your site’s accessibility. Many different types of people need to use the web. Not everyone is using technology in the same way. It is crucial to design for a range of abilities and assistive technologies, to make sure that people do not experience barriers to using your site.Web accessibility is a deep and important topic, and there are people and companies who specialise in it. The WCAG 2.0 guidelines are considered the industry standard in accessibility, but these can feel overwhelming! Each guideline has three levels of success criteria, A, AA and AAA. The level of compliance that is legally required varies depending on where you are based and the sector.
As a rule of thumb for getting started, aim for level AA. For this post, let’s look at some of the easy ways to get started with some basic accessibility auditing on the sites you design and develop.
Part 2 continues here
Curated by (Lifekludger)
Read full article at Source: Part 1: How to Conduct a Basic Accessibility Audit on Your Site : Adobe Dreamweaver Team Blog
Our first major decision in implementing our Adobe.com mega menu was to respect user expectations for global navigation. As an accessibility engineer, it’s tempting to want always want to implement the appropriate WAI-ARIA design pattern for the widget I’m developing. In this case, working on a menu, I looked to the WAI-ARIA Menu or Menu bar (widget) design pattern which describes the keyboard interaction and WAI-ARIA roles, state and properties for a list of links presented “in a manner similar to a menu on a desktop application.” This would seem to fit the bill, but it’s somewhat problematic when implemented in its entirety for global navigation.
The design pattern specifies that the menu be treated as a single stop in the tab order, after which the arrow keys move between the menu and submenu items. This is the way application menus behave in desktop applications, and it improves accessibility for keyboard users because only one tab key press is required to move from the menu to the next focusable element in the application. However, for global navigation, we feel that most users still expect to be able to tab to at least the top level links in the navigation, and that the discovery of a jump in focus from the second link in the site to the search input, skipping all other top-level navigation items, could be confusing and would require unnecessary explanation.
curated by (Lifekludger)
Read full article at Source: Mega menu accessibility on adobe.com « Adobe Accessibility