headonfire

You can do it, actually.
This code:
<?php do_action('cyberchimps_footer'); ?>
runs a function called cyberchimps_footer. You need to find this function in your theme’s php files, it is defined somewhere. Probably, in functions.php file, but it also can be in any other specific file, created by CyberChimps.

If you are a bit familiar with any code editor like Notepad++ or Sublime Text try searching within theme’s directory for cyberchimps_footer. When you find it, you can see what they do with this function and remove or comment everything you don’t need.

There is a little chance that they output their logo with another function called in the footer – cyberchimps_after_wrapper or cyberchimps_after_footer_container. Then you will have to perform a search for this function names.

Anyway, it’s a 5 minute job, including downloading and installing Notepad++ if you don’t have one ??

Let me know if it helped.

Ok, got your point.
By the way, mailto: links are handled differently by browsers and target attribute is completely ignored. So, there’s no way to open it in new tab. I thought I had a bug with Gmail only, but with some more testing I found out it’s just not possible. Mailto links to webmail services will always open in current tab, enternal mail programs will launch in their own separate windows.
And Gmail still produces this bug with history. If is filed as a bug in both Firefox and Chrome support threads but still not fixed.

The problem here is that you will be stranding a specific group of users who will no longer be able to return to the site.

Actually, I don’t see where I have this group of people in my scenario. They will close a tab/window with webmail and return to my website’s tab automagically – most browsers with default settings after closing a tab return user to previously active tab. I explained you a Gmail scenario without target=”_blank”. In this case we really get this group of users who will no longer be able to return to the site, because we already navigated 2 steps from the site.
I’ve chosen a ‘logical’ approach to follow. The link looks like a button on purpose (and of course it’s pure CSS, no images). Buttons are meant to behave differently, not like inline links. Buttons perform actions, not just leading to another page. They open external application, spawn modal windows and layers, open new tabs and windows. These behavior is logical. And this behavior must be consistent. If it opens external mail app when it’s assigned by the user in browser prefs, it should open webmail in the same fashion – in new window. Same if you use contact forms. In this case a ‘Contact us’ button should open a pop-up div with a form, not going to ‘Contact us’ page with this form attached somewhere on the page.

You are right about alt attribute for links. My bad. Just checked W3C specs, and everything seems logical. Alt for images, in my case I will use title attribute. W3C states:

This attribute offers advisory information about the element for which it is set.

which is what I need. And it displays as a tooltip, which is great. This way, a user hovering the button will see the text ‘Send me an email’. It’s even ok to extend the message, saying ‘Click here to send me an email in new window or your default mail app’. It’s a perfect solution for visual browsers. But what about touch devices? Keyboard only? Screen readers can implement this differently. Other devices too. No standard again. As you said, it’s unwise to rely on them.

And regarding spam level. Sounds fair, that If a browser can parse it, you can virtually guarantee that most spam bots will be able to parse it as well, but as I wrote above, we did a test. 2 new emails on the same website. One was obfuscated using same technique, the other one plain. After 6 months those emails had different amount of spam received, and the difference was huge. That means, even if harvesters can do this in theory, in practice seems like they are not doing. In russian/ukrainian language there is a proverb: “If you are afraid of wolves – never go to the forest”. Same story here ?? Obfuscation obviously protects, not 100% but significantly. Paired with a quality email service like Gmail with their solid SPAM filtering you can sleep well and don’t worry about being spammed.

There’s no way to live completely without spam. As I also wrote, even if you don’t advertise your domain-based emails it’s pretty easy to guess them. Choose 10 random domains, send emails to [email protected] and 9 of 10 letters will be delivered. If you shared your email with anyone (subscribed to any newsletter or registered on any website) there’s always a chance their database will be hacked and stolen. Then your email will be definitely in all SPAM databases and marked ‘reliable’.

Eek! target=”_blank”?

Yeah, this is something I’m trying to figure out for a long time. First of all, a button saying ‘Send me an email’ is logically a “new window action” as it will open a mail client. For external apps _blank will be ignored. For those who set Gmail (or other webmail) to handle mailto: links in the browser without _blank it will be loaded in same tab/window replacing the site, which is not a logical and expected behaviour. With Gmail it looks really bad. Clicking mailto: link opens in current window/tab a blank page with Gmail’s ‘compose’ overlay div and after sending the message this overlay is automatically closed leaving you in front of a blank page. Awkward. But wait, that’s not all! When you hit browser’s back button you see a ‘compose’ overlay again instead of going back to the site. What most users will do in this case? Close the tab/window. This is not a user-friendly behavior. I think that ‘Contact me’ link is not an internal/external LINK to be followed, it’s an external ACTION, which by default will be handled in separate window (external application or webmail in external window) or it can handle an overlay with contact form..

the alt must replicate the text rendered in the graphic

