I'm in the process of creating a searchable combobox component. It must be 100% accessible, so I want to tell screen readers how many results there are available when they open the component's options dropdown, and when they are changing its filter term.
The component looks something like this:
I think I will probably need a live region. I know two ways of doing this:
1) role="alert"
This is AFAIK the safest option: it used to work years ago already, and it is pretty well supported by all major browsers (Chrome/Edge, FF) and screen readers (JAWS, NVDA, VoiceOver/iOS, Talkback).
The bad thing: it is "rude", ie. it interrupts the screen reader's current announcement. In addition, some browsers add an ugly "Alert" as a prefix to each such announcement.
So for example, if the options dropdown is expanded (the user presses Down key after focusing the filter input), then two things happen at the same time:
The filter input's aria-expanded is set from false to true, which makes the screen reader announce expanded
The dropdown is now visible, containing a live region with text 4 of 12 options available, starting with "Badminton"
If this live region is a role="alert", then it potentially interrupts (⚡️) the expanded announcement, which feels like a hiccup from the screen reader, ie. expa⚡️ 4 of 12 options....
2) aria-live="polite"
This is the more gentle option: it will append the live region's content to the current announcement of the screen reader (instead of interrupting it), ie. expanded 4 of 12 options....
Sadly, this is not supported with JAWS+Chrome, as far as my tests show - can anyone confirm this? If so, this is extremely lame, taking into account that its the most used desktop combination, and behind both are multi-national (and probably multi-billion) companies.
Conclusion
I can't just use the gentle aria-live everywhere, I need to figure out which browser is used, and if it's Chrome, I need to reside to role="alert".
But there are more problems: there seem to be serious differences between how browsers (and/or screen readers) handle live regions:
Some have problems recognising a live region if it's first hidden (ie. hidden attribute, or display: none) and then made visible. It will then simply not be treated as live region.
Some immediately announce the content of such a made-visible live region, while others just ignore their initial content (they will only announce a change to it).
Some announce a role="alert" element even when it's already there when the page is loaded, others don't (and I think the latter ones are right, because as far as I understand, live regions should announce changes of content, not content that's initially there already)
So this topic is much more complex than I hoped. The simplest solution would probably be the following: just append a visually hidden role="alert" element at the end of the DOM each time an announcement is be made. Then, a few seconds later, remove it again. But this feels ugly to me. I'd rather have my live region right inside my component, where also visible users can see it, or at least parts of it: on the screenshot you can see 4 of 12 options for filter "d", but to screen readers, the same text is announced, plus some more details, ie. starting with option "Badminton". Keeping visual and screen reader announcement in the same place feels like good practice to me, so I will not easily forget about the latter ones, or I will spot some bugs quickly (that would otherwise may be not visible).
So my question is: is there maybe an existing script or library which solves this problem in a solid way and provides optimal experience for the most common browser / screen reader combos?
Thank you.
Polite live regions should be preferred. As you have noticed yourself, alert interrupts current speech, it's rude.
The prefix "Alert!" automatically added might even feel a little scary at times.
As you have noticed, polite live regions are working a little different on each browser + screen reader combinations. Some of these differences are intentional, others are just bugs, and others are simply due to the fact that the official specification doesn't clearly define any particular behavior.
This makes the whole thing, as you have said, actually quite complicated.
Sadly I have no universally working solution. In order to handle all cases, you need to make user agent detection.
Let's look at various issues or points of attention we have with live regions today (in may 2022).
I have no official reference, the following is only my own observations along the years:
Live region detection
A live regions is successfully taken into account as such only when aria-live attribute is present when the element is added to the DOM, and when it is visible by screen readers.
This, in particular, means that it isn't taken into account when the aria-live attribute is set after the element has been added in the DOM, when the element is display:none, visibility:hidden, when attributes aria-hidden or hidden are set, or when the size is 0. Even if hidding attributes are removed later on, it doesn't work.
Announcement time
The only two cases when the content of a live region has to be announced are:
When the element is added in the DOM
When the content of the element has changed
For all other cases, it isn't well defined in the specification. In particular, initial content present directly in HTML code may not be announced, and as far as I have already observed, none of the browsers I have already used ever announce initial content at page load.
Interruptions
When an assertive live region is added, speech is normally always interrupted. Polite live regions updates should never interrupt speech.
However, with many browsers + screen readers combinations, a content currently being read is shut up:
When the aria-live element is removed from the DOM
When its content is emptied
This is for example the case with VoiceOver both under iOS and mac.
So if you have multiple messages to be spoken potentially quick in succession, you shouldn't just replace the older message by the newer one.
You can adopt several strategies:
Simply append new messages to the already existing live region
Create new live regions each time
Clear live region content or remove it from the DOM only if the last messages is older than a few seconds ago
But, be careful, that's not all.
Repeat or not repeat
With some browsers + screen readers combinations, if you simply append new messages to be announced at the end of a live region, the whole content is repeated over and over again from the beginning.
In short, the whole content is read each time there is a change, even parts that haven't changed.
IN theory, the standard provides the two attributes aria-atomic and aria-relevant to control this behavior.
Defaults values are aria-atopic=false and aria-relevant=additions, meaning that only the new content has to be read, and content that hasn't changed shouldn't be read again.
However, in practice:
Chrome with both Jaws and NVDA ignore these attributes completely. The whole content is always read at every change no matter what.
With Firefox and Jaws, the aria-live region no longer works when aria-relevant attribute is explicitly set
With at least some versions of Safari, the aria-live region doesn't work if aria-relevant=additions isn't explicitly set
With some versions of Chrome, if for any reason you want to speak twice the same message, replacing content doesn't work, even if you replace first by the empty string and then by the content again
Are we safe if we create a new live region for each message? Spoiler alert: no!
Announcement order
When several live regions are added to the DOM or updated quickly, nothing says which one has to be announced first.
Safari iOS seem to handle it correctly, i.e. read content in the order of update. I don't know on mac.
With Chrome and both Jaws and NVDA, updating quickly several live regions seem to make them being read in reverse order of their position in the DOM.
Conclusion
At present, it looks like the safest is to create new polite live regions for each message.
You can reuse them, but only if new messages don't arrive too quickly, or if it doesn't matter if they are occasionally interrupted.
For your particular case, I would say that a single reused polite live region is sufficient.
But of course the best is to test as many combinations as possible.
Good luck.
I build a website with twenty eleven child-theme method, after adding 14 items to menu with Menus under Appearance in wp-admin, only 10 first items appear. I search around the internet and many people mention about adding suhosin to php.ini to solve it. I tried but it didn't help.
Anyone have the solution for it, please help me. I'm using bluehost.
My first thought is, this may be a CSS error only. Your menu may be overflowed with 14 items or didn't get enough space to display all items in one line. Check your browser rendered source code first and make sure that all your 14 menus are listed there or not.
If all 14 items are there, then you need to reduce the font size or padding/margin between each element to accommodate all menu items in one line.
For a better check, provide us the live site link.
In Plone the default folder_contents etc. views display 20 items per page. This is too small number for most of our use cases. How to increase this number to 100?
See https://dev.plone.org/ticket/8115:
The number of items shown by default in the foldercontents is hardcoded in a BrowserView: tableview.py. Although I think it's a good default, I find it frustratingly small for some of my websites. I would suggest to move this value to a new property in site_properties.
You'll have to edit tableview.py, I think.
I am going to write an application that uses QT4 (with C++ or python it isnt important in that moment).
One of functionality is "Showing all items in database".
One item has a Title, author, description and photo (constant size)
And there could be very many items. Let's say 400. There won't be enough space to show'em all at once time.
One row will have 200px, so i need at most 4 for once time.
How to paginate them? I have no idea.
I can use limit and offset in SQL queries, but how to tell window: "that's 5th page"?
Any solutions?
First off, you normally do not want to use any manually set pixel widths in any GUI application, if you do, your toolkit sucks (or you must work in game development).
Second off: be more specific.
You'll need to define "page" for your application, namely what a page should be in its context. I assume it is breaking a list of items into separate pages. Normally this is done by using one of the view classes (e.g. QListView or QTableView) to take care of much of the legwork: it's called a scrollbar (not to mention the collapsing folders concept from file managers). Another method is splitting the information across several tab pages (QTabWidget), where each page displays a view of some sort (Perhaps QTextView or one of the M/V or Item view classes).
Same thing can also be done using your own widget stack and some other widget to manipulate the currently displayed page. This is basically how the option dialogs in the TeamSpeak 3 client and most KDE apps work; it's also how wizards with back/next buttons work in concept. I suggest you take a look at this config dialog example
Normally what you want is a view with a scrollbar and or some form of collapsing related entries into categorised information. If you just want to display a list of pages where each page is X entries: use a tab widget or stacked widget.
Ok so I'm writing a failry complex ASP.NET page that has quite a bit of javascript related to it. The problem is the page has alot going on with it but the browser just acts unresponsive alot of the time and lags while the javascript seems to perform fine.
In this page, I send down a array list of available items for the user to select from. Well when this list grows to like a 1000+ items in the list the page just sucks for lack of better words. If i don't have that many items to select from the page acts fine. I mean the javascript performance is ok but the page just lags. The scroll bars on the page are just laggy, it just feels like horrible. Of course none of this happens in Chrome or Firefox.
To kind of give you a little more perspective on the issue, the site has about 150k unminified uncompress css styles for this page, about 10,000 lines of code for js including frameworks, controls, and business rules specific for the page, and the array object text saved to a text document is about 200kb.
Any help on the matter would be greatly appeciated as this is about my 5th month stab at getting this faster...
One of the Yahoo performance rules is "Reduce the number of DOM elements". They say this for a reason.
When you start to go into the range of "thousands" of DOM elements, IE bogs down pretty rapidly. Every interaction with the page becomes slow. The only "solution" is to use fewer DOM elements.
For example, I recently made a web app containing 4 grids with 100 rows each with around 10 columns, all visible at the same time. Those 4000 cells were making IE really slow. I solved this by using a buffered view grid, that only renders the visible rows, and removes the rows outside of the visible scroll area from the DOM (using the ExtJS grid if it interests you).
Of course none of this happens in Chrome or Firefox.
The bane of my little web app developer existence once things get awesome. There's no answer usually other than to simplify the page.
The concepts behind pagination apply to other application pieces. Active Directory won't display every record in a single list once it's large--and it's a desktop app.
Cut it back and then use the interface to get things gradually (usually through JSON requests for me).