6 ms·

I work on a product for higher-ed clients, and this has deeply impacted my team over the last two years. The process has been really tedious and painful for eve

I work on a product for higher-ed clients, and this has deeply impacted my team over the last two years. The process has been really tedious and painful for everyone involved: developers, product folks, management, and the users. University admins send us automated third party a11y reports constantly, demanding that we make all of the recommended fixes immediately. We learned really quickly that several of these reports are very opinionated about how to implement ARIA tags, sometimes in ways that contradict the documentation. It can be hard to explain this to a customer trying to protect themselves legally. In addition, screenreader apps are implemented inconsistently, and reproducing/debugging the screenreader bug in your app can be really infuriating. I felt truly horrible for people who use them on a daily basis because it's an utterly prehistoric experience compared to using the web normally. The last thing is that we've had issues with getting a11y right with our front end frameworks at times to address these screenreader bugs. Ultimately, a11y is so painful and costly for us to get right that it takes up a major chunk of our development efforts these days, and we all hate working on them. The state of developing and maintaining accessible web applications feels like a sad joke given the industry's mantra to make the world a better, more connected place.

arthur_pryor 7y ago
> The state of developing and maintaining accessible web applications feels like a sad joke given the industry's mantra to make the world a better, more connected place. this also feels true of most of the industry's business models. but yeah, the mantra's just a mantra. i think lots of people repeat that and think it sounds like a good goal, but they never really examine whether they're contributing to it. people can bullshit themselves pretty easily. and a lot of other folks just pay lip service to that mantra so they can make money.
inetknght 7y ago
> Ultimately, a11y is so painful and costly for us to get right that it takes up a major chunk of our development efforts these days, and we all hate working on them. Honestly, I expect this question would be difficult to answer in short time or without context. I think it'd be good discussion subject for a blog post. But: what are some examples of the pain and what would you change to simplify?
- deleted 7y ago
  [deleted]
- existencebox 7y ago
  Not OP, but have done two large site UX overhauls in recent history, and my team/company takes accessibility _very_ seriously. The biggest pain point for me has been the lack of a "Ground Truth" static-analysis-esque tool. We're provided some accessibility-issue-highlighting tooling, and there are some open source as well, but it's very common to get a11y tickets where the tool won't pick up the underlying issue, or will say "there's an issue" but not what the correct threshold is for fixing it (e.g. border contrast/density) so there's a bit of trial and error in there too. If we had something similar to the "green squiggles" in IDEs, with, in my perfect world, the "right click->see suggestions ->auto-fix" flow that I can now get in code, addressing these issues would be SIGNIFICANTLY similar. This is only one facet however, although it brushes against other issues in this space (inconsistent behavior of screen readers, occasionally not having sufficient specialized hardware to even test the scenario fully, often having to "negotiate" accessibility fixes with the designers who gave the original layouts, etc.) Also, a final thing that I'm always curious is "just me" or not, but tab-ordering-fixes have seemed far more painful to handle (in dynamic/scalable layout scenarios) than I would have thought going in. The two options I know of for dealing with it are "assign the order" and "adjust your HTML/Z" layout, and the former is a very blunt hammer while the latter sometimes seems to be at odds with other requirements of the layout. (but this could very well be my naivete in frontend, thus this ramble)
  - acdha 7y ago
    Agreed. I've been happy to see aXe getting more visibility so it's easy to do at least the basic smoke testing similarly to other kinds of static analysis but it's definitely an area which is open for much greater improvement.
- shados 7y ago
  Also not OP, but... Getting things to be accessible (in practice: not just what some tool spits out in a report, but making the app/site useful to a real user with disabilities using a real browser of some sort) is not that bad as long as everyone's on board (if the designer wants everything drag & drop in red and green tones, you're kind of screwed). Catering to screen readers is hard for the same reason supporting any non-60%+ user base browser is (uncommon mobile browsers, IE, whatever). All browsers have bugs and quirks, and having less eyes on things makes finding bugs hard. Debugging in a browser you don't use as frequently is always going to be significantly more challenging. When its not a "standard" one, it can be hell. As another poster mentioned, a lot of the automated tools spit out a lot of false positives, and that adds to the burden.
