What version? I tested my blogpost on Safari and added stuff specifically to accommodate it - the only known broken thing is the color picker, and I mention it in the post.
Original HN title: You no longer need JavaScript: an overview of what makes modern CSS so awesome
Changed HN title: Aspects of modern HTML/CSS you may not be familiar with
As the author, I don't really have a problem with either title :).
Externally, the title is meant to be augmented by the summary (as seen in the original HN title), and I much prefer that over just the title alone by itself. I usually make my titles fun and catchy, and a part of the story I want to tell, while the summary's there to provide a more neutral and accurate overview of the post before people click on it.
The post's story doesn't make sense with the changed title, but that's not an issue because if people click on the link they'll see the original title on the website. I don't mind the title of an external link being more descriptive.
could you give any examples of how the page's accessibility could be improved - apart from your dislike of the background color
you're calling the post un-accessible and telling people to not use it as a source - i'd like to know why you think that, and if there's any way to improve the accessibility
This is not my dislike of the background colour (blue is actually my favourite colour, well teal), nothing in that comment was an opinion. The WCAG (Web Content Accessibility Guidelines) have standards for colour contrast [1]. If you turn on developer tools in your browser and go to accesbility you will see how many elements do not conform to these standards. The site falls astray of this in the most common way, which is blue links on a blue background, making link text very hard to read.
i am aware that the link color specifically is not ideal and i have been playing around with designs that feel similar while having better contrast - but your comment seemed to call the entire site un-accessible, so i was wondering if there's anything else that stood out and that could be improved
I am aware that people who read the blog might base parts of their websites on my examples, so I definitely want to make sure they're accessible as to not cause a negative ripple effect on the web.
I don't have a background in accessibility, but I try to do the best I can. I try out what I make with various accessibility tools (e.g. keyboard navigation, screenreaders), and also read up on how things should be handled.
For the radio tabs specifically - they are keyboard navigable, work with screenreaders, and follow the tabbing to content practice mentioned in the WAI-ARIA example[0].
Thanks! Sorry if I came off as brash, time has been tight recently. You've already put a lot of work into a very informative article, and it's appreciated. The outlook is solid. I'd like to find an opportunity to revisit some of my own code with your writing in mind.
Part of the reason for mentioning the radio-tabs is because I was working on my own implementation for a personal project a few weeks ago. My goal was specifically using the role="tab"/role="tabpanel" pattern, but my read of the guidance left me feeling like I was trapped with using JS to set those. Since it was timeboxed, I bailed out to augmenting it with JS for and moved on.
My hope was maybe somebody on HN with more of a background on accessibility could interject some thoughts here.
Of course. I think JS is full of mistakes. To be fair some of the more egregious ones have been fixed, but there are still plenty left.
I'm a big believer in learning new stuff, when that stuff has lasting value. However it is far more efficient to fix things, a one time cost that benefits everyone, than to ask everyone to learn the quirks of a tool, a cost that is paid every time someone new comes along.
reply