Archive index

A11y Slackers Gitter Channel Archive 16th of November 2016

What fresh hell is THIS now? - Patrick Lauke
  1. James Nurthen
    @jnurthen
    Nov 16 00:01
    @marcysutton I thought Thierry's original comment was actually pretty diplomatic. He stated that he didn't agree with the content for every situation. I think that is a good caveat for every situation really. The whole thing got blown up due to a sarcastic response IMO
  2. zakim-robot
    @zakim-robot
    Nov 16 00:08

    [herin] Hi, I am looking for an accessible solution for an issue.
    I have a table of 5 columns and the headers open the help file (The file has internal anchors. So the relevant section of the help file is opened).

    1. The help file opens in a new window. So need to announce that this opens in a new window for AT users
    2. The help file "A guide to XYZ". I need to convey this to the user as well

    Option 1:
    If I add a sr-class to the column headers inside a span element - When CSS is turned off this is the repeated info on each column header. Which I am not happy about as it looks like a very long column heading.
    Option 2:
    If I add a <p> element before the Table and give it an id & make it screen reader only, I can use Aria- described by to associate them with the column header.
    For example

    <p class="sr-only" id="helpnote"> (A guide to XYZ opens in a new window) </p>
    and my TH would look like

    <th><a href="..." aria-describedby="helpnote">Heading</a></th>

    What do you think about option 2? Is there any other options is better than this?

  3. zakim-robot
    @zakim-robot
    Nov 16 00:14
    [caesar] You'd also want to have a visual display of the "opens in a new window", e.g. an icon or something of sorts... so could you incorporate a visual icon with alt text, instead of using the aria-describedby method? So kind of Option A
  4. zakim-robot
    @zakim-robot
    Nov 16 00:23
    [herin] An image with an alt text as ""A guide to XYZ opens in a new window"? Sounds good. In this case, as the link loads different section of the same document, do we need to inform that to the user?
  5. [herin] @caesar : Thanks for the suggestion. Also have a question. How can we differentiate Opening in a new window and opening in a Pop-up to the user?
  6. [caesar] It's really hard, because that's dictated by browser settings. You can configure the browser to open popups in tabs...
  7. [caesar] As for opening the anchor link target, just test that focus is at the appropriate place when the target document is opened. But I don't think it is necessary to inform the user that they've arrived at some other point in the page other than the start
  8. zakim-robot
    @zakim-robot
    Nov 16 00:30
    [herin] The focus transferrs and the site is still usable when the pop-up is open. Will go with the option 1 + image as you suggested. Thanks for that
  9. [caesar] No problem, and good luck!
  10. stevefaulkner
    @stevefaulkner
    Nov 16 07:11
    @MarcoZehe updated his article on slack accessibility https://twitter.com/MarcoInEnglish/status/798779886085095424
  11. zakim-robot
    @zakim-robot
    Nov 16 07:34
    [marcozehe] Good morning! In case it is appreciated, here's my updated article on the accessibility of the Slack service, primarily from a user's point of view, haven't tried the team admin stuff myself.
  12. [marcozehe] https://www.marcozehe.de/2016/01/16/status-of-the-accessibility-of-slack/
  13. [marcozehe] Argh, sorry, @stevef ! Your message came in just when I was posting mine.
  14. stevefaulkner
    @stevefaulkner
    Nov 16 07:51
    no worries @MarcoZehe
  15. zakim-robot
    @zakim-robot
    Nov 16 09:32
    [stefanjudis] hey folks... I just recently discovered that setting display: block on a table has impact on the a11y tree in certain browsers. I was wondering if you know more places where css can have influence (not speaking about contrast and visual a11y here).
  16. zakim-robot
    @zakim-robot
    Nov 16 10:05
    [marcozehe] @stefanjudis: :european_castle:after much criticism, we stopped doing that in Firefox, and the change is in one of the more recent versions, mid to late fourties. CSS table properties are now treated as purely visual with no bearing on the accessible object properties.
  17. [stefanjudis] oooh. interesting. thanks for pointing this out. :)
  18. [marcozehe] Yw!
  19. [stefanjudis] yeah I was very surprised when I heard that css can have influence.
  20. zakim-robot
    @zakim-robot
    Nov 16 10:12
    [marcozehe] Yeah this was the result of a big refactor in Firefox 4 in 2011.
  21. [marcozehe] For the layout engine, HTML table tags and applied CSS table properties are essentially the same. Both result in table frames (for drawing to the screen and other handling).
  22. zakim-robot
    @zakim-robot
    Nov 16 10:18
    [marcozehe] We decided at one point to tie the creation of accessible objects more closely to the layout engine, since that gives us a lot of markup interpretation results for free, and we can avoid doubling the work in the accessibility engine.
  23. [marcozehe] The fact that CSS table properties resulting in accessible table objects was not desired behavior for some in the accessibility community actually surprised us at Mozilla. But after some discussion, we bowed to the opinion of the majority.
  24. zakim-robot
    @zakim-robot
    Nov 16 10:26
    [marcozehe] Funny enough, there was also a bug opened at almost the same time that asked us to take into account even more CSS table properties for the resulting accessibles. So, there were also people who liked what we did. But in the end after some convincing arguments, the decision was made to not take them into account at all any more.
  25. zakim-robot
    @zakim-robot
    Nov 16 10:37
    [alastc] For me it's related to how HTML, CSS and ARIA work. It is surprising to many (most?) developers that over-riding the role of an HTML tag doesn't bring along the other aspects of that role. For example, <span role="button"> not making it keyboard focusable etc. I think the mental scheme is that the HMTL is the foundation, therefore changing things there should change things further up.
  26. [alastc] But not the other way around, so changing CSS shouldn't change the roles in the 'foundation' of HMTL (relating back to the original point).
  27. zakim-robot
    @zakim-robot
    Nov 16 10:47
    [marcozehe] But ARIA is designed to do exactly that.
  28. zakim-robot
    @zakim-robot
    Nov 16 11:02
    [spell] Me again! Any recommendations/advice on where to go for personal certification in field of accessibility? IAAP looked interesting. Any others? Thanks in advance!
  29. zakim-robot
    @zakim-robot
    Nov 16 11:27
    [alastc] Sorry @marcozehe, not sure what you mean by 'that'? Do you mean adding a role should add the functionality of the role?
  30. [marcozehe] @alastc: No, I definitely stand by the decision that ARIA should only affect a11y semantics, not browser behavior. But that's what it does. It does change the a11y exposure of the foundation, whereas CSS does, or should, not do that. So there is a difference.
  31. [alastc] I was just trying to understand & outline the assumptions people make. When modifying the HTML, people assume that change over-rules things, e.g. adding role=button to a span converts it into a button with the associcated functionality. When applying table styles in CSS, that doesn't modify the HTML so people assume it is just for appearance (harking back to CSS Zen garden as well.
  32. [alastc] I'm not disagreeing, but pointing out that it is something I have to emphasis in training because it doesn't match people's expectations.
  33. zakim-robot
    @zakim-robot
    Nov 16 11:33
    [marcozehe] @alastc: gotcha. I believe an argument along those lines was ultimately what convinced us that CSS table properties needed different treatment. And so we fixed it to not expose table related accessible objects. :-)
  34. [alastc] And that decision matches the general assumptions I find developers making - anything in CSS shouldn't affect the accessibility/functionality. The ARIA one goes against people's assumptions, so is the one that needs more education.
  35. [marcozehe] Yes, I remember being asked once after a talk why we wouldn't at least make the basic ARIA roles implement the browser default behavior. My counter argument was that that will be even harder to educate, like "if you use this and that role, you're fine, but if you use the other ones, you're out of luck".
  36. [marcozehe] My argument is always to advocate for the inclusion of more advanced widgets in the HTML standard, and to actually lessen the need for ARIA in HTML bit by bit.
  37. zakim-robot
    @zakim-robot
    Nov 16 11:42
    [alastc] I agree, it's going to be a long road though!
  38. zakim-robot
    @zakim-robot
    Nov 16 11:56
    [marcozehe] Yes, and we're already ten years into that journey.
  39. stevefaulkner
    @stevefaulkner
    Nov 16 12:28
    @MarcoZehe @alastc I floated idea of making some interactive roles include beahviour, but implementers were not interested
  40. Peter Krautzberger
    @pkra
    Nov 16 16:49
    hey, a11y slackers. Does anybody have any useful links relatd to James Teh's post about aria-label/ledby http://blog.jantrid.net/2015/12/woe-aria-surprisingly-but-ridiculously.html ?
  41. (beyond @stevefaulkner's http://thepaciellogroup.github.io/AT-browser-tests/AT.html that is)
  42. zakim-robot
    @zakim-robot
    Nov 16 17:04
    [alice] @pkra what kind of thing are you looking for?
  43. zakim-robot
    @zakim-robot
    Nov 16 18:37
    [melsumner] @pkra I don't agree with the blog post that was linked. Or, more explicitly I don't agree that it's so much of an issue, when learning how to use ARIA these things are learned.
  44. Peter Krautzberger
    @pkra
    Nov 16 20:31
    @alice any further discussion on how to clarify the expected behavior. Also, anything that helps document existing behavior.
  45. @melsummer fair enough. I do run into it frequently.