klenwell 7y ago
I empathize. My last job was with a university that got tagged with a lawsuit threat around the time I started. Accessibility stories eventually dominated our backlog. I appreciated being able to improve accessibility. But the lack of consistent standards and the legal department's lazy and inflexible response to the issue were demoralizing. One of the first things I did in my next position was to bring on a Site Accessibility Engineer (I think I made that term up) to get out in front of issues like this. She was a graduate of a developer bootcamp with past experience assisting people with real-world accessibility issues. She's been invaluable.
- jerf 7y ago
  "She was a graduate of a developer bootcamp with past experience assisting people with real-world accessibility issues." That's one of the best "boot camp" use cases I've ever heard. An accessibility engineer like that doesn't necessarily need to be able to actually code up a backend with a database, etc, but is going to be greatly handicapped if they literally know nothing about the web and can't even show off a prototyped-up page with the new markup they are proposing. They don't need a full "computer science" education, a boot camp is a perfect bootstrap. (I'd still say there's things yet to learn, but when isn't that true?)
  - pmiller2 7y ago
    Sure, but where do they get their second tech job? Site accessibility engineer is not a common job title/position that I know of. Without some of those skills you mention, if not the corresponding formal education, that seems like this person is set up to fail soon, unless companies really start taking accessibility seriously in the next few years.
    - cbsks 7y ago
      From reading the other comments in this thread, it seems that companies are starting to take accessibility seriously, and an experienced site accessibility engineer will not have any issues getting another job.
    - 7y ago
liquidise 7y ago
I went to the A11y page to see what it was. Ironically, the single largest answer on their Learn More[1] page is them explaining what "A11y" even means. I'm trying not to draw sweeping conclusions about the project from this, but damn that's a bad start. 1: https://a11yproject.com/about/#what-does-the-term-a11y-mean https://a11yproject.com/about/#what-does-the-term-a11y-mean
- sigstoat 7y ago
  > I went to the A11y page that's like saying "i went to the mathematics page". there's not an a11y page. > I'm trying not to draw sweeping conclusions about the project from this... you went to the page of some small community effort.
  - joemi 7y ago
    I'm not who you replied to, but as someone unfamiliar with the term "a11y", I googled it while reading these comments and the very first hit is https://a11yproject.com/ https://a11yproject.com/ which I, too, assumed was "the a11y page" -- and after briefly looking at that page again just now, I'm still not convinced that it shouldn't be considered the canonical "a11y page". I now get that "a11y" is a numeronym for "accessibility", but considering I haven't heard it called "a11y" before today, a page calling itself The A11Y Project sounds both fairly authoritative and like it potentially could have been the source of the a11y numeronym. If it's not, it really could use some more explanation on that page.
    - jamesgeck0 7y ago
      > The A11Y Project sounds both fairly authoritative and like it potentially could have been the source of the a11y numeronym. If it's not, it really could use some more explanation on that page. The explanation is on the about page.
      - joemi 7y ago
        I've now read that entire page several times, and I don't believe that the explanation is truly there. The about page does a good job of explaining why accessibility is important, what "A11Y" means, and states that The Accessibility Project's goal is essentially to further accessibility on the web. It's very easy to interpret that page as meaning/implying they originated the term "A11Y" and/or that "A11Y" is specifically related to The A11Y Project, and therefore that The A11Y Project page is the defacto "A11Y page", for someone who has not come across the numeronym "a11y" before. But whatever... This is rather off-topic to the main point of this HN post.
