Archive index

A11y Slackers Gitter Channel Archive 4th of August 2017

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    @zakim-robot
    Aug 04 14:14
    [cameron] @pweil
  2. [cameron] so if you create non-standard handling of abbreviations, that may break expected behavior for screen reader users
  3. [cameron] in the example you used, leave it to the screen reader and the screen reader user to configure the behavior
  4. zakim-robot
    @zakim-robot
    Aug 04 14:28
    [pweil] @cameron I agree regarding "overengineering". I don't think using the <abbr> tag (and a title attribute) can be considered non-standard or "wrong". But if it's of little or no utility, then there's not much reason to use it. I take it from your comment that the best thing to do is nothing; just leave it to users and screenreaders/browsers to handle it. What I wonder is, what is it like for a user to hear abbreviations pronounced as nonsensical (to me, anyway) syllables. Is there anything developers can or ought to do to improve that experience and communicate the meaning of the abbreviation, or should we take the Taoist approach and worry about other things.
  5. [cameron] @pweil take a peek at this http://seeingdifferentuk.blogspot.com/2014/12/abbreviations-jaws-v15-dictionary.html
  6. [cameron] this is what I was describing wrt to dictionaries
  7. [cameron] I think relying on screen reader heuristics, user level settings, and the intelligence (and preferences) of your screen reader customers is your best bet
  8. zakim-robot
    @zakim-robot
    Aug 04 14:44
    [pweil] Thanks. Geez, I didn't know about this; it looks as though NVDA has something similar. These would help with pronunciation. Meaning might be a different story, at least for less common abbreviations. I suppose in those cases it would pay to lean on web writers/editors to explain any abbreviations or acronyms that users might not be familiar with. You get a lot of these in bureaucratic or technical articles. Higher Ed is chock full of them.
  9. zakim-robot
    @zakim-robot
    Aug 04 15:37
    [quidkid] for pdf accessibility, how do you treat empty table cells? if there are more empty cells than there are data points then wouldn’t it be super annoying for the screenreader to keep reading out all the empty table cells?
  10. zakim-robot
    @zakim-robot
    Aug 04 15:57
    [ghanek] where is the table coming from? Static data, or perhaps something like the result of a filter?
  11. zakim-robot
    @zakim-robot
    Aug 04 16:19
    [quidkid] well i guess empty table cells are fine if the wcag 2.0 guidelines are saying to add empty table cells: For tables that contain blank cells, you may need to add empty TD cells so that each row or column has the same number of cells.
  12. [quidkid] https://www.w3.org/TR/WCAG20-TECHS/PDF6.html
  13. [quidkid] I was just confused because for level access, they have a guideline that says Ensure empty data cells contain a placeholder: https://www.webaccessibility.com/best_practices.php?best_practice_id=721
  14. zakim-robot
    @zakim-robot
    Aug 04 17:13
    [reridley] Hi :) Can anyone advise on emoticons and facebook accessibility? Our social media person wants to ask followers to vote on a post using emoticons and has asked whether this something screen reader users can do easily. Does anyone know the answer to this?
  15. zakim-robot
    @zakim-robot
    Aug 04 17:22
    [ghanek] @quidkid they are making that placeholder recommendation for older AT, some of which has spottier handling of an empty cell. But I doubt it would adversely impact newer AT.
  16. zakim-robot
    @zakim-robot
    Aug 04 17:33
    [marcysutton] @reridley i don't see screen reader users using emoticons very often. Usually they will spell out a word like "smile" since it's easier to not have to navigate an emoticon menu.
  17. [marcysutton] That seems like an unnecessary barrier IMO.
  18. [reridley] @marcysutton thanks for the feedback :) I agree about it being an unnecessary barrier but I do respect social media person for asking before post :)
  19. [marcysutton] Absolutely. And that's not to say people using screen readers don't ever use emoticons–here's a great read on emoji by Léonie Watson https://tink.uk/accessible-emoji/
  20. zakim-robot
    @zakim-robot
    Aug 04 17:39
    [reridley] thanks!
  21. zakim-robot
    @zakim-robot
    Aug 04 20:33

    [higley] I have a question for any UX people: I’m creating a widget a little like a select element in that a button opens an overlay that lets you choose some options. Visually, the button text shows the currently selected options (e.g. “Red Hammer” if it let you choose a color + tool). Does it make sense to add extra visually hidden text for screen readers (e.g. “Choose a color and tool”), or are attributes like aria-haspopup and aria-expanded enough to signal what it does?

    Theoretically screen reader users get the same information as sighted users, but it feels a little confusing to me. There are small visual cues like styling the wrapping div to look like a control bar, which might justify adding extra screen reader text. I’m also debating leaving the text as-is and adding role="menu" to the containing div (or doing both extra text + menu role).