jscholes
Joined 11 years ago
Joined 11 years ago
As long as those users aren't disabled.
This doesn't sound like a healthy symptom of a positive workplace culture. I guarantee that for some people, this perspective could be flipped on its head, and rephrased as a fear of being seen as the first person to leave. Other parts of the article reaffirm that, e.g.:
> My heart would beat out of my chest before heading into an exec review.
> Once, my manager asked me to reconsider the vacation I had been planning because my team needed me. “If you go, who will cover your work?”
If this is what gets your juices flowing right now, good for you. But personally? I work hard, hard enough to justify a vacation without the accompanying guilt trip, and with sufficient diligence to make a difference and explain my decisions to leadership. Then I go home.
They do, accessibility being one of them. Rendering math in the way you describe makes it difficult, or impossible, to understand for all sorts of audiences, including those relying on screen reading software.
Interesting viewpoint. While using the service on iOS, with an active ad-free subscription, I haven't noticed any of the issues you mention. Other than sponsorship unfortunately still being required for a small subset of programming. But other than that, the app has been a pleasure to use, far more so than the streaming app from Channel 5 which seeks my position each time I press the Pause button. I now generally rate the UX of All4 above the BBC iPlayer, which was the gold standard for a while.
Polite indication that this is a problem with your organisation, not accessibility or accessibility work. The same issues can occur with design and other areas where everybody and their grandmother has an opinion; it's up to a good org to manage all of those opinions and expertise in an appropriate fashion. If they aren't, and this is making it harder for you to create accessible experiences, you should raise it with someone.
New web APIs, for sure. But the screen reader market is not fast moving, in terms of new software being adopted. The line-up of the most used three screen readers (NVDA, JAWS and VoiceOver) has not changed in over a decade, despite the individual software applications themselves undergoing changes, and of course the market share of each one increasing and decreasing over time.
> Do we seriously expect every small non-technical business eking out a living with a small store to be experts on every facet of accessibility?
No, but I also don't expect such a business to be up on the latest in security, PCI compliance, GDPR conformance and more. For that reason, they are probably either:
1. engaging a web design/development agency; and/or 2. using a pre-defined platform, like Shopify.
In the former case, I do expect anyone making money from website building to at least give accessibility some thought. For the latter, Shopify is one of the businesses you describe, as a "large tech company who can write a blank check for a large team of full-time developers who can work full time on nothing but accessibility". As such, they absolutely should be setting up small business owners for success, by making their out-of-the-box themes, widgets, flows, etc. reasonably accessible to the widest possible audience.
I'm not the original commenter, but I am a screen reader user who works in accessibility.
Unfortunately, I don't have too many good examples; the problem of hierarchical commenting systems being difficult to navigate is common across the web. There is a Reddit client for iOS, Dystopia[1], that does this extremely well for users of the built-in screen reader, VoiceOver[2], by allowing entire threads/subthreads to be collapsed and/or skipped over. On the web, you'd want to look into using hierarchical headings, nested lists and the like, to allow the structure to be conveyed semantically. HN is inexcusably bad at this, as there isn't a single heading anywhere on the site.
[1] https://www.reddit.com/r/DystopiaForReddit/ [2] https://support.apple.com/guide/iphone/turn-on-and-practice-...
Accessibility at Google suffers in the same way as most UX-related things suffer at Google. Namely, the fact that everything is constantly reinvented from scratch, rather than there being one unified way to do it. As a screen reader user, I can say that in some Google products, there can be instances of what, on the surface, should be exactly the same component, but was apparently developed in multiple different ways. This leads to the constant need to work out how accessible each instance is (and e.g. what keyboard support it has), even though I dealt with the same UI pattern minutes ago.
This is highly variable. As a screen reader user who works in accessibility with a software engineering focus, I don't consider a test to be complete if I've only evaluated what the page exposes to the accessibility API. Assessing the rendered DOM by hand, testing on different viewports where controls may be slightly or completely different, etc., are just as critical to the testing process as trying to simply use the page. But, I recognise that there are many accessibility testers out there without such a technical focus, and it is true to say that they may gloss over something if it is completely missing in the accessibility tree.