daxorid 7y ago
Indeed. My business is currently being targeted by these ambulance-chasers, but we are not a college with a well-staffed IT department; we are an ecommerce business with a single front-end developer on staff. Annoying, to say the least.
- austincheney 7y ago
  Yeah, I have no sympathy for you. What’s really happening is that you are delivering a discriminatory experience out of convenience. It’s no different than a restaurant server delivering shitty service to a black family because they stereotyped that people with kids and black people tip less. If your developer takes the technology seriously you should be able to nail about 80% of WCAG AA compliance with minimal effort. I suspect instead your frontend is knee deep in frameworks and abstractions to make the developer’s life easier without regard for the imposed costs of these abstractions.
  - will4274 7y ago
    > It’s no different than a restaurant server delivering shitty service to a black family because they stereotyped that people with kids and black people tip less. Come on now. Stereotyping is an affirmative action, failing to consider accessibility is passive / apathy. It's comparable to not installing a handicap ramp for your restaurant.
    - austincheney 7y ago
      It’s an active decision to disregard accessibility as a business liability, also known as negligence, which is different than an accident.
  - joenot443 7y ago
    I would say it's more similar to distributing menus without braille translations. It's also very possibly their developer is woefully overworked, and what may amount to 'minimal effort' for you, could be outside the scope of what they have the time to accomplish.
mkozlows 7y ago
I spent a while working at an accessibility company, and while I was there, worked on two separate things: 1. Remediating customers' sites that were inaccessible. (Which, btw, for all the "ambulance chaser" comments: Something like 100% of our customers were working with us because they had been sued; none of them were doing so because they had a sincere commitment to accessibility, so there's a reason these lawsuits happen.) 2. Developing our own web-based software, which obviously had to be fully-accessible from minute one, both because a large fraction of the people using it would be blind, and because obviously it had to be, come on. Making changes to customers' sites was deeply, deeply painful, as we tried to work around fundamentally inaccessible designs and make things as close to acceptable as we could, given the reality of what we had to work with. Everything that the parent comment says here was 100% true. Building our own software to be fully accessible, on the other hand, added some extra effort (largely around manual testing, since automated testing can only take you so far), but we're talking about like... 10%? If you have a dev team that's been trained on a11y and is committed to producing an accessible product, it's not super-hard to make that happen. That basically no dev teams work this way says nothing good about our industry.
- FakeComments 7y ago
  What percentage of products, in general, do you believe are “accessible”?
- scarecrowbob 7y ago
  Your experience resonates with mine. IMO, if you start off with sane good practices, it's really not that difficult to work for a11y in web. Just adhering to good markup and keyboard-first navigation will get you most of the way "there", especially if the designers are aware of their constraints and designing with a11y in mind. But reworking stuff that isn't already working around a11y is a massive pain in the ass. So I "get" it, and I've built a lot of stuff that doens't serve every population as well as it could have if I had been more informed. But at this point, for new work it doesn't feel like much of a burden at all, any more than using git or linters or whatever other stuff we do because it's a helpful practice.
evunveot 7y ago
I'm in the same boat, but I'm just a contract web developer for a college within a public university. Turns out the university now requires outside "vendors" to provide a Voluntary Product Accessibility Template [0] and they're not allowed to purchase any "products" that aren't WCAG 2.0 AA. The VPAT essentially lists every individual WCAG guideline and asks to what level your "product" is compliant. This came up because my client within the college is trying to get approval for me to make some updates to the site (which I built for them 4 years ago, taking pains for accessibility before they even had a policy about it) to align with new branding guidelines which are also being imposed from above by the university. I've tried to argue that the VPAT doesn't make any sense because they're not buying a "product" from me, they're paying me to do original work, so if anything they should provide me a VPAT as a form of specification. But the feedback I'm getting is that I should essentially pretend that the "product" is the entire website (including all the content added by college staff over the years), which means I'm supposed to essentially audit every page against the VPAT, or lie and say I did (which I would never do). My only remaining tack is to appeal to the undue burden they're imposing on my small business. Never mind that the website I built for the college is demonstrably more accessible than that of the university itself. [0] https://www.itic.org/policy/accessibility/vpat https://www.itic.org/policy/accessibility/vpat
- extra88 7y ago
  If they could ask anyone to update the site because they host it and it belongs to them, you're right, you shouldn't have to provide a VPAT. However, they should include in any new contract for contract work that the end result be accessible according to their standards (WCAG 2.0 AA). A VPAT could be used as a template for documenting the accessibility of the newly completed work but there are better options. If they wanted documentation of the accessibility of the existing site, before you make any changes, and they wanted it in VPAT format, again, there are better tools but that should be considered separate, additional work.
