91–100 of 118 posts
Earlier quoted context omitted.
Too bad copyreaders are a dying profession 'cause you'd be a natural.
Eh, it's not like I crave copyreading. So I don't mind being automated away by spell checkers in that department.
IMO, this is long overdue, especially considering how large these populations are. Things to consider here relate to text presentation and overall site layout. Think about text sizing/contrast, line spacing, column width, and paragraph height, for example. And consider how each of these things changes when the user is on mobile (paragraphs are now much taller, creating the "wall of text" that many people dread).
- Use blind accessibility tools with your website. If you're on iOS/macOS enable VoiceOver, figure out how it works, close your eyes and use your website. - Disable JavaScript and use your website. This may not be relevant for web apps, but regular websites should work normally. - Try to use your website with only the keyboard. - Try to use your website with extreme zoom levels and font size overrides. - Monitor your…
I'm lucky enough to have a low-vision person who works as a tester on my team, and does our accessibility testing. It's very impressive watching/listening to him use a screen reader - I was really amazed at how fast he has it set to read the screen. He does suggest all the things you've mentioned above, and it's good advice. However one thing he also says is: don't assume that low-vision is the only type of disabilit…
A good takeaway was feeling their frustration with improperly labeled items. You want to order keywords first, for instance "March 25, created on" instead of "Created on March 25", because they have to wait through "Created on:" dozens of times, when they already know the label context.
Good points on the other accessibility areas.
You can use chrome dev tools. Right click the window and click 'inspect'. In the 'Audits' tab, you can run an audit for accessibility. It runs your website and checks it against common accessibility criteria, giving you a score out of 100. On a side note, running this page through the accessibility audit, gives a score of 33. Perhaps HN has some work to do on accessibility.
HN it's very obviously bad for accessibility, small click/touch targets, grey-on-grey text with v. low contrast in some situations (by design), poor indent-level visibility. Using 'shade of grey' to convey information is never going to be great. Table-based layout can screw up screen-readers, I assume it's still 'tabulated but non-tabular'. Way back screen-readers used to assume the first tr contained th even if it w…
I use a screen reader and am a frequent reader of HN. Obviously, much of the site's content is textual - you can't include images in comments AFAIK and it's extremely rare for people to link to graphical content as people often do on Reddit. So from that point of view, the site is an oasis away from the often visual nature of the modern web. On the other hand, there is absolutely no way for my screen reader to gauge whether a comment is a child of another, quickly jump past a child thread that I'm not interested in, quickly move up to the parent or grandparent of the current comment, etc.
TL;DR: the content is accessible because it's text, but accessible navigation is non-existent.
Earlier quoted context omitted.
> JAWS + IE is the most popular combination It's worth keeping a few points in mind when reading these results: 1. The survey was carried out in October 2017. Things can and do move quite rapidly in this area, especially given the increased number of users who will be running Windows 10 now who may not have been back then. 2. IE won't be around forever, and once the accessibility of Microsoft Edge improves (which is…
My only comments to that would be WebAim is the highest authority on accessibility. I'm well aware that these combinations will change over time. The biggest thing is that JAWS costs a lot of money, so people buy, get used to it, and stick with their setup. I tend to say, 'The only people who still use IE have no choice" or something like that.
I'm not sure that's strictly true nor measurable, or really matters in this case when we're discussing a survey filled out by users.
Earlier quoted context omitted.
What does that have to do with accessibility? > You seem to be implying that anyone with a visual impairment, even a partial one I am not. Well written CSS, a subset of usability, is irrelevant to accessibility.
> Well written CSS, a subset of usability, is irrelevant to accessibility. Says who? https://www.w3.org/WAI/fundamentals/accessibility-usability-... > There is a significant overlap between accessibility and usability. ISO 9241-11, defines usability as: The “extent to which a product can be used by specified users to achieve specified goals effectively, efficiently and with satisfaction in a specified context of use”…
Yes, it is still accessible, but usability is decreased. There are multiple ways to activate a button. Accessibility and usability are not contested or mutually exclusive qualities. You can have both great CSS and great accessibility at the same time.
Earlier quoted context omitted.
I would add, to really test, after turning on voice over, turn off your monitor. This will let you test if you can explore your website with the visual structure.
Don't do this - the best way to evaluate is to compare the visual output with the auditory output, something you can't do if the screen is turned off.
Earlier quoted context omitted.
> Well written CSS, a subset of usability, is irrelevant to accessibility. Says who? https://www.w3.org/WAI/fundamentals/accessibility-usability-... > There is a significant overlap between accessibility and usability. ISO 9241-11, defines usability as: The “extent to which a product can be used by specified users to achieve specified goals effectively, efficiently and with satisfaction in a specified context of use”…
> but the icons break at high zoom levels, then is that accessible? Yes, it is still accessible, but usability is decreased. There are multiple ways to activate a button. Accessibility and usability are not contested or mutually exclusive qualities. You can have both great CSS and great accessibility at the same time.
If just the ability to access the content was the only factor in designing accessible content, then you could just tell your blind clients to view the page source and read it character by character. But obviously that would not be acceptable because it creates a significant barrier for usability that sighted clients would not face. Designing accessible content is about removing barriers that make it harder for people with disabilities to access the content, and bad usability is one of those barriers.
Earlier quoted context omitted.
> but the icons break at high zoom levels, then is that accessible? Yes, it is still accessible, but usability is decreased. There are multiple ways to activate a button. Accessibility and usability are not contested or mutually exclusive qualities. You can have both great CSS and great accessibility at the same time.
Bad usability precludes good accessibility. You seem to be implying that accessibility is just about being able to access the content. That's wrong, accessibility is about ease of access to the content. If what you were saying were true, then semantically correct HTML wouldn't be a WCAG requirement. But semantically correct HTML improves usability for people using assistive technologies, thus it is an important part…
That doesn't account for cognitive disabilities.
Ease of access is up to the user-agent software. Accessibility is more than just that. As front end developers we have to provide that content in a meaningful and understandable form without getting in the browser's or screen reader's way. Sometimes that isn't enough and you need to use ARIA to clarify things more precisely.
> then you could just tell your blind clients to view the page source and read it character by character.
Screen readers provide a variety of navigational tools for drilling into page content. They don't just read text.
I am not really sure what you are arguing. You can have great CSS and great accessibility at the same time.