Archive index

A11y Slackers Gitter Channel Archive 22nd of February 2017

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    @zakim-robot
    Feb 22 05:48
    [caesar] Q: how should we diagnose an issue where NVDA is reading aria-expand changes correctly in Chrome but not in Firefox? In FF the read is inconsistent and often skipped.
  2. zakim-robot
    @zakim-robot
    Feb 22 09:38
    [damoberg] To fulfil WCAG 2.0 AA, do you need to provide a site that has complete functionality when no javascript is used?
  3. Fiona Holder
    @FionaHolder
    Feb 22 09:39
    @damoberg No, it's not a requirement of WCAG 2.0
  4. zakim-robot
    @zakim-robot
    Feb 22 10:18
    [damoberg] @fionaholder So in regards to progressive enhancement, were you start off with a site that functions somewhat without javascript, and add more functionality when there is javascript support - you don't have to make sure that each progressive enhancement step is accessible?
  5. zakim-robot
    @zakim-robot
    Feb 22 11:42
    [michiel] seanus1138: I agree with you, that does make more sense to me. I’ll see if I can find the logic behind that decision
  6. zakim-robot
    @zakim-robot
    Feb 22 11:55
    [michiel] seanus1138: an initial though: most of the APG interactions are based on desktop OS interactions. The menu you refer to comes from Windows, where you can indeed only tab to one item and then have to move with the arrow keys.
  7. [michiel] On macOS you can tab to all main items and move through them with the arrow keys, expanding them when you press down arrow or right arrow to open a sub menu.
  8. [michiel] Because they’re the same when it comes to arrow key navigation I prefer the macOS implementation as it makes more sense to me.
  9. Fiona Holder
    @FionaHolder
    Feb 22 12:33
    @damoberg Not actually sure in that case, I'd be tending towards saying that you'd have to make sure each step complies. Not sure if anyone else has a more formed opinion?
  10. This seems to back up my view: "To conform to WCAG 2.0, you need to satisfy the Success Criteria, that is, there is no content which violates the Success Criteria."
  11. zakim-robot
    @zakim-robot
    Feb 22 13:31
    [michiel] I agree with Fiona, if you go through the trouble of making it progressively enhance, why not also make those accessible?
  12. zakim-robot
    @zakim-robot
    Feb 22 15:54
    [cameron] friends! how does one display visual focus outline or highlight in JAWS (17)?
  13. [conley] I would think that should be done vis CSS
  14. [conley] and not rely on the AT to provide that
  15. zakim-robot
    @zakim-robot
    Feb 22 16:09
    [cameron] @conley yes, keyboard focus is handled with CSS. Good call! I'm talking about the screen reader cursor.
  16. [cameron] voiceover shows screenreader focus by outlining elements on the page
  17. [cameron] wondering if JAWS (or NVDA) have a similar feature
  18. [conley] In my experience they dont
  19. [conley] VO's outline can be hit or miss as well
  20. [conley] like if the page scrolls without its knowledge the outline is all over the place
  21. zakim-robot
    @zakim-robot
    Feb 22 16:17
    [cameron] oh neat, there's an NVDA plugin that supports this https://twitter.com/NVAccess/status/400091602216964096
  22. [marcysutton] I was about to comment with that link! Haven't used it yet though
  23. [cryberg] Hi all! Are there any good blog posts or resources out there about how to ensure a Terms of Use modal is accessible? The main concern is that the user has to scroll to the bottom of the text to enable the "I agree" button in the footer.
  24. zakim-robot
    @zakim-robot
    Feb 22 16:22
    [marcysutton] As long as it has overflow:auto with a scrollbar it should be fine with the regular approach https://www.marcozehe.de/2015/02/05/advanced-aria-tip-2-accessible-modal-dialogs/
  25. [marcysutton] That way the arrow keys will work (or TAB)
  26. [cryberg] So there's no need to provide instruction anywhere explaining that all content needs to be read before the "I agree" button will be enabled?
  27. zakim-robot
    @zakim-robot
    Feb 22 16:28
    [marcysutton] Ah, yeah that would probably help. :)
  28. [marcysutton] But that's more of a usability thing than accessibility necessarily
  29. [cameron] @marcysutton that plugin works great btw
  30. [michiel] More information on accessible modal dialogs: http://w3c.github.io/aria-practices/#dialog_modal
  31. [cryberg] @marcysutton Fair enough. I guess I'm not sure what the experience is like for screen reader users when they encounter a Terms of Use in a desktop, and I'd like to make tis web version as similar to that as possible
  32. [cryberg] If they don't expect to hear instructions about what enables what buttons, then that's good to know
  33. [marcysutton] I'd think a heading with "Terms of Use" and a line of text below it saying you have to "read" it all would be sufficient.
  34. [marcysutton] I put "read" in quotes because we all know how that goes. haha.
  35. [cryberg] haha yeah
  36. [cryberg] "quickly skim to the end"
  37. [michiel] “Scroll to the end of the page to enable the ‘agree’ button”
  38. [michiel] Or, y’know, not have such a requirement :P
  39. zakim-robot
    @zakim-robot
    Feb 22 16:33
    [cryberg] It's a legal requirement :( we have to say that we required all the content to be "read"
  40. zakim-robot
    @zakim-robot
    Feb 22 16:39

    [gokatgo] marcysutton: Not in this case.

    Our end users have all their machines set to English, and there are cases where we’re serving up lessons in one language for a few lessons, and may switch to a different language in a separate lesson.

    In our case, we’re serving up our lessons in ePub3 files, and have assessments embedded in the lessons via iframes. The ePubs have a language attribute set in the metadata of the content.opf file.

    So… depending on the language attribute we set in the ePub determines the language of the assessment we’ll be embedding in that ePub. Because of this, we’ve had to localize much of the UI elements.

  41. zakim-robot
    @zakim-robot
    Feb 22 17:26
    [garcialo] @damoberg @fionaholder It needs to be accessible at each step.
  42. zakim-robot
    @zakim-robot
    Feb 22 17:42
    [damoberg] @garcialo Does that mean that a site which requires javascript isn’t accessible?
  43. [conley] http://webaim.org/techniques/javascript/#reliance
  44. [conley] >...WCAG 2.0 and all other modern guidelines allow you to require JavaScript, but the scripted content or interactions must be compliant with the guidelines.
  45. [damoberg] @michiel One guideline is that you should provide the same experience to all users, and that is impossible when there is no javascript usage, for advanced features that is.
    I agree with Fiona, if you go through the trouble of making it progressively enhance, why not also make those accessible?
  46. zakim-robot
    @zakim-robot
    Feb 22 17:49
    [susanjrobertson] reupping this from yesterday, does anyone have recommendations on making a multi select work for all? https://web-a11y.slack.com/archives/general/p1487712234003671
  47. [damoberg] @conley It doesn’t get more clear than that, thanks!
  48. [conley] np JS is pretty much ubiquitous as this point
  49. [garcialo] Otherwise what’s the point? To say otherwise would allow one to say “it’s accessible...if you disable everything that makes all the cool features we have work."
  50. zakim-robot
    @zakim-robot
    Feb 22 18:00
    [damoberg] I guess that you would have to remove features to meet the least common denominator. For example to get to AAA level you can’t have certain features, even with javascript.
  51. zakim-robot
    @zakim-robot
    Feb 22 18:10
    [michiel] My point was, you can have a progressively enhanced tabs widget that starts out life as a bunch of headings and content and change that into tabs. It would be accessible with and without JavaScript.
  52. [michiel] Of course that doesn’t apply to all features/components/what have you, but it certainly does to some.
  53. [michiel] susanjrobertson: there is some advice that might be useful in the deleted pages of the APG: https://rawgit.com/w3c/aria-practices/master/aria-practices-DeletedSectionsArchive.html#combobox
  54. [michiel] Be aware that this is very old advice and might be out of date.
  55. [damoberg] For me it was one thing to make the non-js version accessible/usable, and a different beast making it follow the same WCAG level as the enhanced site.
  56. [michiel] It might contain something useful though.
  57. zakim-robot
    @zakim-robot
    Feb 22 18:26
    [susanjrobertson] thanks michiel, yeah, i've seen some of that
  58. [susanjrobertson] the hardest part is getting the keyboard interactions right, we're trying to write up a guide and then build based on that
  59. zakim-robot
    @zakim-robot
    Feb 22 19:00
    [davidakennedy] @susanjrobertson Not sure if you’re looking into using Select2, but if you look into it, the WordPress Accessibility team did a lot of testing on it for possible inclusion in WordPress. See: https://make.wordpress.org/accessibility/2015/09/07/accessibility-usertest-select2/ and select2/select2#3744 All that might help. :)
  60. Jason Day
    @jasonday
    Feb 22 20:36
    @susanjrobertson - multi-selects are bad UX for everyone
  61. In our testing, users don't understand how to use them and almost always do a single select
  62. visual affordance may help indicate multi-select (a checkbox), but the operability is still an issue
  63. zakim-robot
    @zakim-robot
    Feb 22 20:57
    [susanjrobertson] thanks davidakennedy, we have looked at select2
  64. [susanjrobertson] @jasonday we have clients who repeatedly ask for them, so we'd rather work on trying to make them better for people than just say no or lose the battle completely and the select2 does give visual affordance, but nothing to help keyboard users get in and out easily and the voice over is odd
  65. zakim-robot
    @zakim-robot
    Feb 22 21:33
    [dylanb] Looking for a way to contribute to Open Source but aren’t a developer? dequelabs/axe-core#20
  66. [dylanb] Looking for information on actual SVG image support so we can improve the rules