I am trying to scan the body of an email for a confirmation link. I am not sure how to find the right link though.
All interesting e-mails have their link inside the href attribute of an a element, the link sometimes contains one or more of some keywords like "register", "validate", "click", "uid"... and some form of ID. Sadly all don't have those keywords and the IDs also have many different ways they can look.
Do you have any ideas how you can find the right link, maybe something I missed?
While there is no standard for how confirmation links in emails are formatted and it's almost impossible to detect all of them with 100% accuracy, but you can still cover a whole lot.
I think you're moving in the right direction. You can also look for words, if any, inside the anchor tags like; 'Confirm you email,' 'Click here to confirm.' Also the words before and after the anchor tags themselves. Don't just analyse the hrefs apart from their context.
You can go a bit further and open the links that don't fit these criteria then look for certain helping keywords. It's a bit risky, though, as some confirmation links expire after they're opened. So keep that in mind.
A bit advanced approach (and a bit out there TBH) you can apply, if none of the links in an email are identified as confirmation links, could be taking a screenshot from the email itself and someone selects where the confirmation link is then do some analysis on the position of the click then select the corresponding element and get your link. I'm not kidding! you can do it using Puppeteer in a relatively easy way!
Of course you can always use machine learning but you don't wanna go there.
And that's it, I think.
Related
I'm mainly interested in the a11y aspects
So as you might be aware, sometimes you might wish to have a button that acts as an anchor.
These are 4 ways (I can think of) of approaching this issue:
1. Button inside an anchor element
<button>Button</button>
2. Anchor inside button element
<button>Button</button>
<!-- Also should it be a href or button onclick (?) -->
3. Anchor styled as a button (without a button element)
<a class="buttonLike" href="//redirection">Button</a>
4. Button acting as a redirection (without an anchor element):
const button = document.getElementById('button')
button.addEventListener('click', () => {
window.location.href = "//redirection"
})
<button id="button">Button</button>
I've tried to find an answer to this myself. Closest I could find was this excerpt:
According to the MDN anchor spec, which states the following:
Anchor elements are often abused as fake buttons by setting their href to # or javascript:void(0) to prevent the page from refreshing, then listening for their click events .
These bogus href values cause unexpected behavior when copying/dragging links, opening links in a new tab/window, bookmarking, or when JavaScript is loading, errors, or is disabled. They also convey incorrect semantics to assistive technologies, like screen readers.
Use a <button> instead. In general, you should only use a hyperlink for navigation to a real URL.
Unfortunately this doesn't help me too much. Basically all it states is you should not use the third approach (anchor styled as a button) if you don't mean to provide a real link to it, which is not what this question is about.
Is there any official WCAG on this subject matter that I was unable to find or?
Option 1 is not valid HTML.
Option 2 is not valid HTML.
Option 3 is the correct choice here.
Option 4 is semantically incorrect.
Semantics are one of if not the most important aspects of accessibility.
There are two things at play which dictate option 3.
The first is that an anchor should be used only to jump to sections and to navigate between pages.
The second is that a button should perform actions on the same page.
Now if you want to style a call to action link to look like a button that is fine but make sure you use the correct semantics, but make sure that CTA leads to a new page or it isn't semantically correct.
And although it is swearing on StackOverflow to mention SEO, a hyperlink rather than a JavaScript redirection will be far better.
The first and second rules of ARIA say:
1st rule : If you can use a native HTML element [...] then do so
2nd rule : Do not change native semantics, unless you really have to.
Interactive elements like a and button can't contain other interactive elements:
The a element may be wrapped around entire paragraphs, lists, tables, and so forth, even entire sections, so long as there is no interactive content within (e.g. buttons or other links).
So, as what you want to do is linking to a page, your third solution is obviously the only one correct.
I think you might have confused the "bogus" stagement which refers to your 4th example.
From my little experience with Accessibility and semantics there is no "one size fits all". It really depends on your priorities and the user experience you are aiming for.
A <button> gets all the accessibility goodies from the browser automatically: Being selected or pressed using the tab or spacebar/enter keys.
A <a> element is a link, links are meant to be used as links or anchors within a page.
Anchors are not as important in comparison to a button within a page. From a user experience point of view; a button is used by people to interact with a UI, either to confirm or make the UI do something. Pressing a button provides a different feedback compared to a link. Anchor links on the other hand help a user with finding content within a page.
Again, it really depends on what you are trying to do:
Is this a terms page or an article? Then list your anchor links without any button-like styling
Does this a link that has to look as a button so users find it easier to spot or interact? Then style it as a button without it being actually a <button>.
I'm working on a chat web application. I want to make sure it is accessible for everyone. Currently, when I tab to the chat content, the focus goes to the first message in the chat - which is at the top of the screen. To access the most recent messages, the user must tab through all the messages. Is there a way to override this behavior so tabbing starts at the bottom of the screen? I can't modify the order of elements in the DOM because that will display the messages out of order and confuse users who don't use a screenreader. Besides, the user would still need to tab through all of the messages to access the input to send a message. How can I make sure tabbing doesn't scroll to the top of the screen?
Bad answer
You could use positive tabindex values, but it's a bad practice.
Many explanations exist about why it's bad. Don't use tabindex.
Simple answer
People who frequently use tab to navigate usually also know that they can move backwards with shift+tab.
So you are safe if you do nothing special, and just assume they will be smart enough to navigate backwards in order to quickly reach last messages.
Better answer
Ask yourself this question: do each messages really has to be individually focusable ?
Probably the answer is no, or at least not so directly with tab alone.
For your particular case, I suggest you to make a list box instead of a flat serie of messages.
Ideally you should probably have this kind of behavior:
Pressing tab goes into the list, pressing tab again goes to the next element outside of it.
Since a single tab is sufficient to skip all messages, the input field to say something can be reached with only two or three tabs
If I want to read the messages one by one, I go to the list, and then can use arrow keys and home/end to navigate between messages in the list. Pay attention to home/end, they are often forgotten, and arrows aren't sufficient in very talky rooms.
When going outside of the list and then back in, the same message should be again focused as when leaving the list
In fact, something often forgotten is that keyboard navigation isn't just about tab. There are as well arrow keys, home/end, spacebar and enter, etc.
There are well written advices on what should do what in which situation on the Internet. Search for example "WAI authoring practice".
IN general, the most useful and most frequent used elements must be quickly reachable.
Keep in mind that if you must press many keys to reach something, you have probably failed in making a well designed interface.
you can use the tabindex attribute :
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/tabindex
You can set the tabindex number attribute on specific elements. The incremental order of the tabindex will be the selecting order.
Read more here.
So I have this page which has 3-4 anchors and whenever I click the button to jump to the section I want, the url should remain the same (without adding #anchor).
I googled this but I couldn't find anything that works and I'm still learning JS so I don't have the knowledge to do this.
Not sure what you mean, Perhaps you can edit your question to show us what you have already tried. Anchors are how the browser knows where to scroll to, if you want to achieve the same thing but without changing the anchor in the address bar you can try something like this on click:
elmnt.scrollIntoView();
See also: https://www.w3schools.com/jsref/met_element_scrollintoview.asp
I run a large Discord server and I'm making a channel for people to post template information about their online groups. To make complying with the template either, I've created a single HTML page which takes the information that goes in the template and regurgitates it into a box on the bottom of the page with some nice bolding and italics where needed already for copy/paste.
Unfortunately, I don't know Javascript so I'm just trying to piece things together and learning as I go. (I'm learning other languages but not this one in school.)
For some reason me trying to format code on here isn't working so I can't paste what I have so I'll just try and explain it.
I'm using oninput="groupNameFunction()" and I'm having the javascript grab the user entered data as they type it via grabbing the ID of the input field then regurgitating it out in the innerHTML of another element. And it works great.
But checkboxes (and probably radio buttons) don't work with oninput (for pretty obvious reasons) but I've been able to get onblur to work to some extent.
The problem is that I'm a beginning coder and I don't quite know or understand how I'll take all the results from all the checkboxes and regurgitate them out into a nice list when there are many IDs and many choices and it doesn't seem sensible to try and write all choices from a single thing into their own function, or how I'll handle the same thing with radio buttons.
I can't find any examples in stuff like W3 tutorials of this being done, it's probably that I just don't know the language to google it correctly.
Could someone point me in the right direction on how to make this work?
here's a little fiddle for you to play with. (press F12 to open developer tools and see console, you'll find logs there)
for radio and checkbox inputs you have change event, it triggers when user check and uncheck the box. bare in mind that you need to have same name="friendly-name" attribute on radio buttons in order them to work as expected.
for the "text" filed use input event.
don't add inline events in HTML, it's bad practice, add them via JS. from JS you can select all your inputs by ther class, name, tag name etc.. and add event handlers (you can find everything in the fiddle).
hope it helps. :D
I am looking for the overlay that comes down from the top of the screen and lets people either go to the survey or select “no thanks.” What kind of flexibility do we have with this functionality? Can we put any content we like in that space (i.e., text and images)?
Technically you can put anything in there.
Conceptually it is a bit different for me:
You see this mostly used to softly point a user to something, with as less disturbance as possible. As such it is clear that the more content you put in it, the more you defy it's purpose.
So in short:
if you want to show the user something that he might like or that you want him to do but that is not really needed, without disturbing the normal flow of the user, use such an overlay.
If there is something that the user really has to know about / has to do, then you should consider other options (for example a modal dialog).
In every case you should consider the importance of the message versus the impact on usability.