mises 7y ago
With that much work being required, could the case be made that goes beyond a "reasonable accommodation"? Maybe that would mean that some of the less-trafficked pages would not need tagging, though maybe the more major and commonly-accessed ones represent a reasonable accommodation.
mwcampbell 7y ago
> [using the web with a screen reader is] an utterly prehistoric experience compared to using the web normally. I think that's too harsh a criticism of screen readers. Can you give more details about why you think it's that bad?
ckundo 7y ago
Lot's of love for accessibility folks in education. Maybe a small consolation, but we just made AccessLint, our GitHub code review application free for edu's, inspired by this thread.

arthur_pryor 7y ago

> The state of developing and maintaining accessible web applications feels like a sad joke given the industry's mantra to make the world a better, more connected place. this also feels true of most of the industry's business models. but yeah, the mantra's just a mantra. i think lots of people repeat that and think it sounds like a good goal, but they never really examine whether they're contributing to it. people can bullshit themselves pretty easily. and a lot of other folks just pay lip service to that mantra so they can make money.

inetknght 7y ago

> Ultimately, a11y is so painful and costly for us to get right that it takes up a major chunk of our development efforts these days, and we all hate working on them. Honestly, I expect this question would be difficult to answer in short time or without context. I think it'd be good discussion subject for a blog post. But: what are some examples of the pain and what would you change to simplify?

deleted 7y ago
[deleted]
existencebox 7y ago
Not OP, but have done two large site UX overhauls in recent history, and my team/company takes accessibility _very_ seriously. The biggest pain point for me has been the lack of a "Ground Truth" static-analysis-esque tool. We're provided some accessibility-issue-highlighting tooling, and there are some open source as well, but it's very common to get a11y tickets where the tool won't pick up the underlying issue, or will say "there's an issue" but not what the correct threshold is for fixing it (e.g. border contrast/density) so there's a bit of trial and error in there too. If we had something similar to the "green squiggles" in IDEs, with, in my perfect world, the "right click->see suggestions ->auto-fix" flow that I can now get in code, addressing these issues would be SIGNIFICANTLY similar. This is only one facet however, although it brushes against other issues in this space (inconsistent behavior of screen readers, occasionally not having sufficient specialized hardware to even test the scenario fully, often having to "negotiate" accessibility fixes with the designers who gave the original layouts, etc.) Also, a final thing that I'm always curious is "just me" or not, but tab-ordering-fixes have seemed far more painful to handle (in dynamic/scalable layout scenarios) than I would have thought going in. The two options I know of for dealing with it are "assign the order" and "adjust your HTML/Z" layout, and the former is a very blunt hammer while the latter sometimes seems to be at odds with other requirements of the layout. (but this could very well be my naivete in frontend, thus this ramble)
- acdha 7y ago
  Agreed. I've been happy to see aXe getting more visibility so it's easy to do at least the basic smoke testing similarly to other kinds of static analysis but it's definitely an area which is open for much greater improvement.
shados 7y ago
Also not OP, but... Getting things to be accessible (in practice: not just what some tool spits out in a report, but making the app/site useful to a real user with disabilities using a real browser of some sort) is not that bad as long as everyone's on board (if the designer wants everything drag & drop in red and green tones, you're kind of screwed). Catering to screen readers is hard for the same reason supporting any non-60%+ user base browser is (uncommon mobile browsers, IE, whatever). All browsers have bugs and quirks, and having less eyes on things makes finding bugs hard. Debugging in a browser you don't use as frequently is always going to be significantly more challenging. When its not a "standard" one, it can be hell. As another poster mentioned, a lot of the automated tools spit out a lot of false positives, and that adds to the burden.

klenwell 7y ago

I empathize. My last job was with a university that got tagged with a lawsuit threat around the time I started. Accessibility stories eventually dominated our backlog. I appreciated being able to improve accessibility. But the lack of consistent standards and the legal department's lazy and inflexible response to the issue were demoralizing. One of the first things I did in my next position was to bring on a Site Accessibility Engineer (I think I made that term up) to get out in front of issues like this. She was a graduate of a developer bootcamp with past experience assisting people with real-world accessibility issues. She's been invaluable.

