Archive index

A11y Slackers Gitter Channel Archive 21st of February 2017

What fresh hell is THIS now? - Patrick Lauke
  1. powrsurg
    @powrsurg
    Feb 21 14:32
    Aside from a series of focusable items that are next to one another, is it possible to apply will-change to any elements?
  2. keyboard only that is
  3. zakim-robot
    @zakim-robot
    Feb 21 15:37
    [quidkid] My account manager wants to know whats the legal minimum requirement to fulfill the accessibility requirement? like 80% accessible. I responded saying i don’t think it works that way given that 80% of SSB Bart findings could be different from another company. but she has a point that now from a business standpoint, we have 3 unresolved issues from the report that even the experts don’t have an answer for how to solve regarding screenreader conflicts for specifically firefox for a specific screenreader and only that instance
  4. [quidkid] where do we draw that line?
  5. zakim-robot
    @zakim-robot
    Feb 21 15:48
    [michiel] quidkid: you can’t realistically make something a 100% accessible. That said, it all depends on the issues at hand. Perhaps there is another way to include something on a page, a different design pattern, what have you.
  6. [quidkid] @michiel true but from a business standpoint, where do we draw that line?
  7. zakim-robot
    @zakim-robot
    Feb 21 15:53
    [dralusde] @quidkid, this becomes risk assessment, and the answer will be different for every organization. The legal minimum requirements can often be found in the regs and laws. However, your organization
  8. [quidkid] We need to abide by WCAG AA
  9. [quidkid] but do we have to meet all of WCAG AA?
  10. [dralusde] Yes
  11. [dralusde] To be complaint, you have to.
  12. [michiel] You can’t cherry pick the rules you want to follow.
  13. [dralusde] Sounds like your account manager is looking for an out/excuse to say it doesn’t matter if you don’t fix the last three issues.
  14. zakim-robot
    @zakim-robot
    Feb 21 16:00
    [dralusde] There are some exceptions built into the US laws, but courts have tended to scrutinize their use very closely
  15. [quidkid] Because of this I think we will have to alter our website designs going forward to be less complex in order to reduce the costs for remediation.
  16. [dralusde] That is often a really good idea, and can often make the site work better for everyone.
  17. [dralusde] You can then focus the complexity where it gives a real benefit.
  18. zakim-robot
    @zakim-robot
    Feb 21 16:05
    [quidkid] the hard part now is remediating the already animation heavy, complex design websites we have made for the client before accessibility came into play.
  19. [quidkid] from the developer standpoint, given how long it is taking me to figure out certain fixes with animations, it is quicker, cost effective for me to just scrap the animation. Granted, I personally want to try and figure out the way to keep it and make it accessible but we’re running out of paid hours
  20. powrsurg
    @powrsurg
    Feb 21 16:26
    I would argue that your requirement is to fulfill WCAG 2.0 AA spec (or 508, but that was just updated to basically be WCAG). Screen reader conflicts you should work to resolve just like you would browser bugs, but failing to do so shouldn't put you at risk for litigation (again, assuming the spec was fulfilled).
  21. or at the least should minimize risk
  22. I feel the #1 most common thing that modern web design will need to alter as they move to become more accessible is color contrast. I don't know why so many sites these days seem to really hate readable text. I have good vision and I have trouble reading many sites these days. Did someone mess up the initial bootstrap design or something?
  23. zakim-robot
    @zakim-robot
    Feb 21 16:38
    [quidkid] in that case do I need to solve these last few issues? the first one, I had an aria solution but the non-aria solution screwed with the animation. Another issue was closing a menu on Android Mobile with TalkBack. it works with Chrome but not firefox. -__-” and then something specifically in iOS there is an issue with an SVG.
  24. [quidkid] they are all very specific
  25. zakim-robot
    @zakim-robot
    Feb 21 16:56
    [shawn.henning] Am I correct in thinking that the best approach is to conform to WCAG; AA and target specific browsers? If your website does not support certain browsers for any users then it shouldn't be an issue. It may be that Opra, for instance, "works" for some users, but if it does not work with a specific assistive technology that you explicitly note you do not support that should be enough.
  26. [quidkid] ^sorry im not really sure what you mean? the client wants us to support all mainstream browsers.. IE, Chrome, Firefox
  27. zakim-robot
    @zakim-robot
    Feb 21 17:04
    [shawn.henning] Then charge them for each additional browser and make support a cost.
  28. [shawn.henning] I think it is also reasonable to say best with "insert specific assistive tech combinations here".
  29. [shawn.henning] In my experience Firefox plus Voice Over on Mac is poor and not going to be a good experience in current versions. So I am not sure the cost is worth it to support when Safari is always going to be available on macOS.
  30. [shawn.henning] I would love to hear how others in this group approach this dilemma. Obviously conforming to WCAG at the specified level is mandatory, but support of all possible browser plus assistive tech is not reasonably possible, so you have to target.
  31. zakim-robot
    @zakim-robot
    Feb 21 17:19
    [marcysutton] I have always prioritized known combinations and not worried about the others. But they should be explicitly called out in docs
  32. zakim-robot
    @zakim-robot
    Feb 21 17:29
    [shawn.henning] That is my feeling as well. If you start getting a lot of bugs for a combination you did not expect you can evaluate the value to fix or add to the supported list. Every day an update to a browser, OS, or assistive tech potentially breaks or fixes something so you have to manage that risk somehow.
  33. zakim-robot
    @zakim-robot
    Feb 21 17:57
    [quidkid] @marcysutton what are those known combinations? where can I find these docs?
  34. [quidkid] and thank you so much everyone for helping me out. it’s been quite stressful as I’m just newbie developer and the only one who is working on building a remediation process
  35. [marcysutton] They would be docs created by your organization. Browser versions could be rooted in analytics, and then the ATs that pair best with those browsers. JAWS + IE (versions matter here), NVDA + Firefox, Safari + Voiceover, iOS Safari + Voiceover, Chrome and TalkBack or Firefox and TalkBack
  36. [marcysutton] That way users know what you support
  37. [quidkid] Alrighty so if i mention this to management, they are going to tell me to come up with docs. So how should i go about doing that? are those listed combos the known and established convention or is this something customized per organization
  38. [marcysutton] Those are pretty well-known combinations. But how far back you go in IE could depend on your analytics
  39. zakim-robot
    @zakim-robot
    Feb 21 18:02
    [marcysutton] There are also multiple versions of JAWS. But you have to draw the line somewhere, I usually focus on the latest versions of things
  40. [quidkid] “depend on your analytics” im not quite sure what this is referring to
  41. [marcysutton] Does your analytics show users in IE6?
  42. [marcysutton] How many? How much effort/cost are you willing to cover for that number of users?
  43. [marcysutton] There are no analytics for ATs. But your browser analytics can help point you in a direction
  44. [quidkid] ohhhh i see.. i think that information comes from the client who asks us to build the site. I know right now they are using IE 11 but they are a healthcare insurance company so they always ask to be as far back compatible as possible since we don’t know what older users are using
  45. [quidkid] we probably have a greater number of older users
  46. [marcysutton] From a cost perspective those versions have to be explicitly called out so they make the cut. You can't magically test and cover everything
  47. [quidkid] at least that’s what the account manager tells me when I ask what browsers to make sites compatible until
  48. [quidkid] so for right now i guess i shouldn’t be wasting more time trying to figure out how to fix those 3 issues since they are so browser + AT specific, right?
  49. zakim-robot
    @zakim-robot
    Feb 21 18:08
    [marcysutton] Are they in combinations that you support? That comes back to the support matrix. Are they common combinations?
  50. [quidkid] Crap they are common combinations
  51. [marcysutton] Then they are worth prioritizing. It's a balancing act, where some things will make the cut and some won't.
  52. [marcysutton] That said, mobile ATs are particularly difficult. Some known bugs never get resolved and we have to work around them or provide other affordances
  53. [quidkid] yeah it was for mobile!!
  54. [quidkid] all the bugs are for mobile
  55. [quidkid] dang it so how can i say that without getting canned
  56. zakim-robot
    @zakim-robot
    Feb 21 18:13
    [quidkid] its not cost effective to keep going on like this
  57. [marcysutton] I would do some research on the bugs and try to provide time estimates
  58. [quidkid] even their vendor accessibility -we had a call with them because they pointed out those errors, I asked for how to fix it and they said that was tricky and they weren’t sure. if the experts can’t figure it out, how can I do so or provide a time estimate. this is so frustrating!!!
  59. [marcysutton] What are the bugs again? We might be able to point you in the right direction
  60. [marcysutton] But obviously we all have our own jobs to do too ;)
  61. zakim-robot
    @zakim-robot
    Feb 21 18:19
    [quidkid] true i understand that. I’m really grateful for any help I can get. I wish I had a mentor here so if anyone in Philly who knows accessibility needs a job, let me know. (sweat smile emoji)

  62. [quidkid] [Android]

    The navigation menu that is presented when the Mobile Menu (hamburger menu) is activated cannot be closed using the close control if TalkBack is running.

    TalkBack users cannot navigate to the rest of the page if this cannot be closed.

  63. [quidkid] [iOS]

    The logo does not receive focus. Instead, a section above the logo receives focus and announces the accessible text. When a user double taps to activate this link, nothing will occur since there is nothing actionable within the focus indicator.

    Screen reader users cannot activate the logo that brings the user to link

  64. zakim-robot
    @zakim-robot
    Feb 21 18:24

    [quidkid] [Mobile]

    After the "go top" graphic, if the user keeps swiping, they will start to hear the mobile navigation menu options. These controls are not visible since the menu is not expanded but they are being announced.

    Screen reader users can become confused as to why the navigation elements are being announced. Additionally, activating these does nothing.

  65. [marcysutton] So the user can't get to the link? Have you tried moving focus with a setTimeout to delay it a tick? That's always the first thing I try.
  66. [marcysutton] if there is something covering it, try to find out what that is.
  67. [quidkid] no but i’ll try it. I’m not quite sure what you mean by moving focus with a setTimeout delay but i’ll google more about it. you’ve helped me so much so far and I can’t thank you guys all enough!!
  68. [marcysutton] it's a focus management trick.
  69. zakim-robot
    @zakim-robot
    Feb 21 18:30
    [marcysutton] For the generic mobile "go top graphic" issue, sounds like you need to make the hidden menu inert
  70. [quidkid] oh right!! you keep mentioning the inert thing. I got so confused when figuring out how to use it though so I went for “aria-hidden” until it was clicked but they want a non-aria solution too. i really have to figure that out and not give up trying to implement it.
  71. [marcysutton] aria-hidden by itself won't be enough if they are focusable. That will cause ghost controls
  72. [marcysutton] Inert is much easier since it handles focusability and aria-hidden for you
  73. zakim-robot
    @zakim-robot
    Feb 21 18:37
    [quidkid] ahh okeydokey those ghost controls are probably what they are talking about too..
  74. zakim-robot
    @zakim-robot
    Feb 21 18:53
    [jiatyan] @quidkid take the brain dump from Marcy (Marcy rocks!), figure out how long it'd take to implement each solution, get your stakeholders to decide on the risk vs ROI. Solutions include re-design, or even provide accessible alternatives. E.g., provide a text-only site map rather than animated menus, but make sure the text-only gets updated the same time as the animated one.
  75. [jiatyan] @quidkid https://labs.ssbbartgroup.com/index.php/Assistive_Technology_Browser_Combinations
  76. [jiatyan] IMO, for your primary audience for older adults, you'd want to pay attention to effects of resizing or magnification rather than screen reader.
  77. zakim-robot
    @zakim-robot
    Feb 21 19:52
    [quidkid] @jiatyan Thank you so much!! yeah… it’s really hard for me to figure out how long to implement a solution since i have very little past experience to go off of. I did a coding bootcamp to change career paths after graduating in May, got hired in October(our web team is just 3 of us). I feel like I’m just pulling numbers out of nowhere. I keep telling myself better a struggling new developer than not a developer at all but gosh it’s hard
  78. zakim-robot
    @zakim-robot
    Feb 21 20:58

    [gokatgo] So I’ve seen this question partially answered in the past… can someone give me further insight on whether the <input type=file> element’s button text can be customized? My challenge is: localization (this app is intended to be available in multiple languages. Currently, the React component I’m modifying has a localizedString passed in as a prop, and the rendered DOM element has this structure, yet seems a bit hacky to me:

    <label htmlFor=“file-upload" className="c-file-upload"> <span>{this.props.localizedStrings.chooseFile}</span> <input id=“file-upload" onChange={(e) => { this.handleChange(e); }} type="file" /> </label>

    Can the standard button text in the <input type=file> element be modified? Is this workaround the only solution? So far, this works on Voiceover, haven’t checked on other AT.

  79. [conley] No, it can't be changed unfortunately
  80. zakim-robot
    @zakim-robot
    Feb 21 21:23
    [susanjrobertson] hello a11y friends! we're working on figuring out how to make a complex multi select (such as is here: http://select2.github.io/examples.html) and want to make sure it works for all, does anyone have any resources, ideas for that? This will most likely be translated into some js frameworks, but we want to make sure we get interactions right first
  81. [susanjrobertson] we specifically want to do the Multiple Select boxes example (which doesn't work well for keyboard and not great for voice over either)
  82. [gokatgo] That
  83. zakim-robot
    @zakim-robot
    Feb 21 21:48
    [conley] I would change the localized string from a span to a button if that's the actionable item
  84. [conley] actually scratch that
  85. [conley] sorry
  86. [conley] given you have the input field wrapped in a label, that should suffice
  87. [conley] as long as the input field isn't hidden via display:none
  88. zakim-robot
    @zakim-robot
    Feb 21 22:08
    [jessebeach] @gokatgo
  89. [jessebeach] I'd just use a <button> instead of an <input /> there
  90. [conley] input is required as that's how the file will be handled
  91. zakim-robot
    @zakim-robot
    Feb 21 22:13
    [marcysutton] Wouldn't the user's language set on the browser/machine override it?
  92. [caesar] Q: are there any "screen reader compatibility test" sites out there that are similar to, but with greater coverage, than this Powermapper site? http://www.powermapper.com/tests/
  93. Sean Elliott
    @seanus1138
    Feb 21 23:15

    Hey guys, I had some questions regarding keyboard interactions with menus. https://www.w3.org/TR/wai-aria-practices/#menu
    In the authoring guidlines https://www.w3.org/TR/wai-aria-practices/#kbd_general_within it is stated "the tab sequence should include only one focusable element of a composite UI component" you can see the interaction when tabbing to the menu on this example page https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/menubar-1.html - you can only tab to the "about" menu item pressing tab again would take you to the other menu present on the page further down. Not to the "addmissions" menu item next to the "about" menu item.

    I guess my questions are:

    • is the main menu on websites expected to follow this and only have the first navigation element focusable, or is not meant for the main menu?
    • if so does this not break peoples mental model of how the tab key works?

    Very interested in peoples opinions as i would have expected the main menu navigation to work like this when tabbing https://adobe-accessibility.github.io/Accessible-Mega-Menu/

  94. zakim-robot
    @zakim-robot
    Feb 21 23:17
    [jessebeach] @conley > input is required as that's how the file will be handled
  95. [jessebeach] Didn't see the type=file; indeed
  96. [caesar] @seanus1138 it depends on how complicated your menus are. I think the APG version assumes it's a simple dropdown, where the menu root is a tab stop, and the dropdown elements are arrow keys.
  97. [caesar] That generally prevents problems like having to tab through dozens of menu links to move through the masthead/primary navigation
  98. [jessebeach] @ceasar, I'd agree with that. If the menu has 3 or 4 items total, tabs are fine. But if you're going to build a menu component, then it's best to be consistent regardless of the size of the menu and just support arrow-key navigation
  99. [caesar] @seanus1138 - that Adobe mega menu can't be collapsed. Once you open one, you're "doomed" to keep tabbing through everything
  100. [caesar] Clicking the top-level element activates the link for that element, instead of being a menu toggle.
  101. zakim-robot
    @zakim-robot
    Feb 21 23:23
    [caesar] No, I lie. You can "Escape" out of it
  102. Sean Elliott
    @seanus1138
    Feb 21 23:23
    @Ceasar cant you collapse it with the ESC key?
  103. zakim-robot
    @zakim-robot
    Feb 21 23:23
    [caesar] Hehe...
  104. Sean Elliott
    @seanus1138
    Feb 21 23:24
    haha, so the main idea behind only tabbing to one item is to limit the amount of tabbing needed to get to the next section. Would you say its a failure to still be able to tab to each menu item and also still have all the other keyboard interaction applied?
  105. i guess im thinking of stakeholders in projects who dont agree with that interaction and would prefer to be able to tab to all menu items
  106. zakim-robot
    @zakim-robot
    Feb 21 23:27
    [caesar] It's more about menu philosophy, and whether you believe menus are the old school definition (a la Operating System widgets) or the new school "modal dialog" style of interaction.
  107. [caesar] I don't think either way is more correct or objectively better. It should only need to be consistent
  108. Sean Elliott
    @seanus1138
    Feb 21 23:31
    awesome, thanks for the response @caesar
  109. zakim-robot
    @zakim-robot
    Feb 21 23:32
    [caesar] Just an opinion :)