It makes no sense for me, really. Looks like just stupid following some strict rule, not thinking about the end user but about getting ‘WCAG Passed’ badge. First of all, the button is not a graphic, it’s a PLAIN TEXT link ‘Contact me’, it is a text and it is accessible. The alt attribute, as I understand, gives alternative readers some extra information – explanation, instruction etc. Replicating ‘Contact me’ text in alt attribute makes no sense because it doesn’t help and it’s actually redundant, because the link text is accessible itself. Alt text here is kinda optional instruction for alternative reader. What am I missing?

have you tried putting your theme through the theme accessibility audit yourself?

Not yet, until now I developed themes only for personal projects and clients. Right now working on my first theme to be released in public and will definitely try this out. Thanks!

I was researching on optimizing website performance and load speed and found an interesting hint. While this is not related to the WSOD bug, it may be useful for njs7227 and everyone else using CDN.

First, if you map your CDN service or S3 bucket to your subdomain you will have redirects.

Second, browsers will prefetch DNS only for your subdomain, not the actual location of a file. You will have non-prefetched DNS lookups, it can significantly decrease load speed, especially if you have many files linked to CDN.

The solution:
Let’s say you have files.domain.com.s3.amazonaws.com mapped to files.domain.com. In your HTML add this tag to your HEAD section right after the charset definition:
<link rel="dns-prefetch" href="//files.domain.com.s3.amazonaws.com">
This will tell browser to prefetch DNS lookup of this domain address, and when the actual request and redirect is made, the DNS lookup part will be skipped (it’s already prefetched) making it respond faster.
Tested, it really helps.

I’m not sure yet how Amazon serves this subdomain internally, right now testing if adding one more prefetch link for s3.amazonaws.com will make it even faster.

https://creativemarket.com/badelt/7896-Righter-A-Simple-WordPress-Theme/live-preview

Here’s a demo of a Righter WordPress theme. I’m creating a Pro version of the theme with extra functionality and fixing some general issues for this version. Accessibility is on the list.

Check the ‘Contact me’ button, bottom left. In the original theme it’s not obfuscated, has no alt and title attributes etc.

Original code (from the link above):
<a target="blank" href="mailto:[email protected]?subject=Hello" class="email">Contact me</a>

My edited version:
<a href="mailto:someon%65@gmail%2E%63om?subject=Hello" target="_blank" alt="Click here to send me an email" class="email">Contact me</a>

It has alt attribute, it’s a text link accessible by it’s nature, the design (it looks like a button) is pure CSS. It functions well – opens a mail client’s (or webmail’s) ‘Compose new message’ screen and puts there recipient’s email address and message subject. As I understand it’s 100% accessible and operable. The email address itself isn’t readable and it shouldn’t actually. It’s still accessible. Am I right?

By the way, checked WCAG 2.0. Seems like I’m following these guidelines intuitively, I learned this in the process, not by reading the guidelines. Most of this is just a common sense and good practices.

Sorry but that’s not an accessibility issue as it does not impact disabled people specifically

It impacts millions of people, including disabled. It’s off-topic and completely different discussion but had to mention it when talking about critical WordPress core features.

It’s about trying to ensure that you do not create barriers
…
All that they do ask is that you do not make their lives more difficult if this can be avoided.

Got it. Completely agree.

A question. Ok, I have obfuscated email and some user agents can’t understand the email address characters. Looks like a problem. But the tag has alt attribute saying ‘Press this link to send me an email”. I suppose this user agent can perform this basic action (following a mailto: link and sending email using a webmail or any mail client). Using contact form is actually the same – a visitor can send an email but he can’t see the actual email address. So, every user, including disabled CAN use this feature. Looks like we don’t have any problem here. Am I missing something?

It’s part of WordPress core.

Oh.. ?? WordPress core lacks some really important features. The most important part of these features is setting up and managing multilingual websites. Especially when you use one language with latin subset and another one with cyrillic. More that 36% of WordPress downloads are in other languages than english. Millions of websites are build on WordPress in 2 and more languages. And core support for this is really poor. WordPress team says it’s a plugin area. With more that 1/3 of downloads? Come on. All the plugins over there have lots of weak points and limitations, they have different architecture and switching between them is impossible or very hard. And relying on a single plugin is stupid – if it stops updating or updates are late you can’t use your site or forced to stay with an outdated version of WordPress. Developing and managing multilingual websites with WordPress is a nightmare. Believe me, it’s my day-to-day job and I know it.

To avoid discrimination for a start

Good point. I’m doing the most part of the job to make sites accessible as much as I can. But not always 100% usable and comfortable for ALL kinds of disabled people. Need to learn these in details.

Then I’m sorry but your hypothetical client is a fool.

1. They are not hypothetical, that’s real situation with real clients. I hear it from 9 clients out of 10. Even when I start talking about features for disabled people they look at me like I’m an idiot.
2. They pay for the development, they can insist or choose another company to work with. I prefer to have them stay – it’s business.

In the UK

