Archive index

A11y Slackers Gitter Channel Archive 1st of February 2016

What fresh hell is THIS now? - Patrick Lauke
  1. zakim-robot
    Feb 01 01:05
    [jitendra] @jkva has the new edition come of this book?
  2. jkva
    07:24
    jitendra: I don't think so - I'm reading the 2010 version. Hence the 'years ago' comment.
  3. MichielBijl
    09:04
    @cameron, can do tonight (8-9PM GMT+1)?
  4. MichielBijl
    10:08
    @jitendra: I think it's important to get people interested/motivated to do something about accessibility. WCAG won't motivate anyone… I'd look up some good talks/short videos on a11y.
  5. jkva
    10:09
    I'd think Marcy's "Winning" presentation video would be a good starter
  6. zakim-robot
    10:10
    [jitendra] I know and understand that WCAG won’t motivate, What I was saying was in regard of Job posts and interviews
  7. jkva
    10:10
    Heh, my name is "Job", that confused me for a second
  8. zakim-robot
    10:11
    [jitendra] When a person see WCAG, Section 508 in a job post, he often think that because has has not read what is specifically written in WCAG/508 he is not eligible for the job
  9. MichielBijl
    10:11
    Hmm
  10. zakim-robot
    10:12
    [jitendra] And the same applies to interviewee too
  11. MichielBijl
    10:12
    Well, don't know about other people, but 90% of whats in job postings I apply for doesn't apply to me.
  12. MichielBijl
    10:12
    As for starting points: this is an introduction I did for managers: http://dir.rawr.eu/introduction-to-accessibility-(for-managers).zip
  13. MichielBijl
    10:13
    And pretty much the same presentation (some more technical details) for developers: http://dir.rawr.eu/introduction-to-accessibility.zip
  14. MichielBijl
    10:14
    Most—if not all—front end jobs require knowledge of JS frameworks; I have none.
  15. MichielBijl
    10:15
    Still get jobs, so not sure that really matters.
  16. MichielBijl
    10:15
    You can still learn stuff :)
  17. jkva
    10:16
    This message was deleted
  18. powrsurg
    14:59
    if you can do JS without a framework you're probably overqualified I'd say
  19. MichielBijl
    14:59
    ?
  20. MichielBijl
    15:00
    All I know is alert('Hello world')
  21. MichielBijl
    15:00
    Can I be overqualified now?
  22. MichielBijl
    15:00
    :P
  23. MichielBijl
    15:05
    @powrsurg what do you mean exactly?
  24. powrsurg
    16:27
    Sorry, was in a meeting. But a person I believe that a dev that doesn't need hand holding and needs a JS library to do anything is a better dev. Being able to write something in say, 100 lines of pure JS is actually better for the end user than 5 lines in jQuery (since it's really 5 lines + howerver many lines jQuery is)
  25. MichielBijl
    16:37
    I'd agree.
  26. jkva
    16:40

    Depends highly on the project and support requirements. For a larger project, having JQ is nice, since it allows me to focus on the problem to solve, instead of having to deal with browser compatibility issues. For some simple pages with JS enhancing the experience, vanilla might be preferred.

    What /is/ important, I'd argue, is being able to know what to do when you have to debug matters, or when Vanilla JS is a better idea. In short: know your language, and know when to use a library to its advantages.

  27. jnurthen
    17:28
    +1 to that. Depends what the dev is doing - I want our devs writing applications not worrying about browser compatibility
  28. powrsurg
    17:55
    Also it depends upon your market. Low end mobile devices really do have trouble running frameworks like jQuery. Honestly, I argue that making a site mobile friendly includes removing dependencies on frameworks. But that's just my 2¢
  29. powrsurg
    17:56
    and apparently hitting the alt key and trying to enter codes on the numeric keypad in gitter freaks things out
  30. powrsurg
    17:56
    tried to do alt+411 and when I hit the four it jumped around
  31. jnurthen
    17:58
    if you are writing a web application you either have a framework and you have some consistency or you get the wild west. For a small site sure but when you are talking large applications that is not feasible
  32. zakim-robot
    19:05
    [klara] For the page language requirement in WCAG, my automated accessibility testing tools tell me I need to set a default language (eg. <html lang=“en”>) in our app. But we translate our app into 24 other languages. I don’t really know how this would work, would JS reset the cookie and replace the default? Any advice? (Assume I am ignorant in the ways of Javascript.)
  33. jnurthen
    19:06
    I wouldn't add that using JS myself - but if you are, then the code knows which version it is requesting (it has to - to know which strings to request) so just set it.
  34. zakim-robot
    19:13
    [klara] Well I’m not entirely certain how it gets set. When I QA for internationalization, I set it on the browser or apply a localization code to the end of my query. It sounded like if it’s known from a users profile, we’ll also set the language.
  35. zakim-robot
    19:14
    [klara] I was just hoping that maybe someone else would be familiar with accessibility and internationalization and know how to field that requirement.
  36. jnurthen
    19:16
    I am familiar but each of our tech stacks handles it in different ways. Normally our user has a language profile set but I have seen it driven from the browser's preference for languages
  37. MichielBijl
    19:21
    @Klara, I don't understand the question.
  38. MichielBijl
    19:21
    At what time do you want to set the lang attribute?
  39. MichielBijl
    19:21
    Ideally, it would be set when the page is generated on the server.
  40. zakim-robot
    19:22
    [karlgroves] IMO the lang value would change when the lang itself changes. So, the same mechanism that does the translation would also change the lang atttribute
  41. jnurthen
    19:23
    Is this the most inaccessible site you have ever seen - http://www.disabilityjobs.gov.in/
  42. jnurthen
    19:25
    Seriously - not sure I can find anything done correctly
  43. jnurthen
    19:26
    ah - the skip nav works :)
  44. zakim-robot
    19:27

    [karlgroves] >Is this the most inaccessible site you have ever seen

    IDK, can we count web-based applications as sites? :wink:

  45. jnurthen
    19:27
    ah yeah - i've seen a few of those too.....
  46. MichielBijl
    19:28
    Slack? >:)
  47. zakim-robot
    19:30
    [klara] @MichielBijl It’s possible I don’t know what I’m asking. I just know I’m getting an error for not having <html lang> in our head tags. But when I test with VoiceOver in English and Spanish by using my browser to switch, it handles fine. My concern is recommending the developers add that snippet of code without knowing what’ll happen for internationalization, but it might be that I can’t get an answer until I ask them that. :simple_smile:
  48. zakim-robot
    19:30
    [klara] They just rely on me to explain what needs to happen for accessibility and on this one, I’m pretty fuzzy.
  49. zakim-robot
    19:32
    [karlgroves] @klara I apologize but I’m confused about what your question actually is. Do you want to know how to add that code or why it should be added?
  50. zakim-robot
    19:33
    [klara] @karlgroves I guess I want to know how one switches that out to handle internationalization. If I add <html lang=“en”> will that get stuck as the default regardless of the language of the page?
  51. zakim-robot
    19:34
    [karlgroves] Yes it will be stuck that way, which is why it must be changed to the relevant language when the translation happens.
  52. zakim-robot
    19:34
    [klara] Okay. That’s enough to get started on. Thank you.
  53. zakim-robot
    19:34
    [karlgroves] I mentioned above: IMO the lang value would change when the lang itself changes. So, the same mechanism that does the translation would also change the lang attribute
  54. zakim-robot
    19:35
    [karlgroves] If the devs can change the language they definitely can change the lang attribute as well
  55. zakim-robot
    19:35
    [klara] You did mention it. Just takes a little while for me to circle my brain around things sometimes. :simple_smile:
  56. zakim-robot
    19:35
    [karlgroves] its OK
  57. zakim-robot
    19:35
    [karlgroves] Should be a relatively straight forward thing, I imagine.
  58. zakim-robot
    19:36
    [klara] I hope.
  59. jnurthen
    19:36
    @karlgroves depends on the tech stack and how the translations are being done.... should be simple but devs sometimes make things complex
  60. zakim-robot
    19:37
    [karlgroves] very true. Never underestimate the many ways devs can mess up accessibility. Hence our job security, right?
  61. jnurthen
    19:38
    i have seen instances where the translated content was only a subset of the page - and the HTML element was added generically for all languages
  62. zakim-robot
    19:39
    [karlgroves] Sure, but somewhere someone had to consciously write business logic to do that.
  63. jnurthen
    19:39
    in these cases the only thing that could be done easily was to add the lang further down the hierarchy - which is ok from an a11y point of view - as long as it is a parent of all language content - but makes some validation tools barf
  64. jnurthen
    19:40
    i.e. i have had to put the lang attribute on the body element or lower occasionally just due to silly architecture
  65. zakim-robot
    19:41
    [karlgroves] Was that being added server side?
  66. jnurthen
    19:41
    yeah
  67. jnurthen
    19:41
    although i forget the specifics.... this was on an obsolete product a long time ago
  68. zakim-robot
    19:41
    [karlgroves] Wait. NM. Doesn’t matter. Even in that case you could add it to the <html> element with JS
  69. jnurthen
    19:42
    yep.... you certainly could
  70. jnurthen
    19:42
    i certainly wouldn't recommend that approach it is just sometimes pragmatically you have to go with a working solution even if not optimal
  71. zakim-robot
    19:43
    [karlgroves] Yeah.
  72. zakim-robot
    19:43
    [klara] Possibilities++ Thanks for the input. I appreciate the help. And the patience.
  73. zakim-robot
    19:43
    [karlgroves] :+1+
  74. zakim-robot
    20:08
    [bmeunier] What’s the lastest stats for daltonism?
  75. zakim-robot
    20:24
    [karlgroves] Did you give Google a shot?
  76. jasonday
    20:30
    Rounding back to the jQuery debate, let's remember that efficiency and readability in code is very important to the overall maintenance of the site. JQ is highly readable, and depending on the size of your site, writing in JQ + the JQ library may be smaller than the corresponding JS to achieve the same thing.
  77. jasonday
    20:33
    So, if you take @powrsurg 's comparison - if you multiple that times 1000, the savings of JQ is realized (don't quote me on the actual numbers).
  78. powrsurg
    20:47
    I find that HIGHLY unlikely to be the case
  79. powrsurg
    20:47
    I understand the readability aspect, but it most certainly is not going to result in a site that is actually smaller ...
  80. zakim-robot
    20:49
    [karlgroves] I can’t imagine the choice of JS library having any impact one way or the other on dev time except when it is first adopted
  81. jasonday
    20:50
    on the scale of large sites, I think it does & can. On our site, we have reformulated a lot of our older code (vanilla JS) using JQ and saw reductions of thousands of lines.
  82. zakim-robot
    20:51
    [karlgroves] reduction of thousands of lines of code?
  83. jasonday
    20:51
    Well, when you're talking 100 lines versus 5 lines - there's a time savings different there right off the bat as well as debugging/maintenance savings
  84. jasonday
    20:52
    @zakim-robot - yeah. Old, dated js
  85. jkva
    20:52
    Personally I highly value the monadic style of programming JQ gives me. Although I'm sure this could be achieved on a smaller footprint than all of JQ. Especially given the modern querySelector
  86. jkva
    20:52
    Currently BlissfulJS gives me a nice balance between the two
  87. zakim-robot
    20:54

    [karlgroves] @jasonday but it really isn’t 100 lines vs. 5. It might be 5 lines in your code, but you’re not literally deleting 95 lines of code.

    Don’t get me wrong, I’m not bashing jQuery, but it doesn’t seem like you’re comparing apples to apples.

  88. jkva
    20:55
    I like small libraries that give me nice composition of features. That allows me to be flexible and can switch / adopt without having to start over or suffer from lockin
  89. powrsurg
    20:57
    @karlgroves that is what I'm saying. I've worked on large sites and I can't imagine that the vanilla JS solutions are truly larger than the jquery library + extra ...
  90. powrsurg
    20:57
    I mean, it could be technically possible, but that seems more like you're trying to make it longer lines ...
  91. jasonday
    20:58
    yeah, but we're talking about time & maintenance savings as well as overall site savings. When you're dealing with really large scale sites, it's just not practical to write large scale applications in pure JS. You will see a benefit from using JQ from a size perspective, and from the debugging/maintenance angle - especially when code has a lot of different hands on it. My apples to apples was that when you scale up the "100 lines vs 5", you do start to see savings by using JQ. And, which would you rather maintain - 10,000 lines or 500?
  92. jnurthen
    20:59
    @jasonday +1
  93. jkva
    20:59
    Unless you end up writing your own in-house lib (to deal with keeping your code dry) but then might as well use JQ and stand on their shoulders
  94. jkva
    21:01
    Large sites have large codebases (what constitutes large anyway? Maybe different discussion) - the first hit is the heaviest, after that the browser caches the file. Either your own (by that time, large) lib gets cached, or JQ (or whatever other lib you use) gets cached. Even better chance of that when using a CDN.
  95. powrsurg
    21:01
    and again, my other argument was in regards to handling on low-end mobile devices. They WILL make the site sluggish when using a large library
  96. jkva
    21:01
    Original point that a dev whom knows vanilla besides a lib is a good dev - still stands.
  97. jasonday
    21:02
    I'm not bashing vanilla JS either; we use it plenty as it is faster in it's execution in some scenarios over JQ. I was just challenging the assertion that vanilla JS is likely better for an end-user. Additionally, JQ can be a hog. We typically do a custom build, in modules, to load dynamically for only what is needed - to address @powrsurg 's low end mobile devices issues.
  98. jkva
    21:02
    @powrsurg : Agreed - but that only works when your site did not need a large library to begin with. A 'larger' site might either have a large home-grown 'vanilla' library, or some other library. Either way, sluggish.
  99. powrsurg
    21:02
    also, 10,000 lines on a single page sounds like you need to refactor your entire environment ....
  100. jkva
    21:02
    It's a bad thing when you use JQ to hide a single thing
  101. jkva
    21:03
    and for nothing else
  102. jasonday
    21:03
    @powrsurg - very true.