While doing accessibility sanity checks, I like to ensure to provide appropriate guidance for developers to correct anything that is reported as problematic or incorrect.
In this case, their implementation of a tooltip was incorrect. So I set to use MDN's documentation (https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Tooltip_Role) as a reference.
But before simply sharing that, I tested MDN's code example with VoiceOver myself, and I discovered something curious:
List elements (<ul> in MDN's example) are not actually read by the screen reader. I tested with VoiceOver on Chrome and Firefox, and they both read the tooltip content as expected.
Does anyone know if this is a Safari bug, or if there is anything to ensure to do in the markup to ensure the tooltip content is read?
Here is a link to test: https://htmlpreview.github.io/?https://github.com/jansensan/test-a11y-tooltip/blob/main/public/index.html
Here is the code: https://github.com/jansensan/test-a11y-tooltip/blob/main/public/index.html
Edit: To clarify, I currently tested this on macOS Ventura with Safari, Firefox, and Chrome. The issue of VoiceOver not reading the content happens on Safari (weirdly enough). It skips the list altogether (I added paragraphs , <p> before and after the list to see what it would read).
There are two different situations here.
Descriptions only need to be read as a flat string
According to ARIA’s Text Equivalent Computation, exposure of the referenced structure is not required:
The purpose of the computation is to create a perceivable label or description for alternative presentations, in the form of a flat string of space separated textual tokens.
So this concerns the text read when focus is on the input—provided the user activated announcement of descriptions in their settings.
Reading the tooltips content by moving reading cursor onto it
If the reading cursor is moved onto the tooltip widget itself, the whole contents must be read, including structure. It would be surprising if Safari didn’t do that. If it doesn’t, it’s a bug.
Tooltips must stay open on hover
Both tooltip examples have one issue, though: They fail WCAG Success Criterion 1.4.13 Content on Hover or Focus, because they close when trying to move the mouse pointer on them.
Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
It’s a reflex of mouse users to hover content they are reading, independent of screen reader use.
Related
I am using IntelliJ Idea for developing scala and Java programs. I am also a screen reader user.
One of the most useful features that IDEs provide is code linting and displaying error and warnings in your code, along with descriptions. I understand if you are a sighted user, you can just hover your mouse over an erroneous line of code and you get a tooltip with the description.
I haven't been able to figure out how to access this description as a screen reader users. So far, to review errors/warnings I would just build the program and look at the command line output, however this is pretty inefficient compared to just hovering over line of code.
Could someone share a better way of reviewing errors/warnings in IntelliJ using a screen reader? Ideally how to access the error tooltip, or how to access a better UI for reviewing them instead of looking at raw command line output.
I'm not sure about warnings however errors can be accessed in two ways:
Firstly when the caret is moved into a line with error the error text is written into the status bar - the problem with this approach is that for JAB applications screen readers are generally unable to find it, so in case of NVDA object navigation has to be used.
The second way requires your caret to be exactly at the point with error - generally it would be set in the proper place if you've navigated to the line with F2. After that you need to press CTRL+f1 - focus moves to the unnamed pane and the error text is its first descendant so once again you need to employ object navigation. I haven't found any reasonable way to access error texts with JAWS sadly.
Importantly, make sure to turn on screen reader support:
settings (ctrl + alt + S) > appearance and behaviour > Appearance > Support screen readers (requires restart)
Then when your caret is on an error/warning, you can press ctrl + F1 and a dialogue will pop up with the description. Press escape to close it.
If you want to make sure the caret is on an error/warning, use F2 to jump to next error/warning.
As noted by lukaszgo1 in his answer, the description is also printed to status bar, but NVDA cant find it using its normal command, because JAB GUI applications are lacklustre in their implementation of accessibility, however if you want to access the status bar of IntelliJ to read the description you can use an NVDA addon which I developed, that adds a command for reading IntelliJ status bar and fixes list items not being labelled properly.
I actually forgot I asked this until I got an answer recently.
Thanks to lukaszgo1 for his answer.
After Ctrl+Q (Quick documentation) I could not see all text. I have to scroll horizontally to see all content. I could not make the editor to fit the window.
UPDATE:
The problem is only symbol definition, ie. the first line. The description (block text) is wrapped correctly. Actually, I don't want to resize this window as I prefer to keep it as I write in the same position for quick reference. I have to add that my monitor is quite small (15-inch) which is probably causing the problem.
Indeed method signature in the popup is not wrapped. There is a request you can vote for: IDEA-169414.
UPDATE: The documentation popup is reworked in 2018.1 and it should be fixed.
I'm not aware of a way to configure IntelliJ to wrap text in these windows.
I think the quickest way to see the full line in the quick documentation window is to press Ctrl+Q again to make it a little bigger (and center it) or maximize it with Ctrl+Shift+"
Keep in mind that the smallest version (the one that appears after the first Ctrl+Q) can be resized by hovering the mouse cursor over its edge and dragging it. It's going to retain the same size the next time you open it.
I've made a couple small Safari extensions. For one of them, I would like to collect a set of user-entered strings (e.g., URLs or URL patterns) using a textarea in the settings screen. The only setting types offered in the documentation are one line text, check box, slider, select lists, and radio buttons. I could use a one line text field as an ugly workaround, but I'm hoping there's a better option. I've googled for hints and looked through Safari extensions in GitHub, but haven't found an example of anyone doing this yet.
Does anyone have an example of how to use a textarea for a Safari extensions setting? Is there an undocumented feature I've not been able to find? Or is there a way to trigger a custom popup window from the settings?
Thanks for any tips.
No, there is no way to build a more complex UI inside the settings dialog. What extensions typically do is add a button (checkbox, even if it's not quite the correct element) in the settings page which then launches a separate Safari page which contains the full settings UI, written in HTML.
For an example of this, install uBlock and take a look at how it launches its setting UI.
I am making a webpage that has different areas that can be clicked on to change the contents.
I want to set it up so that when you click on an area, an openWYSIWYG editor appears in the middle of the screen with the rest of the page greyed out.
I have achieved this except for the positioning of the editor. When you click on a section I have a div with 50% opacity cover the page and a textarea appear in the middle. But when I try to attach the editor to the textarea, it loses it's position and falls behind the div not in front of it like the textarea is.
Can anyone suggest a way of centring the openWYSIWYG editor?
You're looking for Modal positioning. Here's one solution:
http://jqueryui.com/demos/dialog/#modal-form
Basically, apply the Jquery Dialog to the div that holds your WYSIWYG. Don't forget a submit button.
Just a quick heads up--I went through quite a bit of headache dealing with WYSIWYG editors for client-facing sites a few months back. It seems that clicking the "paste from WORD" button was a very difficult task to figure out. Word-pasted code can wreak havoc on websites, overrunning text fields in the database. I gave it a try on their demo (which also doesn't support webkit based browsers) and the result wasn't pretty. The only two options I found to solve this were to sanitize code on the back end, or to use CKEditor. I chose the latter because it was so easy. Take a look at CK, it's a great piece of free code.
I am using (a school modified version of) the "Squeak By Example" (SBE) image for a OOP/OOD class. However, my System Browser is missing a few features that appear in SBE. I assume there are some configuration options that can get them back for me, but I can't find them yet.
My questions are:
1) How do I get the buttons back? In the bottom pane there should be a bunch of button (browse, senders, implementors, versions, ..., source). My buttons are missing.
2) How do I get the small workspace area above the buttons to appear? There is supposed to be an area that I can type in, below the top panes, and above the buttons, but it doesn't appear.
Thanks in advance!
Robert
Edit - I did fool around in the Preferences Browser and tried a lot of settings. I managed to make the buttons come back and then later got that small (unknown name) workspace pane back, but I have no idea how. I have tried to systematically turn stuff off again to find out what setting(s) controlled what, but I was unable to determine what controlled either problem. So even though I have it working, I would like some squeak/smalltalk knowledgeable person to let me know how to control these as it might help me learn...
"In the bottom pane there should be a bunch of button (browse, senders, implementors, versions, ..., source). " -- switch on the optionalButtons preference in the preferences browser.
The "area that I can type in, below the top panes, and above the buttons, but it doesn't appear" sounds like the annotation pane - this gives you summary information about the method you're currently viewing, and it's controlled by the annotationPanes preference. Alternatively you may be referring to the Mercury Panel which is used for fast navigation to other classes and methods; this is (of course :-) controlled by the mercuryPanel preference.
If you've been messing around, you may also find that you now have an incorrect system browser selected. Squeak has a choice of browsers which can act as the System Browser. You can choose between them by clicking the menu button on the System Browser and selecting "Choose new default Browser". Open a new browser window to see what effect this has had.
You may also want to try a Pharo image which has everything configured the way you want by default.
Do you have access to the Preferences Browser? It should be in the main system menu. You can alter all sorts of things via this browser, including which buttons appear in teh system browser?