I insert the below paragraph into the database .However while displaying it is displayed as (which is not desired one):
The use of this website is subject to the following terms of use: • The content of the pages of this website is for your general information and use only. It is subject to change without notice. • Neither we nor any third parties provide any warranty or guarantee as to the accuracy,
Desired paragraph view:
The use of this website is subject to the following terms of use:
• The content of the pages of this website is for your general information and use only. It is subject to change without notice.
• Neither we nor any third parties provide any warranty or guarantee as to the accuracy.
How can we achieve this in asp.net/C#
Insert the complete html into database and set into div as innerhtml
<div id="div" runat="server"></div>
div.InnerHtml = "paragraph from Database which saved as HTML";"
Use the paragraph tag.
<p>The use of this website is subject to the following terms of use:</p>
<p>• The content of the pages of this website is for your general information and use only. It is subject to change without notice. • Neither we nor any third parties provide any warranty or guarantee as to the accuracy.</p>
You may need to substitute your line feed/carriage return symbols with br tags before you put the text in the control. Or, possibly put the br tag into your paragraph text when its stored in the database.
To substitute, you can use String.Replace()
The character codes can be found here http://www.asciitable.com/
Look for character codes 10 and 13. You should check the text you're attempting to substitute, to find out if both codes are in the string, or just one of them.
Related
We have a project at my work at the moment around ensuring we meet accessibility standards on our website.
Our emails are built using Salesforce Marketing Cloud layouts. Does anyone know how we can see or test how 'accessible' they are?
I can test using ReturnPath to see how they render on various devices and that gives me results for colour blindness, but I'm not sure how to test how well they would or wouldn't work with a screen reader for example
Emails are a tough one from an accessibility perspective. We are still stuck using tables for layout even in 2021!
We can't use WAI-ARIA and CSS is very limited.
As such I have a smaller checklist for emails that covers the important stuff we can control.
The main things I would look at are:
Reading order
Make sure that the email reads left to right and then downwards (assuming the language is a left to right language, otherwise reverse it)
Use headings
Email marketers often just style normal text instead of putting proper headings in. Make sure headings are in fact <h2> to <h6> with a single <h1> explaining the purpose of the email at the start.
Also make sure that the headings do not skip levels (so don't go from <h2> to <h4> for example).
Colour contrast
The exact same rules for websites apply to emails. I would recommend running the colours through the Web Aim colour contrast checker for your text and background around the text, button backgrounds and text etc.
Alt Attributes
Alt attributes on images is the big one you need to check for especially in emails where images might be the only content within a hyperlink. As you can't use aria-label or visually hidden text in an email alt attributes are the only way you can make a link have meaning if it contains an image (plus as email clients block images it means there is meaningful text for everyone else not just screen reader users).
Meaningful Link Text
Along the same lines make sure links do not just say "Read more". Instead make link text meaningful e.g. "Read our article on X Y Z".
Use a descriptive subject line
This one is the only one that is "difficult" as a marketer. You want subject lines to intrigue people to open the email, however for people with cognitive impairments cryptic subject lines can be disturbing / confusing etc.
Getting the balance between "giving the game away" and meaningful subject lines is difficult, if unsure err towards meaningful (it may help your open rate / conversion rate anyway so A / B test it!)
View in Browser
Due to the limitations of email clients the best way to ensure accessibility is to have a custom "view in browser" link in the email (as salesforce etc. are very unlikely to do a good job of the browser versions of their emails).
That way you can use WAI-ARIA, visually hidden text etc. and mark the page up properly, complying with WCAG 2.1 (and very soon WCAG 2.2) requirements.
Obviously I am aware of the amount of work this entails but once you have a template and components built that are accessible it does become much easier.
Testing
Personally I would just test manually, but I am sure somewhere out there an email testing service exists similar to Axe Accessibility Checker.
But given the length of a typical email I would say a manual check will only take 2 minutes once you know what to look for so a service may not be worth it.
You could always copy and paste the email HTML into a file and save it with a .html extension and then open and test it in a browser / accessibility checker. But you might get a load of issues you can't resolve due to the use of tables for layout.
Finally - learning to use a screen reader takes less than an hour, grab NVDA or VoiceOver and test the email yourself, if you can understand it and access all the same information as everyone else then send it!
There's probably a historical reason for this, but I don't know where to start looking for where this might be documented.
Specifically, instead of the cryptic "anchor tag" with a "hypertext reference" (well, I suppose terminology was different back then):
StackOverflow
why didn't something like this happen?
<link to="https://stackoverflow.com">StackOverflow</link>
What exactly did "anchor" mean anyway?
According to the W3 docs:
A link has two ends -- called anchors -- and a direction. The link starts at the "source" anchor and points to the "destination" anchor, which may be any Web resource (e.g., an image, a video clip, a sound bite, a program, an HTML document, an element within an HTML document, etc.).
I'm not an expert in the field, but I believe that it is merely because of the terminology at the time. Reading that article can provide more details about the definitions, but you may need to message the original authors or historians to provide a creditable answer.
A was short for anchor, which could be a url or a named anchor (created with <a name="myanchor">text</a>). The text in my example would not be visually different, and another A tag could set its href to #myanchor. When clicked, the browser would scroll the named A tag to the top of the page, or at least ensure it was visible.
Link wasn't added until later, and it means something else semantically.
See http://www.w3schools.com/tags/tag_a.asp
As to why, I think only the Html group at the time could answer, but i'd guess that since you could link to another page or within the document, hyper linking wasn't all it could do. Or perhaps since bandwidth was more expensive, brevity had a higher value.
The link tag references a link the current document has with an external source, so it is used to specify a link with associated CSS files. Your thinking is "hyperlink", which is different to the tag's intended usage.
As for your new question about "anchor", I would assume it got its name as an anchor is stuck to its place, and the anchor tag points to a specific location (sometimes on the same page, using #id).
I see many pages out there without OG tags (i.e. tags as specified here: http://ogp.me/), yet the Facebook URL Linter seems to be able to get an image and description for them.
For example - you won't see any OG tags (or even other relevant meta tags that could be used to infer said data) on the home page of:
http://www.magicka2.com
But when you take it through Facebook, it finds a description and image:
https://developers.facebook.com/tools/debug/og/object?q=http%3A%2F%2Fwww.magicka2.com%2F
So, what am I missing? The image and description they get seem very specific (and correct). Thanks :)
In case of missing Open-Graph tags, Facebook analyses the page and extracts the image for which it thinks it suits the best and what text should be the description text. They follow some "rules" to determine which picture, but there is also some AI involved and it's part of their systems.
If you want to control which image/title/description your page will show when shared, I would advise to always provide OG-details explicitly.
How do I change the Kentico CMS search settings so as to display a part of text from search results as in Google? Presently it shows only the path in the results.
It depends on how you have your search setup really.
At the page level if you are using the Portal Engine model, which the majority of people use now, you have to check the Widget that you are using, basically it boils down to a regular search or Smart Search.
If your using the ASPX Template model you may have to open up your source for the page and see which usercontrol file your using from ~/CMSWebParts/Search/ or ~/CMSWebParts/SmartSearch/
Once you figure out which user control you are using it's a matter of inspecting the Transformation that it uses. Most likely you'll be using one of the following:
CMS.Root.SearchResults
CMS.Root.SmartSearchResults
CMS.Root.SmartSearchResultsWithImages
Click on Edit Transformation and check out which field is inside the Call to SearchHighlight, normally, "Content". Then you know it's pulling from the main content of the document. I've also seen this be tied to a different field like "Title" or "Caption". But the default is "Content".
If you still dont see results with part of the text, make sure you have a Smart Search Index setup, found in CMSSiteManager -> Administation -> Smart Search. If you don't see your site in the Index list then you need to add one. Make sure you rebuild it and optimize it (click edit on the row to get to those options). After that is all rebuilt then you should see the text appear under the result.
One thing to note, is that as #jao has mentioned, this only takes the first 280 characters of the content of the page. If you're matching search text doesn't happen to be in the first 280 characters, then no highlighting will occur.
try the following in your search result transformation:
<p>
<%# SearchHighlight(HTMLHelper.HTMLEncode(TextHelper.LimitLength(HttpUtility.HtmlDecode(HTMLHelper.StripTags(GetSearchedContent(DataHelper.GetNotEmpty(Eval("Content"),"")),false, " ")), 280, "...")),"<span style=\"background-color: #FEFF8F\">","</span>") %>
</p>
This will show the first 280 characters from your content, with the search terms highlighted.
Right, in short we basically already have a system in place where the HTML content for emails is generated. It's not perfect, but it works.
From this, we need to be able to derive a plaintext alternative for the email. I was thinking of instantly jumping on and creating a RegEx to strip the <*> tags from the message - but then I realised this would be no good because we do need some of the formatting information (paragraphs, line breaks, images etc).
NOTE: I am OK with actually sending the mail and setting up alternative views etc, this is only about getting plaintext from HTML.
So, I am pondering some ideas. Will post one as an answer to see what you guys think, but thought I would open it up to the floor. :)
If you need any more clarification then please shout.
Many thanks,
Rob
My Solution
OK, so here it is! I thought up a solution to my problem and it works like a charm!
Now, here are some of the goals I wanted to set out:
All the content for the emails should remain in the ASPX pages (as the HTML content currently does).
I didn't want the client code to do anything more other than say "SendMail("PageX.aspx")".
I didn't want to write too much code.
I wanted to keep the code as semantically correct as possible (no REALLY crazy-ass hacks!).
The Process
So, this is what I ended up doing:
Go to the master page for the email messages. Create an ASP.NET MultiView Control. This control would have two views - HTML and PlainText.
Within each view, I added content placeholders for the actual content.
I then grabbed all the existing ASPX code (such as header and footer) and stuck it in the HTML View. All of it, DocType and everything. This does cause VS to whinge a little bit. Ignore It.
I then of course added new content to the PlainText view to best replicate the HTML view in a PlainText environment.
I then added some code to the Master Page_Load, checking for the QueryString parameter "type" which could be either "html" or "text". It falls over to "text" if none present. Dependant on the value, it switches the view.
I then go to the content pages and add new placeholders for the PlainText equivalents and add text as required.
To make my life easier, I then overloaded my SendMail method to get the response for the required page, passing "type=html" and "type=text" and creating AlternateView's as appropriate.
In Summary
So, in short:
The Views seperate the actual "views" of the content (HTML and Text).
A master page auto switches the view based on a QueryString.
Content pages are responsible for how their views look.
Job done!
If any of this is unclear then please shout. I would like to create blog post on this at some point in more detail.
My Idea
Create a page based on the HTML content and traverse the control tree. You can then pick the text from the controls and handle different controls as required (e.g. use ALT text for images, "_____" for HR etc).
You could ensure the HTML mail is in XHTML format so you can parse it easily using the standard XML tools, then create your own DOM serialiser that outputs plain text. It'd still be a lot of work to cover general XHTML, but for a limited subset you plan to use in e-mail it could work.
Alternatively, if you don't mind shelling out to another program, you could just use the -dump switch to the lynx web browser.