Archive index

A11y Slackers Gitter Channel Archive 10th of August 2017

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    @zakim-robot
    Aug 10 12:59
    [reridley] Hi :) Can anyone confirm that figcaption for an image should be used in addition to alt text rather than an alternative to alt text?
  2. zakim-robot
    @zakim-robot
    Aug 10 13:54
    [scottohara] yes, it should be used in addition
  3. [tink] @reridley if the image is the only content of the figure, then the figcaption can serve instead of the alt https://www.w3.org/TR/html52/semantics-embedded-content.html#when-a-text-alternative-is-not-available-at-the-time-of-publication
  4. zakim-robot
    @zakim-robot
    Aug 10 14:00
    [tink] But it's an exception rather than the rule.
  5. zakim-robot
    @zakim-robot
    Aug 10 14:05
    [reridley] @tink @scottohara thank you
  6. [tink] One other thing is that if the image is the only content of the figure, it's important that the alt and the figcaption don't use the same text.
  7. [tink] The alt and figcaption serve different purposes, but if they're the same it's also a lot of duplication for screen reader users.
  8. [reridley] Any idea if figcaption is widely supported by screen readers?
  9. zakim-robot
    @zakim-robot
    Aug 10 14:10
    [reridley] That was my other concern. if it wasn't and the alt text wasn't present - then there would be no alt text at all
  10. zakim-robot
    @zakim-robot
    Aug 10 14:35
    [tink] I believe it's well supported in current screen readers, but don't have any test data to substantiate that I'm afraid.
  11. zakim-robot
    @zakim-robot
    Aug 10 14:44
    [reridley] @tink thanks. useful feedback anyway
  12. powrsurg
    @powrsurg
    Aug 10 15:12
    We have developed a poll that has text that shows how many votes each option got, and then was using <meter> to create a visual display of said vote. When testing with NVDA it just read out the value of the meter tag, which was redundant at that point. Is it right for us to apply aria-hidden="true" in such a case, or is there potentially something we're missing?
  13. The headers and whatnot are not correct, but what should the markup for this be to really make it accessible? https://codepen.io/powrsurg/pen/VzWPMx
  14. zakim-robot
    @zakim-robot
    Aug 10 16:31
    [tink] @powrsurg if the <meter> is purely a visual representation of the info in the <p>, and requires no form of user interaction, then using aria-hidden would seem to be ok.
  15. [tink] FWIW I think the <meter> element is closed incorrectly. It should have a proper closing element in HTML5 </meter>.
  16. [tink] According to html5accessibility.com, the <meter> element has less than good accessibility support across various browsers.
  17. powrsurg
    @powrsurg
    Aug 10 16:34
    I can believe I closed that wrong. I don't work with it much. Heck, I didn't even do the work that was behind the question. I'm just the "a11y guy" so I was asked about it and I quickly put together that codepen for asking here.
  18. zakim-robot
    @zakim-robot
    Aug 10 16:36
    [tink] nods.
  19. zakim-robot
    @zakim-robot
    Aug 10 17:53
    [sara.tabor] Hi folks - I'm looking for some good high-quality captioning/transcribing vendors for existing audio and video content. Does anyone have any good recommended vendors?
  20. [sara.tabor] I work in Engineering, but have been asked by our client for this assistance.
  21. [sara.tabor] Not normally my realm. :)
  22. [tink] 3PlayMedia are very good for captions/AD on existing recordings.
  23. zakim-robot
    @zakim-robot
    Aug 10 18:02
    [nicki.rios] Does anyone know if there are any accessibility reasons for not removing input:-webkit-autofill background color?
  24. zakim-robot
    @zakim-robot
    Aug 10 18:51
    [ghanek] @sara.tabor Big State U here has used 3PlayMedia, Cielo24, and AST for Post-Production Closed-Captioning & Transcription.
  25. zakim-robot
    @zakim-robot
    Aug 10 19:19
    [sara.tabor] thank you @tink and @ghanek for the feedback, cheers! 8-)
  26. zakim-robot
    @zakim-robot
    Aug 10 20:30
    [spell] Hey A11y Friends! Quick question. When is it appropriate add in up and down arrow functionality? if I have a drop down with hyperlinks links in it, is keyboard arrow up/down necessary or will tabbing through suffice? Thanks in advance!
  27. zakim-robot
    @zakim-robot
    Aug 10 20:46
    [ugi] I generally implement arrow functionality in any menu style component that spawns or has a child element that can expand and collapse. i think, pretty much anything that can take aria-expanded and aria-haspopup properties should have arrow key functionality.
  28. zakim-robot
    @zakim-robot
    Aug 10 21:23
    [spell] Thanks, @ugi. Any good tutorials or script examples for doing that? My team uses jQuery, so that would be ideal.
  29. [ugi] I think, Menu Button is the pattern you are looking for.
  30. [dpogue] @spell Example menu button: https://ayogohealth.github.io/ay-menu-button/
  31. [spell] Thanks, gang!
  32. zakim-robot
    @zakim-robot
    Aug 10 21:29
    [ugi] Please note that the w3c example only uses arrow keys. I highly recommend using both tab and arrows keys.
  33. [ugi] Untitled
  34. [ugi] this is the keyboard pattern I usually recommend for dropdown type components
  35. zakim-robot
    @zakim-robot
    Aug 10 21:38
    [spell] @ugi This is great. Regarding this: "Up/Down arrow keys, or tab/shift+tab keys move focus through the menu items. " It seems like you are saying either one is acceptable, rather than both. if my expanded content area is a list of links that can be tabbed through, is arrow function ality necessary?
  36. zakim-robot
    @zakim-robot
    Aug 10 21:47
    [marcysutton] We should be thoughtful about when to bind TAB vs. arrow keys. Menus and tab panels act as a single tab stop, which makes it easy for keyboard and screen reader users to skip past them. Regular links operate with TAB, so binding the arrow keys on regular links is an enhancement.
  37. zakim-robot
    @zakim-robot
    Aug 10 22:11

    [ken.petri] When using mobile screen readers, a normally interactive element that is visually obscured by another element cannot be interacted with.

    For example, say you have a footer-like bar that sticks to the bottom of the viewport, position:fixed. If you swipe to a button that is "underneath" your sticky footer thing you will hear the screen reader announce that the button is a button and hear its accessible name. But if you "double-tap" to click the button, the tap/click event is not passed to the button. It is "absorbed" by your sticky footer thing. Apparently, the mobile screen readers' swipe focus rectangle is literally where the actual click event occurs -- not on the DOM node but on the physical screen, wherever the rectangle gets painted.

    Does anyone know a way to address this issue?

    We want the sticky footer thing but we need a way to make sure that stuff that is focused by the screen reader always gets positioned "above" that sticky footer. A mobile screen reader will perform a scroll when it detects that a swiped to element is outside of the standard viewport. However, there is no calculation that takes into consideration the vertical space consumed by the sticky footer thing.

    We could force the scroll by listening for events, but focus/blur listeners won't do the job, since Android Talkback is not passing an event when an interactive element is swiped to/off of.

    Anyone encounter such an issue before? Any clever (or dead obvious) solutions?

  38. zakim-robot
    @zakim-robot
    Aug 10 22:27
    [marcysutton] add more padding around it so it doesn't get covered by the footer maybe? I'm surprised that the event for a focused element would be obscured by the footer. That sounds like a good thing to do more testing on.
  39. [marcysutton] maybe make things that go behind the footer inert so they aren't interactive?
  40. zakim-robot
    @zakim-robot
    Aug 10 22:40
    [spell] Thanks, @marcysutton . Perfect answer.
  41. [alice] Does anyone know here of any existing hacks to detect AT users on the web? Obviously I am not condoning that behaviour, just looking at what the existing surface is.