Avoid paragraph breaks in reflowable epub3

I know that page breaks are meaningless in reflowable books as the content may be displayed on various devices or screens, or layouts, but there are cases where this is needed : read aloud books.

As in read aloud books the book is auto scrolled, with highlighted paragraphs being read, if at the end of the page, the paragraph is not complete it is however read aloud until the end of the paragraph, which can let the reader in a situation where he cannot not read the text being spoken for a certain time.
When the lecture of the paragraph resumes, the text is auto scrolled and the situation will return to normal on the next paragraph.

Hence to avoid that and to force that each paragraph should display complete, I've tried to add to each <p> tag being referenced from the smil page, a <p style="page-break-inside: avoid" ../>, but it didn't work.
What is the proper way to do that ?

I think, there is no specific meta information for something like screen-readers, why should they break content into arbitrary pages, if the author does not indicate this with a rendition property?
In doubt one can add to the OPF-Document the related meta information:
<meta property="rendition:flow">scrolled-doc</meta>
If one has one document per chapter or subchapter, this is typically the right choice.
This applies to all user agents and indicates that no pagination is intended by the author.
The prefix rendition is related to the namespace http://www.idpf.org/vocab/rendition/#
Because this is not predefined in Version 3.0, only in 3.0.1, which has no own version indication, it is better to define the prefix explicitly.

I'm not sure I understood correctly your answer, but I tried your solution and it's even worse: On Readium, the lecture blocks at the end of the page.. There's a scroll bar on the side, but that's not the subject ...
My question can maybe expressed as follows : is <p style="page-break-inside: avoid;" ../> supposed to produce the correct behaviour according to epub standard ? If placed on every paragraph couldn't it be the solution ?. And if it doesn't work, can it be considered as a reader's bug or lacking feature ?

In EPUB Content Documents 3.0.1 it is not mentioned, that this CSS 2 property is excluded.
The property applies to visual, paged media, on box-level elements within the normal flow of the root element. If this applies for your example and the used viewer and the viewer ignores it, it looks like a bug or gap of the viewer.

Without pagination due to the rendition property, there are no page breaks at all - how can it be worse?

Readium still seems to have a bug for non-linear documents to clip the bottom parts of the content - do you mean this? I reported this already a longer time ago, this reader is borked due to several bugs creating basic accessibility problems, basically because they pessimise the capabilities of WebKit so simulate something like a paper-book ;o) - do you think, it is really in use by the audience?

I'm still struggling on the subject, but for simplicity, let's avoid the read aloud topic. Suppose that I have a reflowable book of one page too long to fit on one page of my tablet. If I want to paginate it, I guess that using the rendition property and the <meta property="rendition:flow">paginated</meta> is the way to do that. As the text is paginated, a bottom paragraph may be spread over two pages. How can I avoid paragraphs being spread over pages, and shifted automatically to the next page ? I have tried the "page-break-inside: avoid;" CSS property, and also the epub:type="pagebreak" on a span element as indicated under : http://www.idpf.org/accessibility/guidelines/content/xhtml/pagenum.php , but no effect on readium or my tablet reader. I doubt I'm the first person to face this problem.. Any help would be appreciated..., I'm a bit puzzled with a documentation not very well illustrated by practical examples.

This is a known sticking point for media overlays in reflowable content.

It would be great if css were obeyed, but support for page breaking is spotty. I believe the primary reason being that css doesn't have a usable pagination model itself, so the complexity of using the computed styles and factoring that into the algorithms that the reading systems use to chunk content is sufficiently high that it's not a priority to implement.

The only reasonably reliable alternative at this time is to increase the granularity of your sync points so that you don't have to wait for an entire paragraph to be read before the reading system resynchronizes the display. Word-by-word synchronization would always work seamlessly, sentence-by-sentence with some lag, and paragraph-by-paragraph being the worst option. Granted, I understand the complexity/cost of increased granularity often makes it a non-starter.

I'll raise this issue with the accessibility group, as there's a new revision to the standard going on right now, but even we were to add that RSes that support media overlays must/should respect the page break properties, it's probably not going to have a tangible effect in the real world any time soon.

And the pagebreak property is entirely unrelated to pagination in reading systems; it's just a marker where print page breaks occur so that someone in a print/digital setting (schools) can follow along with the print users. If a student requires a digital edition because they are blind, for example, they'll need to be able to get to the same "page" in the digital book as their print peers if the rest of the class has a print edition.

No, most reading systems do their own pagination. I've only heard of vivliostyle using the css approach. How to make pagination native to the web is a question both in idpf and the w3c, as it would make reading systems and content development a lot more predictable. The w3c digital publishing interest group has taken up the issue with the css working group, for example. You can read some of the discussions from the last TPAC, though they're not all that helpful in terms of a practical resolution.

Note, too, that CSS3 Paged Media has been partially replaced by the CSS Fragmentation module. I don't know what happens to the pagination model part. It's come up on the lists before, and some people hate the model and others don't see why it shouldn't just be finished up.

IDPF also took a stab at paged media in the Adaptive Layout document, but it's another case of a pagination model that never took off (not implemented anywhere that I know of).

You can request that the reading system not paginate by setting the rendition:flow property to "scrolled", but it won't work across the board, either.

Well I see that Santa Claus didn't bring a solution to my problem, and that the layout issue is far from being solved.
Thank you anyway, the good news is that it will give me an opportunity to reconsider a completely different approach.