The following contents of the HTML file are not read by the screen reader. The NVDA reads the text until "read by the Screen Reader" then it only reads & (and) = (equal) < (less) > (greater) and not any other special characters.
<p>
I want these characters to be read by the Screen Reader "&=`"<>\[]-".
</p>
Use this technique intended for emoji: http://tink.uk/accessible-emoji/
These things are simple to fix though. We need to tell the browser to expose the emoji (or its container) as an image, then give it an accessible name.
Use the ARIA img role to expose the as an image in the accessibility tree:
<span role="img">☃</span>
Then use the aria-label attribute to give the emoji an accessible name:
<span role="img" aria-label="Snowman">☃</span>
[…]
Now the browser will expose the emoji as an image in the accessibility tree, and use the value of the aria-label attribute as its accessible name. When a screen reader queries the accessibility tree it will use this information to tell the user that there is an image of a snowman (☃) on the page.
You have to give it a role otherwise the aria-label will not be announced.
Related
Is it possible to check textual user input in a PowerPoint presentation?
I would like to create some kind of password field that users need the fill in correctly, before they can move on to the next slide.
To be clear: This is while the presentation is running, not in the edit mode.
An ActiveX text box can receive user input while the presentation is in slideshow view and has a Password Character property which, if set, displays the chosen character instead of whatever the user is typing; keeps the password safe from prying eyes.
My company is trying to become WCAG compliant. One of the things we need to do is add aria-label to interactive elements. My question is do I need to add an aria-label to an element which already has a label which is read by a screen reader.
So basically i definitely need a "close" aria-label here:
<button>x</button>
But in some cases I have a placeholder for example, which is read by the screen reader. Do I need to add an aria-label anyway just in case? The aria-label would be the same as the placeholder.
#mikkel has good advice regarding the first rule of ARIA use.
Regarding your specific question on the placeholder attribute, relying on the placeholder as your label would fail several WCAG checkpoints.
Placeholder text is typically light gray and when displayed on a white background often fails 1.4.3 Contrast Minimum
The placeholder text disappears when you start typing so now the "label" has disappeared and would fail 3.3.2 Labels or Instructions
The placeholder attribute is not specifically referenced in the accessible name calculation (https://www.w3.org/TR/accname-1.1/#step2) although it might be considered in step 2D as "an attribute that defines a text alternative". It's not clear if placeholder is a "text alternative". Personally, I don't think it is. If not, then you would fail 4.1.2 Name, Role, Value
If you look at the spec for placeholder, it has a big disclaimer about not using it as a label.
Warning: Use of the placeholder attribute as a replacement for a label can reduce the accessibility and usability of the control for a range of users including older users and users with cognitive, mobility, fine motor skill or vision impairments. While the hint given by the control’s label is shown at all times, the short hint given in the placeholder attribute is only shown before the user enters a value. Furthermore, placeholder text may be mistaken for a pre-filled value, and as commonly implemented the default color of the placeholder text provides insufficient contrast and the lack of a separate visible label reduces the size of the hit region available for setting focus on the control.
So, all that being said, yes, you should have some kind of visible label associated with your input field even if you are using the placeholder attribute.
Short answer, no.
Long answer, it depends on the situation.
But important – first rule of aria:
If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
When in doubt, choose native HTML.
https://www.w3.org/TR/using-aria/#rule1
If you have a visible label, then you should connect the label text and the input field via the label-element.
If the input field does not have a visible label, the aria-label is one technique that can add the label semantically.
In your example of the button, you should use an aria-label, as the "X" doesn’t give the user any information. Of course, most users can guess what an "x" dos, but the user should not have to guess.
And here am talking of users who use assistive technology.
I would recement that you get a professional to test your site, for legal reasons but mostly for your users.
I'm a web developer, but have used the last 10 years on web accessibility. So far, it’s the hardest field of web development I hav had to learn and I'm still learning. 😊
Thanks for looking.
Background
I am working on a MS Outlook plug in that requires certain text to be injected into the body of a new meeting request when a button click event fires.
The meeting request window only allows plain text or RTF (no HTML). The text that my application needs to enter should be able to be swapped out when the button is clicked again, but should not remove any text that the user may have added either above or below mine.
For now, I use a string of underscores with a leading and trailing set of hidden slashes like this:
\v//\v0__________________________________________________________________
{MY CUSTOM TEXT GOES IN BETWEEN}
__________________________________________________________________\v//\v0
Problem
With plain text, this is not a problem, but the problem arises when the user edits the body, and then clicks the update button again, it seems that the structure of the RTF encoding changes in a way that is not predictable and I therefore can not search for my text boundaries. For example, after the user adds their own text and clicks the "update button", my code now receives the following which I am unable to find using IndexOf():
//}{\\rtlch _______________________________________________________________
Question
Is their an easier, more consistent way to have essentially merge fields in RTF that the user may edit? I essentially just need to swap in or out a chunk of very simple text regardless of whether the user has written above or below it.
Thanks.
Actually HTML for appointments is supported by Outlook 2016. In any case however, Inspector.WordEditor returns an instance of the Word's Document object, so you can add a bookmark around your text using the Word Object Model rather then by injecting text visible to the end user.
I feel strange asking a question about what's probably the simplest page in my iPhone app but here it is anyway:
I have a controller that a user can invoke to display the rules of the game and some acknowledgment information. I set up a Text View object filling up the whole page in Interface Builder and am wondering what's the best way of entering the text I need.
I can do all of this in the m file but entering large text sections in a programming language is never fun.
I can also simply overwrite the default "Lorem ipsum dolor..." text in Interface Builder but then my return characters don't seem to be taken into account when I run the app.
Is there a better way to fill my Text View with my own formatted text? And how can I format my text neatly and easily (i.e. make titles in bold, underline some words, etc.)?
Thanks.
There is no way to easily display formatted text in a UITextView. The best approach for this kind of problem is to use a UIWebView and store the text as an HTML file.
Use the NSTextStorage class to store the formatted text in your NSTextView.
Use Core Text
Core Text Tutorial for iOS: Making a Magazine App
I want my application to detect whatever has been typed applications like text edit or text area of any other applications.
I am using Mac.
Thanks,
Rahul
This is accessible from the text view's -textStorage, which is a subclass of NSMutableAttributedString/NSAttributedString. You can get the attributes (including font) for a given range. Expanding on that, you can ask the text view for it's typing attributes, which are the same thing NSAttributedString uses.
That said, the only way to get this reliably from other applications is to use input managers or an unsavory code injection a la ApplicationEnhancer.