Responsive Web Design and Accessibility: Challenges and Solutions
•Descargar como PPTX, PDF•
12 recomendaciones•3,853 vistas
Responsive Web Design is often used as the cure-all solution for web application usability problems - including accessibility. While responsive web design can have a very positive impact on accessibility, there are a couple of issues to watch that can get in the way. This presentation lists common RWD accessibilty issues and their solutions
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Responsive Web Design and Accessibility: Challenges and Solutions
Similar a Responsive Web Design and Accessibility: Challenges and Solutions (20)
Último
Último (17)
Responsive Web Design and Accessibility: Challenges and Solutions
- 1. Responsive Web Design and Accessibility Challenges and Solutions Twitter: @dylanbarrell GitHub: @dylanb dylan.barrell@deque.com http://dylanb.github.io/ http://unobfuscated.blogspot.com/
- 2. The Promise of RWD © 2014 - All Rights Reserved 1
- 3. Example Responsive Site © 2014 - All Rights Reserved 2
- 4. Example Responsive Site © 2014 - All Rights Reserved 3
- 5. The Promise of RWD © 2014 - All Rights Reserved 4 • Opportunity to: – Add support for all devices – Maintain a Single Code Base – Modernize – De-Clutter the UI – Use Semantic Markup – Achieve Accessibility
- 6. Things To Watch © 2014 - All Rights Reserved 5 • Keyboard • Tables • Focus • Zooming • Style Sheets • Gestures • ARIA differences
- 7. Keyboard © 2014 - All Rights Reserved 6 • iOS does not send JavaScript events for – LEFT, UP, DOWN, RIGHT – (caveat, have not tried 7.1) • ARIA Authoring Guidelines require arrow keys
- 8. Keyboard © 2014 - All Rights Reserved 7 • iOS does not send JavaScript events for – LEFT, UP, DOWN, RIGHT – (caveat, have not tried 7.1) • ARIA Authoring Guidelines require arrow keys Use standard HTML 5 input types Use gestures Insert dynamic content inline (screen reader hints) Scale the widget to fit the screen
- 9. Data Tables © 2014 - All Rights Reserved 8 • 3D tables do not work on iOS • 2D headers (th) only first row and column in iOS • headers attribute does not work on OS X/iOS
- 10. Data Tables © 2014 - All Rights Reserved 9 • 3D tables do not work on iOS • 2D headers (th) only first row and column in iOS • headers attribute does not work on OS X/iOS Try to redesign the UI (e.g. use lists instead) Try to keep data tables to 2D Use scope attribute on 2D tables
- 11. Responsive Tables © 2014 - All Rights Reserved 10 • Unless you do something, responsive data tables will be inaccessible – Data table algorithm does not work without display:table
- 12. Responsive Tables (soln. 1) © 2014 - All Rights Reserved 11 @media (max-width: {breakPoint}) { /* Force table to not be like tables anymore but still be navigable as a table */ table, thead, tbody, tr { width: 100%; } td, th { display: block; } /* Hide table headers with display: none because accessibility APIs do not pick up reliably on these headers anyway */ thead tr { display:none; } tr { border: 1px solid #ccc; } td, th { /* Behave like a "row" */ border: none; border-bottom: 1px solid #eee; position: relative; } }
- 13. Responsive Tables (soln. 2) © 2014 - All Rights Reserved 12 <table role=“grid”> </table>
- 14. Focus © 2014 - All Rights Reserved 13 • iOS will not focus dynamically inserted elements consistently – Element must be in the DOM and “visible” for about 1 second in order to consistently receive focus Write a focus utility that uses setTimeout()
- 15. Zooming © 2014 - All Rights Reserved 14 • Auto zoom can make touch to explore difficult • Sighted users need to be able to zoom – 200% the absolute minimum for WCAG 2 AA
- 16. Zooming © 2014 - All Rights Reserved 15 • Auto zoom can make touch to explore difficult • Sighted users need to be able to zoom – 200% the absolute minimum for WCAG 2 AA Use 19pt or bigger for all form fields Use em instead of px/% Do not use meta viewport maximum
- 17. Style Sheets © 2014 - All Rights Reserved 16 • Multiple break points mean multiple tests – Need to replicate all your accessibility testing for each size – Adding a high contrast style sheet multiplies this • Content positioned off screen is still visible to screen readers
- 18. Style Sheets © 2014 - All Rights Reserved 17 • Multiple break points mean multiple tests – Need to replicate all your accessibility testing for each size • Adding a high contrast style sheet multiplies this • Content positioned off screen is still visible to screen readers Make your main style sheet high contrast Use automated tools for testing Use display:none for hidden content
- 19. Gestures © 2014 - All Rights Reserved 18 • Screen Readers intercept gestures • VoiceOver has a gesture pass through mode – 10 gestures • Zoomed screens’ gesture velocity is different
- 20. Gestures © 2014 - All Rights Reserved 19 • Screen Readers intercept gestures • VoiceOver has a gesture pass through mode – 10 gestures • Zoomed screens’ gesture velocity is different Use 19pt font to avoid auto zoom Detect zoom Simplify interaction
- 21. ARIA differences © 2014 - All Rights Reserved 20 • ARIA support is still quite variable – aria-expanded – aria-live – dynamic roles • Bad examples – http://alistapart.com/article/accessibility-the-missing- ingredient
- 22. ARIA differences © 2014 - All Rights Reserved 21 • ARIA support is still quite variable – aria-expanded – aria-live – dynamic roles • Bad examples – http://alistapart.com/article/accessibility-the-missing- ingredient Test everywhere Use a compatibility/component library (a11yfy)
- 23. Questions? Twitter: @dylanbarrell GitHub: @dylanb dylan.barrell@deque.com http://dylanb.github.io/ http://unobfuscated.blogspot.com/ © 2014 - All Rights Reserved 22
Notas del editor
- Here you can see the desktop view of a site that I worked on with Travis Marasca and Brian Dillon from Basic Semantics. This is the site that won the most recent Knowbility Open AIR challenge. You can see at the top a nicely sized logo of the Dominion School for Autism, to the right of that is the search input and below the search is the top-level site navigation. The main page header appears below that “Helping Children Reach Their Fill Potential” followed by the main content which has a three column layout.
- If you switch into an iPhone, then you will see that the same content and capabilities are there, but they have been adapted to fit the capabilities of the screen. The icon has been scaled to better fit this screen resolution. The search input has been replaced with a button that shows and hides the search input. The top navigation has been replaced with the (now ubiquitous) hamburger icon which pops up a navigation popup menu and the three column layout has been serialized into a single column.
- Responsive Web Design promises a lot of benefits and delivers quite well on most of these, it is often also used as an “easy sell” for development organizations that want to improve accessibility but cannot “justify” it along traditional ROI routes. If done right, RWD can get you a long way towards an accessible web application/site but there are some things that are not quite straightforward…
- This list represents the categories of items that can cause problems. I will be going into each of these in a bit more detail.
- The problem is that on iOS, the keyboard key down and key up events do not get delivered to the JavaScript event handlers. ARIA widgets rely on the use of the arrow keys. This means that any complex widgets like tabs, menus, date pickers and the like will not work on iOS with a keyboard attached. This makes iOS of limited use for keyboard-only users and introduces some difficulties for blind users as well.
- Although the HTML 5 input types are not all accessible today on all platforms, they are implemented accessibly on all major mobile platforms and offer the most reliable way to get accessible input for things like Date picker widgets, time etc.They also provide a consistent user interface to the users that the users will be familiar with. Use the HTML 5 input types (conditionally) for mobile platforms.If you have to create a complex widget, then map arrow keys to gestures if possibleInsert content inline and manage focus to ensure that a touch to explore strategy can be used to access the content.Scale and position the widget by default so that it fits completely on the screen to support touch to explore
- 3 dimensional tables (are tables where one or more cells have 3 or more other cells that serve as headers)On desktop operating systems such as Windows and OS X, there are mechanisms to mark up table cells in such a way that all the relevant information is read out to screen reader users as they navigate these tables.On iOS, there is currently no support for 3D tables at all and iOS only reliably supports 2D tables where the first row and first column are the column and row headers respectively. You must also use the scope attribute to make this work reliably.On OS X, there is no support for the headers-id association markup for 3D tables.
- The first solution is to see whether the table can be redesigned to make use of some other markup mechanism. Sometimes a search UI can serve as a better interface for finding data that is otherwise presented as a table. Case in point is a bus schedule.Where tables must be used, try to change the 3D tables to a collection of 2D tables instead. Simplify these tables to make sure that the first row and/or the first column serve as headers.Where this is not possible, conditionally markup the tables so that there is a solution for each platform. For OS X, this means using the ARIA grid role and related roles and attributes. For iOS, this means using off screen text.
- This first solution uses some tricks to make the table flow responsively while still allowing for table navigation by a screen reader.TO make use of this, look at the a11yfy jQuery library as it has utility functions that will flow these tables as the breakpoints are traversed within an application.
- Another solution is to apply the ARIA grid roles to the responsive table. This will force the screen reader to regard the table as a table independently of the display property
- On iOS, if you dynamically insert or show and hide content, then focus cannot be placed into that content unless the content has been in the DOM AND visible for around 500ms. The solution for this is to create a utility function that places focus into the element you want focus to be placed into after waiting 1000ms on iOS and immediately on all other platforms.The a11yfy library has an example of such a utility function for jQuery
- When the focus goes into a form field, iOS and other mobile platforms will automatically zoom the screen to allow a sighted user better visibility into what is being entered into the screen.This, in addition to the situation where a user has zoomed into an application to a very high level will cause the events delivered to the event handlers for the gestures to deliver information that make it appear as though the user’s swipes are “slower” or not as long.This can cause problems in applications that require gestures or in applications that require touch to exploreAlso, disabling the zoom for applications using the meta viewport attributes will stop sighted users from zooming into the application to a level that is comfortable for them
- The solution to the auto zoom is to use 19pt or bigger for all form fields, this will stop the OS from auto zoomingUsing ems instead of pixels for the break points will allow a user to use the browser zoom function to zoom in and trigger the responsive break points. This allows sighted users who require a large zoom level to take advantage of the responsiveness, even on desktop or other large sized displaysDo not use the maximum-scale attribute in the meta tags and do not disable user scaling
- Each break point requires you to test the entire application (or at least all the pieces of the UI that are different) for both functionality and accessibility.If you add special style sheets for high contrast requirements, then this will multiply the amount of testing required by a factor of how ever many breakpoints you have for each additional style sheet.Sometimes style sheets will hide content that is intended to be invisible using an off screen technique instead of display:none.This means that a keyboard only and/or screen reader user will still have to traverse that content in order to get to the content that is supposed to be the visible content.The opposite problem also can occur - hiding content with display:none when it should really be accessible to a screen reader
- Making sure that your main style sheet adheres to WCAG 2 level AA in terms of color contrast and also ensuring that users can use their own styles for text and background will minimize the amount of testing that you need to performAutomated testing tools can significantly reduce the amount of testing where you are forced to provide many different break pointsEnsure that you use display:none for really hidden content and create specific styles that are very explicit in what they are to be used for E.g. hidden and sr-visible
- As mentioned earlier, the gesture distance and hence the velocity calculated by event handlers is different on zoomed screens. This can cause problems for applications that rely on gestures. This affects all users but will be more problematic for blind users who will nto be aware of the auto zooming.
- ARIA support, while increasing almost daily, is still quite varied.In particular, there are problems with aria-expanded not being widely supportedAria-live has some quirks which, if not followed, will cause it to either not work or generate confusing announcements on certain platforms. iOS is one platform where aria-live can simply not work if not implemented correctly, whereas JAWS can make confusing announcements when content is deleted
- The general approach to ARIA is – before you use a technique, make sure you, or another accessibility expert has tested it on all the required platforms. There are a lot of ARIA examples on the Internet that do not work in a cross-platform way.Once you have implemented something, put it into a library so that you can re-use the tested cross-platform code without having to worry about re-implementing the fixes for quirks