Archive index

A11y Slackers Gitter Channel Archive 14th of August 2017

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    @zakim-robot
    Aug 14 14:15
    [mtribone] @cameron does alt="" make the automated tests fail? We’re shopping around for automated testing for accessibility, but we use Travis CI.
  2. [mtribone] Haven’t found a good match that is still being developed
  3. zakim-robot
    @zakim-robot
    Aug 14 14:38
    [cameron] no, alt="" instructs assistive tech to ignore an image
  4. [cameron] @mtribone if you apply alt="" to an <img>, the image is removed from the accessibility tree
  5. [cameron] it’s a way to signal to assistive tech that the graphic is not meaningful or decorative, and that it would create additional noisiness to the screen reader experience to include it
  6. [cameron] @mtribone are you on GitHub?
  7. [cameron] your project I mean
  8. [mtribone] ah. yes. yes. thank you.
  9. [mtribone] I used alt='' for thumbnails because there was more meaningful metadata included in the content
  10. zakim-robot
    @zakim-robot
    Aug 14 14:43
    [mtribone] @cameron https://github.com/psu-stewardship/scholarsphere and https://github.com/samvera/sufia for now, but new projects are starting
  11. [cameron] cool!
  12. [mtribone] @cameron so including alt="" creates more noise for screen readers?
  13. [mtribone] just to clarify
  14. [cameron] nope
  15. [cameron] alt=“” makes the screen reader ignore an image, meaning less spoken text overall
  16. [mtribone] working on a cultural heritage object repo next https://github.com/psu-libraries/cho-req
  17. [cameron] but it’s something that you should use thoughtfully, since it obscures content
  18. zakim-robot
    @zakim-robot
    Aug 14 14:50
    [mtribone] yeah until we can get intelligible alt text for our apps, we thought that the metadata like title, description, etc. was more meaningful
  19. [mtribone] and had less noise
  20. [cameron] voiceover will read the filename for an image with missing alt text, which is annoying
  21. [cameron] JAWS will announce there’s an image, but not the filename last I checked
  22. [cameron] I suspect JAWS is configurable in that regard
  23. [cameron] I’m not sure if folks use aria-labelledby in the case you’re describing
  24. [mtribone] ah. that could be good
  25. zakim-robot
    @zakim-robot
    Aug 14 14:56
    [cameron] @mtribone I’m helping build a GitHub integration that creates PR reviews with accessibility remarks https://accesslint.com
  26. [cameron] in case you find that useful
  27. [mtribone] @cameron yes!
  28. [cameron] basically comments on regressions and additions that break accessibility rules
  29. [cameron] less audit, more code review :)
  30. [mtribone] I see. do you have docs on getting started? might wanna take it for a spin and see if it works for the team
  31. zakim-robot
    @zakim-robot
    Aug 14 15:06
    [mtribone] @cameron just added it to me personal repo
  32. [cameron] @mtribone if you click connect with Github on the page I sent, it will start listening for PRs and comment automatically with useful guidance
  33. [mtribone] @cameron I’ll see if the team wants to give it a spin for our cultural heritage object project. we’re still in the testing phase. dealing with scaling issues right now. might jump to another code base.

  34. [cryberg] Hi All, I could use some help. I'm trying to advocate to update a particular section of the web application I work on to make it more keyboard friendly, but my designers don't want to buy into the changes until they see an example somewhere else on the internet of the same concept. Here's the breakdown:

    As it stands, we have a list of items on the main screen. Clicking on an item opens a modal dialog of more details for that item, and in the header of the modal are "Previous" and "Next" buttons that will load the details modal for the previous/next item from the list on the main screen. Currently, when one of those next/previous buttons is clicked, the whole modal then rerenders quickly. It visually looks like only the content was updated and the buttons were present the whole time. After rerender, focus begins at the beginning of the modal, i.e. not on the button that had been clicked.

    In other words, if you click "next," you then have to tab three times to click "next" again (First on the whole modal, second on "previous", third on "next), and it makes it very frustrating to quickly page through the details.

    Finally, if you are at the end of the list, the "Next" button becomes disabled, and likewise "Previous" is disabled if you're at the beginning of the list.

    What I am proposing is to preserve focus on "Next" or "Previous" when they are clicked, so you can just hit "Next", "Next", "Next" and get to what you want without a lot of extraneous tabs. This could be done by using jquery to reassign focus, or to rewrite the view structure so the buttons don't rerender; both options are on the table. And when you get to the end of the list and "Next" is disabled, I'm proposing that focus should move to the "Previous" button.

    In my mind, this seems much more usable, but I'm getting a lot of pushback on it. They particularly don't like moving focus to "Previous" if "Next" is disabled, and vice versa. If anyone has some thoughts on why the proposal not more usable, I would love to hear the feedback. And if anyone has an example of this kind of keyboard interaction being used somewhere else that might help my case, I'd greatly greatly appreciate it.

  35. zakim-robot
    @zakim-robot
    Aug 14 15:17
    [cameron] btw @mtribone here’s an example of AccessLint PR review accesslint/bourbon.io#4
  36. [cameron] ping me if I can help with anything else!
  37. [mtribone] @cameron thx! I certainly will
  38. [mtribone] @cryberg gotta run but will think on it some more. My initial thought was wondering if the focus would affect screen readers? meaning they’d have to tab back up to hear the content?
  39. [cryberg] @mtribone Thanks for taking the time! The only content before the Next/Previous buttons is the modal title, which is announced then the modal loads.
  40. zakim-robot
    @zakim-robot
    Aug 14 15:28
    [cryberg] @mtribone this is what the modal looks like:
  41. zakim-robot
    @zakim-robot
    Aug 14 15:43
    [johnbhartley] @cameron @mtribone I'm curious if also adding aria-hidden="true" would be something to add (maybe even programatically) to make sure all screen readers ignore it
  42. zakim-robot
    @zakim-robot
    Aug 14 16:32
    [jhetrick] @mtribone @cryberg I had the same thought regarding screen reader context. would it help to make the Next/Previous labels more verbose for screen readers? e.g. when viewing Item 4, the Previous/Next buttons are (audibly) labelled “Previous: Item 3”/“Next: Item 5"
  43. zakim-robot
    @zakim-robot
    Aug 14 16:41
    [jhetrick] but to your original question, yeah I think that preserving keyboard focus on Previous/Next is a good approach overall.
  44. [jhetrick] as for the first/last item in the list, does it make sense for the disabled button to be focused, but indicated as disabled? also thinking of screen readers, that might provide more context that you’ve reached the end of the list
  45. zakim-robot
    @zakim-robot
    Aug 14 16:52
    [jhetrick] moving focus to the Previous button isn’t necessarily what the user will want to do if the Next button is disabled — it might be to close the modal — so rather than guess, maybe leave focus on the disabled button
  46. zakim-robot
    @zakim-robot
    Aug 14 17:09
    [cameron] @johnbhartley alt="" is well supported across user agents to remove images from the accessibility API
  47. [cmegown] question: anything other than -1 or 0 for tabindex is considered an anti-pattern, correct?
  48. Jonathan Neal
    @jonathantneal
    Aug 14 17:12
    Is there a job board that focuses on accessibility? Or, at least, is there something that considers it an important part of a (frontend) position?
  49. zakim-robot
    @zakim-robot
    Aug 14 17:12
    [cmegown] does that mean there's no good use case for something like tabindex=2?
  50. [cmegown] because i'm seeing one in the generated sign up form created by azure b2c
  51. [clairebones] @johnbhartley is you're looking to hide images that don't provide information wouldn't role="presentation" be the best option?
  52. [cameron] @jonathantneal there’s a slack channel #jobs in the webA11y org
  53. [cameron] also there’s a Twitter account
  54. [cameron] https://twitter.com/a11yjobs
  55. [cameron] here’s the w3c text alternative computation algorithm https://www.w3.org/TR/wai-aria/roles#textalternativecomputation
  56. [cameron] Hidden, according to the spec:
  57. [cameron] > Indicates that the element is not visible or perceivable to any user. An element is only considered hidden in the DOM if it or one of its ancestor elements has the aria-hidden attribute set to true.
  58. Jonathan Neal
    @jonathantneal
    Aug 14 17:16
    Thank you so much, cameron!
  59. zakim-robot
    @zakim-robot
    Aug 14 17:17
    [cameron] alt=“” is implicitly hidden from the accessibility API tho
  60. [cameron] here’s how Google’s accessibility developer tools test for alt text
  61. [cameron] var imageIsPresentational = (image.hasAttribute('alt') && image.alt == '') || image.getAttribute('role') == 'presentation';
  62. [cameron] they run that after filtering for aria-hidden
  63. zakim-robot
    @zakim-robot
    Aug 14 17:26
    [mtribone] @cryberg thanks for the screen shot. I’m liking what @jhetrick has provided so far. As for examples in production that are similar to support your proposal, I’d have to dig a little bit. looks at his own modals in production
  64. zakim-robot
    @zakim-robot
    Aug 14 17:42
    [mtribone] looks like the practice is to set focus on the first focusable element unless there is “a condition where doing otherwise is advisable.”
  65. [mtribone] https://www.w3.org/TR/wai-aria-practices/#dialog_modal
  66. zakim-robot
    @zakim-robot
    Aug 14 19:44
    [kivi] @cryberg it sounds like some usabilty testing is in order. Get with your users, let them tell you (by words or actions) what they expect.
  67. zakim-robot
    @zakim-robot
    Aug 14 20:02
    [cryberg] @mtribone @jhetrick thanks for the feedback. I think we were assuming that a disabled button shouldn't be allowed to receive focus, but you're right that that isn't necessarily the case
  68. zakim-robot
    @zakim-robot
    Aug 14 20:14
    [garcialo] @cmegown I can’t think of any case for using a positive value for tabindex; there could still be one, of course. Just seems like it would be too much of a hassle to have to manage it.
  69. [mtribone] @cryberg @jhetrick Perhaps aria-disabled is a better solution for screen readers if the button is disabled and have the tab focus back on previous.
  70. LauraOU
    @LauraOU
    Aug 14 20:24
    If its a modal dialog box, you may want to have the last page focus on the close instead, as it will still be important to close the dialog to return to the page.
  71. zakim-robot
    @zakim-robot
    Aug 14 20:25
    [cmegown] @garcialo weirdly enough they put tabindex="2" on a "forgot password" link that was in the middle of the form
  72. [cmegown] so that meant you tab through the whole form then back up to the "forgot password" link then back down to any content below the form