1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

Website accessibility

Discussion in 'Legal Issues' started by anotordowe, Aug 28, 2020.

  1. #1
    Hi everyone!
    I've stumbled upon these articles on website accessibility and compliance with ADA, WCAG, etc...
    https://www.atilus.com/top-10-ada-lawsuits/
    https://pixelplex.io/blog/how-to-avoid-ada-website-lawsuits/
    Now I'm not sure that my website is accessible enough to avoid lawsuits in the future. What should I do now?
     
    anotordowe, Aug 28, 2020 IP
  2. sarahk

    sarahk iTamer Staff

    Messages:
    28,494
    Likes Received:
    4,457
    Best Answers:
    123
    Trophy Points:
    665
    #2
    Fix your website?

    Read every single one of @deathshadow's posts until it's clear what needs fixing.
     
    sarahk, Aug 28, 2020 IP
    Spoiltdiva likes this.
  3. JEET

    JEET Notable Member

    Messages:
    3,825
    Likes Received:
    502
    Best Answers:
    19
    Trophy Points:
    265
    #3
    There are very few basic things you need to do to get this working.

    1. Use alt tag in your images, and tell what the image is, specially if its a link to another page.
    ex:
    <a href="contact.php">
    <img src="images/ccc.jpg" alt=" contact us " />
    </a>

    Note that your image file is also not named as "contact".
    If there is no alt tag, a screen reader will try to read the file name, in this case, "images/ccc.jpg"
    which is also not telling anything about what the link is.
    So you "NEED" the alt tag.

    2. Avoid using those javascript drop downs menus and drop boxes.
    Use plain HTML dropdown box, and its fine.
    For dropdown menus, at the very least provide a separate plain html sitemap.
    Even better, do not use those javascript dropdown menus at all.
    There are much better ways of showing navigation.

    3. Avoid using javascript actions on important links.
    Like in Login links.
    Stackoverflow was using some kind of crap js on "login with facebook/google" links, which screen readers were not accessing.
    Screen readers read those links, but could not click it.
    They have changed it now.
    But now their "submit question" form does not works with screen readers properly.
    Those guys will get sued someday, am very sure.

    Use simple plain <a href=""> </a> tags.
    I don't know why people felt the need to make their links some other way...
    That ANCHOR tag works perfectly. You can do your javascript checks with those also without any problem.

    4. DO NOT make those auto vanishing alert messages when some form is submitted.
    This happens in hostgator website.
    When you login and create a ticket, they show you an alert message that ticket has been created, and that alert message vanishes in 3-5 seconds.
    People on screen readers do not find that message to figure out what has happened.
    For sighted people, its a big box in the middle of the screen, impossible to miss.
    Not the same case for people on screen readers.

    5. Do not create "only" video content for something.
    Some people cannot listen. They need a written something which they can read.
    Likewise, do not create videos with "only" text slideshows.
    Blind people cannot see those, they need audio.

    6. Do not do too much AJAX play work in your form fields.
    Some people are on virtual keyboards, and their accessibility softwares are helping them type.
    Keep your form fields simple, and you will be fine.

    7. If you want to update a DIV using ajax when something is clicked, try to keep that div near the link in the raw HTML.
    Even a DIV somewhere at bottom or top will do, and if possible, bring focus to the div using a form field when the link is clicked.
    Not required but helps.
    Avoid doing a create element on the fly using javascript. Sometimes it read, sometimes its not.


    8. If your form field needs you to select something, which is a required field, make sure to use a simple dropdown, avoid fancy.
    Gmail's "select country" on "create new email" form, does not works with screen readers.
    At least did not worked some 2 years back, not sure now.

    Basically, if you keep it simple, it will work with accessibility technologies.
    Even little bit drama work, will still work with accessibility technologies.

    Those accessibility technologies are extremely extremely extremely forgiving.
    But if you do too much show sha, then also prepare for a law suit.

    I am waiting for a law like this in my country.
    I have plan to sue like a million websites here...
     
    JEET, Aug 28, 2020 IP
  4. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #4
    @JEET, you're talking like you know what his website is. Care to share?

    Also ALT is not a tag, it's an attribute. In fact most of your terminology is wrong.

    Now that said, you also made a number of good points.

    As many of you know I've been working the past decade as a web accessibility and efficiency consultant. Specifically, I go into places being sued for non-compliance and give guidance -- and assistance re-coding -- sites to meet accessibility norms to a sufficient level to negotiate in good faith with the courts or plaintiff. Done properly you can often get any fines waved, or negotiate a more reasonable settlement if you simply fix the damned thing in a prompt and orderly fashion.

    In days past, when I first switched from full stack development unto and of itself to a focus on front end accessibility, life was easy. Most every site that failed compliance the problem was simple stuff. Improper metrics (aka using pixels for everything), fixed width layouts, invalid/improper semantics, and illegible colour contrasts. The past five or six years though a new problem has arisen: JavaScript for nothing and garbage "frameworks".

    One of the biggest blights upon web accessibility at the moment is "JavaScript for Nothing", "JavaScript without graceful degradation", also known as "JavaScript as the only means of functionality". JavaScript in and of itself is not an accessibility violation, but it should not be used for anything normal users might need to do on a normal site.

    Like navigation, contact forms, shopping carts, and basic delivery of content. If scripting off these things do not function, you are in violation of accessibility norms. PERIOD.

    These things should be coded to work without client-side scripting FIRST, and then / only then should you enhance them with JavaScript, and only as needed or in ways that improve the overall user experience.

    This is why how frameworks like React, Vue, etc, "work" are a giant middle finger to usability and accessibility since what they do is typically useless to screen readers (software reading the page aloud), braille readers, search engines, users/workplaces that block JS for security reasons, and a whole host of other perfectly valid ways of using the web. The Internet is about MORE than perfectly sighted users in front of a screen.

    The same goes for website semantics, you need to understand things like "landings" -- places keyboard and other alternative navigation methods can hook to get around the page -- and why logical document structure is so important as your working base. Your HTML should be the foundation of your accessibility, and slopping it together in a broken, nonsensical, and half-assed manner leads to non-compliance.

    Hence why these equally dumbass "front end frameworks" like bootcrap, tailfart, etc, etc, create far more problems than they solve. They too are clearly written by people who are unqualified to write a single damned line of HTML or CSS. They don't use proper semantics for logical document structure, they use broken font metrics (oft willy-nilly mixing PX and %/EM), they oft operate in complete ignorance of legibile colour contrasts out of the box, and on the whole are train wreck laundry lists of how NOT to build a website.

    ... and betwixt the two of those alone, the people who say "nobody cares about the code" are talking out their asses. Bad code leads to violation of most if not all accessibility minimums.

    Take any example from bootcrap and it's out of the box style. One of the best ways to explain accessibility violations is to take something in total violation and to break it down.

    Starting a document with a H4? 2:1 ratio of menu text color to the background color? Mix-and-match of PX media queries/widths with dynamic font sizes resulting in responsive layout being utterly broken? Abusing lists around obviously tabular data because "teh tabuls r evuls!!!" idiocy?

    Hell, take v5's splash page crap: (something we've been told for decades not to do in the first place)

    https://v5.getbootstrap.com/docs/5.0/examples/cover/

    In terms of JUST accessibility issues caused by their code, we have a H3 doing H1's job, a run-on sentence masquerading as a menu as they have anchors slopped into NAV without a UL/LI structure, H1 doing H2's job, paragraphs around non-paragraph elements like buttons/button-like anchors... and that's just the markup. To screw up the most basic use of HTML in only 24 lines of content markup illustrates beyond a shadow of a doubt the clowns who MADE bootstrap are unqualified to write a single damned line of HTML!

    Hence why they vomit up trash like this:

     <body class="d-flex h-100 text-center text-white bg-dark">
        
    <div class="cover-container d-flex w-100 h-100 p-3 mx-auto flex-column">
      <header class="mb-auto">
        <div>
          <h3 class="float-md-left mb-0">Cover</h3>
          <nav class="nav nav-masthead justify-content-center float-md-right">
            <a class="nav-link active" aria-current="page" href="#">Home</a>
            <a class="nav-link" href="#">Features</a>
            <a class="nav-link" href="#">Contact</a>
          </nav>
        </div>
      </header>
    
      <main class="px-3">
        <h1>Cover your page.</h1>
        <p class="lead">Cover is a one-page template for building simple and beautiful home pages. Download, edit the text, and add your own fullscreen background photo to make it your own.</p>
        <p class="lead">
          <a href="#" class="btn btn-lg btn-secondary font-weight-bold border-white bg-white">Learn more</a>
        </p>
      </main>
    
      <footer class="mt-auto text-white-50">
        <p>Cover template for <a href="https://getbootstrap.com/" class="text-white">Bootstrap</a>, by <a href="https://twitter.com/mdo" class="text-white">@mdo</a>.</p>
      </footer>
    </div>
    
    
        
      </body>
    Code (markup):
    To do the job of:

    
    <body>
    
    	<header>
    		<h1><a href="\">Cover</a></h1>
    		<nav id="mainMenu">
    			<ul>
    				<li><em>Home</em></li>
    				<li><a href="#">Features</a></li>
    				<li><a href="#">Contact</a></li>
    			</ul>
    		</nav>
    	</header>
    
    	<main class="coverPage">
    		<h2>Don't Do This!</h2>
    		<p>
    			Cover is a one-page template for building some dumbass time-wasting splash page devoid of actual content of value. It's the type of rubbish that was on all the "don't make sites like this" lists of a decade ago, that are back with a vengeance because every new generation has to learn the hard way!
    		</p>
    		<ul class="actions">
    			<li><a href="#">Learn more</a></li>
    		</ul>
    	</main>
    
    	<footer>
    		<hr>
    		Cover template for <a href="#">NotCrap</a>,
    		NOT by <a href="https://twitter.com/mdo">@mdo</a>.
    	</footer>
    		
    </body>
    Code (markup):
    Immediately fixing all of the accessibility woes caused by the garbage markup, and killing off the pointless idiotic code bloat caused by the tool they claim is somehow magically "Easier" when it clearly is not.

    Then there's the style. I won't get into the shit-show of how their CSS is applied to the markup, but their values alone are ignorant trash. They've got dynamic fonts -- 1rem on BODY -- mixed with media queries like max-width:1400px; REM is a dynamic font size, if the breakpoints are there for the content, and the content dynamically resizes based on the user's font preference, ALL of their media queries are broken for anyone who doesn't use 16px as the default font size. It's a giant middle finger to users with accessibility needs.

    If you're using EM/REM fonts like a good little doobie, this:

    
    @media (min-width: 576px) {
      .container, .container-sm {
        max-width: 540px;
      }
    }
    Code (markup):
    Is going to be broken crap for the ENTIRE FLIPPING AUDIENCE EM/REM ARE SUPPOSED TO BE USED FOR!!!

    Just as their default colour choices for things like the menu violates accessibility norms. Their bg-dark default is #343A40 whilst the non-current menu items are rgba(255,255,255,0.5). The render color for text is therefor #8D8F90... if we plug that into a contrast checker like the one at webaim:

    https://webaim.org/resources/contrastchecker/

    We discover it fails AA and AAA for normal text, AAA for "large text" (which this is not "large text"). Even more of a laugh, that little dark underscore they use? Fails UI element minimums.

    Out of the box they have utterly unacceptable values because the people working on it also are unqualified to do front-end design!

    Hence why if you used a "framework" -- be it HTML, CSS, or JS -- to build your front-end? You are almost GUARANTEED to be in violation of accessibility minimums. Because the people who create and use frameworks are unqualified to write a single damned line of code, much less build a website. Do not pass go, do not collect your Covid "stimulus payment", go straight to jail.

    And these are the types of things you have to look for when you're doing an accessibility analysis. If you are willing to send me a link to your site, I can provide you an initial overview of what needs to be fixed. I do these for prospective clients no-charge two or three times a week; it's not even fifteen minutes work. One more won't break my back.
     
    deathshadow, Aug 30, 2020 IP
    JEET likes this.
  5. JEET

    JEET Notable Member

    Messages:
    3,825
    Likes Received:
    502
    Best Answers:
    19
    Trophy Points:
    265
    #5
    @deathshadow
    I don't know the website of original thread starter.
    I only listed out basic things which my screen reader friends find really buggy.

    One thing I forgot is this,
    Having a dropbox, and redirecting user automatically to another page when dropbox selection changes.
    No "submit" button, just selection changes and user is redirected to a new page based on selection.
    Here's an example:
    https://azure.microsoft.com/en-us/pricing/details/cognitive-services/spellcheck-api/
    The dropdown box which is listing product names, "Bing search" | "spell check" etc
    Change the selection, and it takes you to next page.

    In that list there are very few items, so its manageable by person on screen reader.
    Sometimes people put 10 or more items in those kind of dropboxes.
    Now, before the screen reader can read the selection, page changes...

    Its not an accessibility problem completely, more like an irritating navigation choice.
    If you add many items in it, its definitely an accessibility problem then.
    Person on screen reader never reaches the lower options, page keeps changing on every down arrow keypress.

    DeathShadow,
    Some of the things you mentioned, I do not agree to them as being accessibility probem.
    Like,
    Menu Anchors without surrounding <li> <ul> tags.
    That is not an issue for screen readers.
    Plus, in your example, you wrapped them inside <nav> </nav> tags.
    This will be read as "navigation region" by screen readers. So it clearly tells a blind person that those are navigation links, which is not really an important notification to begin with...

    This is perfectly 100% accessible (from your example):
    (here screen reader reads, "navigation region")
    <nav class="nav nav-masthead justify-content-center float-md-right">
    <a class="nav-link active" aria-current="page" href="#">Home</a>
    <a class="nav-link" href="#">Features</a>
    <a class="nav-link" href="#">Contact</a>
    </nav>
    (Here screen reader reads, "navigation region ends")
    And in between it reads "link home", "link features" etc etc

    Colors etc problems you mentioned for this same section, I agree with those.
    People with sight can perfectly see the difference between "255.255.255" and "245.245.245" RGB colors.
    But a HUGE lot of people will find it really impossible to read...

    Likewise, <h3> or <h4> etc before a <h1> is not an accessibility problem at all.
    Its against good layout rules of documents, but it certainly is not accessibility problem.

    Perfectly accessible documents,
    symantically perfect documents,
    these are 2 different things...


    I agree with you 100% on this point, "javascript for nothing".
    Somehow they are making 2 links appear inside one using javascript.
    This is becoming the biggest problem these days.
    Here's an example:
    1. Login to CPanel
    2. Go to Cron settings
    3. Add a cron job here
    Now, this new cron job is listed on that page in a table.
    4. Using a screen reader, try to delete it...
    Click the "Edit/Delete" link using screen reader...
    You can EDIT it via screen reader, you cannot delete it via screen reader.

    Somehow they are tracking which word is clicked, Edit or Delete, and then loading options based on that.
    Always loads EDIT options when clicked by screen reader.
    What was the problem with 2 separate links, one for Edit, another for delete...
    CPanel is really becoming more and more inaccessible with every version update.
    Similar are cases with add on domain pages, add new email pages of CPanel.

    VestaCP is even worse.
     
    JEET, Aug 30, 2020 IP
  6. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #6
    Exactly what I mean by using JavaScript for navigation. The solution there being the dropdown should be a list of ANCHORS, or provide scripting off markup, then for scripting on turn that markup INTO the scripting driven form elements.

    It's a wonderful example of a mix between JS for nothing, and/or JS breaking simple navigation for those who aren't sighted.

    It is indeed, or at least for the version of Jaws I have and my braille reader. It's also about proper semantics.

    Remember, anchor is semantically neutral, It applies no grammatical meaning to the text it wraps. Just as HTML is about more than screen, it's also about more than certain outdated versions of screen readers, certain newer versions of screen readers, etc, etc, etc. It exists for all of it so it helps to bloody well pay attention to WHY the tags exist.

    ... and I quote:

    https://www.w3.org/TR/html52/sections.html#elementdef-nav

    It does not exist to replace the existing semantics of saying that it's a list of choices. Without those LI both Jaws and my braille reader here parse that as if it were a run-on sentence and/or inline-level links, NOT separate choices. Or at least, when navigating with the keyboard and/or braille reader keys.

    Slopping anchors into NAV is ignorant of what NAV is for, what it does, etc, etc, etc... and would probably be a WCAG violation if the WCAG wasn't made before HTML 5 was a thing; and likely will be a violation in "Silver" or whatever the *** they're calling WCAG's replacement this week.

    NAV exists to expand the UL's meaning, and make a nice extra container for doing things like modal/hamburger menus. It is not a replacement for those semantics. Hence yes, I'd have included NAV, but I'd also include the UL just like the specification flipping says to!

    It can run even deeper than that. It's possible to make radically different colors that are effectively indistinguishable from each-other for the vast majority of people. For example #00B300 and #FF00FF work out to the same luma under YCbCr, whcih is what SHOULD be used for accessible contrasts. (The W3C actually screwed up on that using the HSL luma instead, which is skewed for CMY not RGB, hence over-valuing red and under-valuing blue.. I only recently noticed this snafu!). Worse whilst if you have the magenta over the darker green, most people can read it, but reverse it and it becomes an illegible mess... but for the colourblind they're effectively the same thing.

    It's invalid navigation. Do you not use the navigation menu alternative? It's utterly banjaxed and makes my braille reader just give up on the page entirely... since it can't find the H3 that H4 should be a subsection of, or the H2 the H3 should be a subsection of, much less the H1 that ties ALL pages together.

    Again, we talked about this via PM, but I don't know what jacked up garbage screen reader you're using, but that's not how it works. I've been doing this for a decade. That's not how ANY of this works... and if it does it for YOUR screen reader, well lah-dee-huffing-dah. It's not about what YOU have. It's not about what I have. It's about following the rules for what EVERYBODY has.

    Much like wearing a mask. It's not about you. It's not about me, it's about everyone else. Hence "It's broken for somebody" is ALWAYS more important than "It works for me".

    And it's not just about what works, it's about meeting the guidelines, PARTICULARLY in court. Hence you're wah wah claim in our previous discussion where you said "I'll show in court it works" means JACK *** if it didn't work for someone and/or fails to meet the legal guidelines. Hence:

    https://www.w3.org/WAI/WCAG21/Techniques/general/G141.html

    Though it's comical in one of their other "informative" sections, they violate their own rules, and have an example that doesn't even make sense. Again, if one were navigating via headings, it would be broken gibberish because the cascade is out of order. But that's to be expected when you have design by committee with over-compartmentalization.

    I've seen people make up the lame excuses about it claiming "oh it's fine" before. Yup, seen them raked over the coals by prosecutors and/or civil attorneys who'll have none of that, and judges who oft find that attitude contemptuous. Hence why I'm such a stickler for it!

    Meeting WCAG minimums is about more than "but it works in my six year old copy of Jaws".

    Hah, good one. Given that everything else in that steaming dung heap is incompetent trash from an accessibility standpoint... (one of the MANY reasons I stopped using CPanel driven hosting over 12 years ago). Their entire UI was build on the bleeding edge of 1997 practices, and they've done little to fix that underlying flaw in the time since.

    Their front end developers have a bad mix of 1990's markup methodologies and "JS is the solution to every problem". Hence the broken interface. Rather than fix their 20+ year old markup, they just keep slathering more and more scripttardery on top... hence yes. It's aging like broken eggs in the sun.
     
    deathshadow, Aug 30, 2020 IP
    JEET likes this.
  7. JEET

    JEET Notable Member

    Messages:
    3,825
    Likes Received:
    502
    Best Answers:
    19
    Trophy Points:
    265
    #7
    @deathshadow
    I used to teach JAWS in a non-profit-org
    Did this for over a decade, and have just recently left that org.
    This is the reason why I know all this stuff, how it works, what screen readers can actually do.

    You said:
    that as if it were a run-on sentence and/or inline-level links, NOT separate choices.

    You know why this is happening?
    Either your forms mode is turned on, and you are using tab to jump from link to link,
    or your install of JAWS is not proper.

    This was happening to my students on a version of opera which was not supported by JAWS.
    Links next to each other got read as a sentence, instead of separate choices.

    I am thinking that you are using a "portable" version of screen reader, not a fully installed one.
    This also happens on portable version of NVDA.
    Use a proper installed version of JAWS, not a portable one. Not that test 1 hour version also.
    Use a fully functional one.
    These accessibility problems that you come across, they are not really there...


    To rectify that dropdown auto navigation, the simple solution is to have a button, and use the JS function in the "onclick of button ", instead of "onchange of dropdown".
    This solves it without too much hassell.
     
    JEET, Aug 30, 2020 IP
    sarahk likes this.
  8. anotordowe

    anotordowe Peon

    Messages:
    4
    Likes Received:
    2
    Best Answers:
    0
    Trophy Points:
    3
    #8
    Wow, @JEET, @deathshadow, thank you for such an extensive discussion on the issue. So much info to take in now.
     
    anotordowe, Aug 31, 2020 IP
    deathshadow and JEET like this.
  9. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #9
    Except it's still scripting based, and therein a violation since it's still a scripting ONLY solution. Well, unless it's an actual form in which case scripting off, you'd have a normal submit. In which case yeah, that's the way you do it. You play the guitar on the MTV...
     
    deathshadow, Aug 31, 2020 IP
    JEET likes this.