jerf 7y ago
"She was a graduate of a developer bootcamp with past experience assisting people with real-world accessibility issues." That's one of the best "boot camp" use cases I've ever heard. An accessibility engineer like that doesn't necessarily need to be able to actually code up a backend with a database, etc, but is going to be greatly handicapped if they literally know nothing about the web and can't even show off a prototyped-up page with the new markup they are proposing. They don't need a full "computer science" education, a boot camp is a perfect bootstrap. (I'd still say there's things yet to learn, but when isn't that true?)
- pmiller2 7y ago
  Sure, but where do they get their second tech job? Site accessibility engineer is not a common job title/position that I know of. Without some of those skills you mention, if not the corresponding formal education, that seems like this person is set up to fail soon, unless companies really start taking accessibility seriously in the next few years.
  - cbsks 7y ago
    From reading the other comments in this thread, it seems that companies are starting to take accessibility seriously, and an experienced site accessibility engineer will not have any issues getting another job.
  - 7y ago

liquidise 7y ago

I went to the A11y page to see what it was. Ironically, the single largest answer on their Learn More[1] page is them explaining what "A11y" even means. I'm trying not to draw sweeping conclusions about the project from this, but damn that's a bad start. 1: https://a11yproject.com/about/#what-does-the-term-a11y-mean https://a11yproject.com/about/#what-does-the-term-a11y-mean

sigstoat 7y ago
> I went to the A11y page that's like saying "i went to the mathematics page". there's not an a11y page. > I'm trying not to draw sweeping conclusions about the project from this... you went to the page of some small community effort.
- joemi 7y ago
  I'm not who you replied to, but as someone unfamiliar with the term "a11y", I googled it while reading these comments and the very first hit is https://a11yproject.com/ https://a11yproject.com/ which I, too, assumed was "the a11y page" -- and after briefly looking at that page again just now, I'm still not convinced that it shouldn't be considered the canonical "a11y page". I now get that "a11y" is a numeronym for "accessibility", but considering I haven't heard it called "a11y" before today, a page calling itself The A11Y Project sounds both fairly authoritative and like it potentially could have been the source of the a11y numeronym. If it's not, it really could use some more explanation on that page.
  - jamesgeck0 7y ago
    > The A11Y Project sounds both fairly authoritative and like it potentially could have been the source of the a11y numeronym. If it's not, it really could use some more explanation on that page. The explanation is on the about page.
    - joemi 7y ago
      I've now read that entire page several times, and I don't believe that the explanation is truly there. The about page does a good job of explaining why accessibility is important, what "A11Y" means, and states that The Accessibility Project's goal is essentially to further accessibility on the web. It's very easy to interpret that page as meaning/implying they originated the term "A11Y" and/or that "A11Y" is specifically related to The A11Y Project, and therefore that The A11Y Project page is the defacto "A11Y page", for someone who has not come across the numeronym "a11y" before. But whatever... This is rather off-topic to the main point of this HN post.

daxorid 7y ago

Indeed. My business is currently being targeted by these ambulance-chasers, but we are not a college with a well-staffed IT department; we are an ecommerce business with a single front-end developer on staff. Annoying, to say the least.

austincheney 7y ago
Yeah, I have no sympathy for you. What’s really happening is that you are delivering a discriminatory experience out of convenience. It’s no different than a restaurant server delivering shitty service to a black family because they stereotyped that people with kids and black people tip less. If your developer takes the technology seriously you should be able to nail about 80% of WCAG AA compliance with minimal effort. I suspect instead your frontend is knee deep in frameworks and abstractions to make the developer’s life easier without regard for the imposed costs of these abstractions.
- will4274 7y ago
  > It’s no different than a restaurant server delivering shitty service to a black family because they stereotyped that people with kids and black people tip less. Come on now. Stereotyping is an affirmative action, failing to consider accessibility is passive / apathy. It's comparable to not installing a handicap ramp for your restaurant.
  - austincheney 7y ago
    It’s an active decision to disregard accessibility as a business liability, also known as negligence, which is different than an accident.