This is the main point. You live in UK and it’s NORMAL for you. But hey, there’s the rest of the world. I live in Ukraine. It’s a poor country. We have no sound warnings for the green lights on the road crossings, no braille on product price tags or packages etc. Disabled people in our country ARE POOR. The government does not care about them. Often even families don’t care much, unfortunately. This is sad. But this is reality in many countries, including all ex-USSR (and Russia to, believe me).

Are there clients out there who do not want a slice of that market?

These market in Ukraine is much, much, much smaller. I would rather say it’s a micro-market. By the way, despite Ukraine is a large country and plastic cards are VERY common and popular (everyone have them) all over the country people still don’t pay by card on the internet. Even on largest online stores the main (over 95% of orders) payment method is ‘Cash on delivery’. This is just an example. Always remember that there is a lot of other countries outside UK and US and in many of them everything is COMPLETELY different. I saw many foreign companies coming to ukrainian or russian market and failing just because they were trying to work the way they work in their country. Always consider mentality and specifics of the country/people you are going to work with.

Who said he had to? Accessible design is not a premium add-on. It should always be part of all design projects. It’s part of WordPress core.

You need to spend some extra time to double-check everything and even test (the perfect scenario). This takes time. Time means money. When the client says “let’s see if we can cut off some costs” you start optimizing every step of yours. No responsiveness, no optimization for slower connections over mobile etc.

Isn’t dropping support for IE6-7 a discrimination? From my point of view, making a website 100% accessible is the same as making it work in IE6-8. If it’s broken and visitors can’t use it properly – it’s bad. If it’s working and users can use the most important features, even if they don’t get all the pretty stuff and extra functionality – it’s ok. Making everything 100% accessible and functional in all possible scenarios for every possible user is utopia.

ah – but does that mean that your site was not accessible to them? You cannot rely on stats for this.

For a large news site we did a deep research, surveys, analytics and polls. It appears in my country blind people almost don’t use internet directly, they ask for help of their friends or family if they need something. In US and other top countries it’s ok for disabled people to have a normal life. Unfortunately, in my country it’s not the same. We have not solved yet problems with elevators for disabled people at shopping malls and street crossings and you are talking about internet.

And? Are you suggesting that people with a visual impairment should not be allowed the same ease of access as everyone else?

Okay, I can make it accessible, but for what reason? A photographer’s portfolio is showcasing photographs. Blind people can read what is the photo about and what is pictured on it but they can’t see it anyway. I can do this extra work as a developer, but a client is not going to pay for that. He thinks blind person will not become a client. You can argue about the accessibility, the rights of disabled people etc but you can’t blame a client of thinking about HIS business. A website is a converting platform and he will pay for anything that will make him new clients. But he is not going to pay for the features for blind people. And in this case the client IS right. So, when I give him a detailed cost estimate, he will review it and remove any parts of the work which are not needed for him.

So what? That does not make them right. And do ensure that you are differentiating between alt texts for decorative images and alts for informational images.

Of course, just gave you an example of a current state. And yes, I do differentiate alts and titles, alts for important stuff and decorations.

And, for example, what about taking care of blind users for portfolio website? I think it just makes no sense. The core part of the site content is visual, it’s impossible to show photography or graphic design portfolio with words.

It may be a problem, but again – not in my country. I have access to visitor stats for more than 150 websites, some of them are number 1-3 in my country in their niche (large news sites). We did a small research once, looking for any non-standard content readers. We were able to identify few screen reader visitors (few among millions) but no braille or of other type. Seems like in my country, unfortunately, blind people don’t use internet or special tools. But I have some websites in english as well, they are oriented on worldwide auditory, will do a research on this topic and look for some solutions. Thanks for pointing me out.

BTW, checked some top local websites for proper use of alt attributes. No one is using them properly… I usually spend a lot of time writing proper alts and translating them. I develop all themes originally in english and then translate them to russian or ukrainian with POEdit, even for commercial projects for local markets. This way if they decide to add another language to their site they are ready to go right out of the box.

esmi, thanks for pointing it out, didn’t knew that. Anyway, in my country (Ukraine) there’s no such laws, so I’m safe. And I use descriptive alt attributes for screen readers. I suppose it will read ‘Send an email to blog author’ instead of reading the email address itself. Am I right?

luigidelgado, in your case I really don’t know and can’t even reproduce your environment. My recent idea was in completely different direction, it’s not your case. Already tested it, didn’t worked (

Regarding how I fixed this WSOD for my website – I actually managed to make it work fine with CDN. Disabled it just because it’s too slow for my region (local ukrainian and russian traffic). CDN wasn’t causing that WSODs. Turn off all caches one by one. Than turn them back on one by one, but, as soon as you check the “Page Cache” checkbox, BEFORE saving settings scroll down to DEBUG section and uncheck everything (the first checkbox is being turned on by default, as I noticed). Then save settings and countinue turning on all other caching methods you use. After that clear and rebuil all caches. It worked in my case, tried this several times. Restored DEBUG, got those WSODs again, repeated described steps – and everything is working again.