- joenot443 7y ago
  I would say it's more similar to distributing menus without braille translations. It's also very possibly their developer is woefully overworked, and what may amount to 'minimal effort' for you, could be outside the scope of what they have the time to accomplish.

mkozlows 7y ago

I spent a while working at an accessibility company, and while I was there, worked on two separate things: 1. Remediating customers' sites that were inaccessible. (Which, btw, for all the "ambulance chaser" comments: Something like 100% of our customers were working with us because they had been sued; none of them were doing so because they had a sincere commitment to accessibility, so there's a reason these lawsuits happen.) 2. Developing our own web-based software, which obviously had to be fully-accessible from minute one, both because a large fraction of the people using it would be blind, and because obviously it had to be, come on. Making changes to customers' sites was deeply, deeply painful, as we tried to work around fundamentally inaccessible designs and make things as close to acceptable as we could, given the reality of what we had to work with. Everything that the parent comment says here was 100% true. Building our own software to be fully accessible, on the other hand, added some extra effort (largely around manual testing, since automated testing can only take you so far), but we're talking about like... 10%? If you have a dev team that's been trained on a11y and is committed to producing an accessible product, it's not super-hard to make that happen. That basically no dev teams work this way says nothing good about our industry.

FakeComments 7y ago
What percentage of products, in general, do you believe are “accessible”?
scarecrowbob 7y ago
Your experience resonates with mine. IMO, if you start off with sane good practices, it's really not that difficult to work for a11y in web. Just adhering to good markup and keyboard-first navigation will get you most of the way "there", especially if the designers are aware of their constraints and designing with a11y in mind. But reworking stuff that isn't already working around a11y is a massive pain in the ass. So I "get" it, and I've built a lot of stuff that doens't serve every population as well as it could have if I had been more informed. But at this point, for new work it doesn't feel like much of a burden at all, any more than using git or linters or whatever other stuff we do because it's a helpful practice.

evunveot 7y ago

I'm in the same boat, but I'm just a contract web developer for a college within a public university. Turns out the university now requires outside "vendors" to provide a Voluntary Product Accessibility Template [0] and they're not allowed to purchase any "products" that aren't WCAG 2.0 AA. The VPAT essentially lists every individual WCAG guideline and asks to what level your "product" is compliant. This came up because my client within the college is trying to get approval for me to make some updates to the site (which I built for them 4 years ago, taking pains for accessibility before they even had a policy about it) to align with new branding guidelines which are also being imposed from above by the university. I've tried to argue that the VPAT doesn't make any sense because they're not buying a "product" from me, they're paying me to do original work, so if anything they should provide me a VPAT as a form of specification. But the feedback I'm getting is that I should essentially pretend that the "product" is the entire website (including all the content added by college staff over the years), which means I'm supposed to essentially audit every page against the VPAT, or lie and say I did (which I would never do). My only remaining tack is to appeal to the undue burden they're imposing on my small business. Never mind that the website I built for the college is demonstrably more accessible than that of the university itself. [0] https://www.itic.org/policy/accessibility/vpat https://www.itic.org/policy/accessibility/vpat

extra88 7y ago
If they could ask anyone to update the site because they host it and it belongs to them, you're right, you shouldn't have to provide a VPAT. However, they should include in any new contract for contract work that the end result be accessible according to their standards (WCAG 2.0 AA). A VPAT could be used as a template for documenting the accessibility of the newly completed work but there are better options. If they wanted documentation of the accessibility of the existing site, before you make any changes, and they wanted it in VPAT format, again, there are better tools but that should be considered separate, additional work.

mises 7y ago

With that much work being required, could the case be made that goes beyond a "reasonable accommodation"? Maybe that would mean that some of the less-trafficked pages would not need tagging, though maybe the more major and commonly-accessed ones represent a reasonable accommodation.

mwcampbell 7y ago

> [using the web with a screen reader is] an utterly prehistoric experience compared to using the web normally. I think that's too harsh a criticism of screen readers. Can you give more details about why you think it's that bad?

ckundo 7y ago

Lot's of love for accessibility folks in education. Maybe a small consolation, but we just made AccessLint, our GitHub code review application free for edu's, inspired by this thread.