Phil,
I have no evidence one way or the other whether screen readers pay
attention
to undisplayed or invisible captions. It seemed safest to assume that
they would
read a visible caption, and that we should head in that general direction.
-- Jon
On 05/17/2017 11:58 AM, Phil Race wrote:
And
The way to do this is to create a file
src/java.desktop/windows/classes/module-info.java.extra
and move the opens there.
See for example
src/java.base/windows/classes/module-info.java.extra
But are you sure jdk.jconsole needs these only on Windows ?
Better make sure of it.
-phil.
On 05/17/201
And PS I was not saying anything to contradict
> tables should not have a summary attribute and should have a caption.
However that the docs I read on the web did seem to imply that
summary was very much intended for ATs but it was not at all clear this
is the point of caption. I'm sure they can
I will leave the decision on whether to do that now up to Sergey although
it seems all he has to do here is remove "invisible".
Many of the "summary" ones had wrong or misleading text but they
seem to have been all fixed.
I'd want to see what the new HTML looks like with a visible title of
cours
I've looked through all the files now. No other comments. So approved.
-phil.
On 05/17/2017 11:19 AM, Phil Race wrote:
I am not sure we are using the summary in a way that makes it worthwhile.
As you noted in the other mail
"The summary attribute was used to give a more descriptive value
of the
Phil,
The bottom line is that in the JDK docs, tables should not have a
summary attribute and should have a caption. This comes down to
accessibility requirements, where we are slowly raising the bar on our
docs, to be in accordance with Oracle's guidelines.
Hiding the caption (style="displa
I am not sure we are using the summary in a way that makes it worthwhile.
As you noted in the other mail
"The summary attribute was used to give a more descriptive value
of the contents of the table. A caption is more like a title"
The values I see are more like a title and as you say that is
It seems, !(parentComponent instanceof Frame)) is not what the spec means.
--Semyon
On 05/17/2017 12:55 AM, Prasanta Sadhukhan wrote:
Ok, sorry. Updated code to get the default Frame when component has no
Frame and
testcase to test that case too.
Updated webrev
http://cr.openjdk.java.net/~psad
Instead of adding more explicit excludes, I would recommend moving the
windows specific source files to:
jdk/src/java.desktop/windows/classes
That is the intended way of making sources platform specific.
If you still need to add the qualified export to jdk.jconsole, but just
for windows, you
Yes, actually I am bit unsure of how to proceed with that. It is meant
to open internal java.desktop classes "only" to jdk.jconsole but now
afer this fix, these classes will only be available in windows platform,
so it should be a conditional "open" and I am not sure if
module-info.java allows
Build changes looks good. However in
src/java.desktop/share/classes/module-info.java you are trying to check
in commented-out code instead of removing it.
/Magnus
On 2017-05-17 12:31, Prasanta Sadhukhan wrote:
Hi All,
Please review a fix for an issue whereby it is seen that
WindowsLookAndFe
Hi All,
Please review a fix for an issue whereby it is seen that
WindowsLookAndFeel classes are built for non-windows platform,
where it is not needed.
Proposed fix is to remove building these classes for non-windows platform.
JPRT build is successful. Also, fixed the regression tests which ex
Ok, sorry. Updated code to get the default Frame when component has no
Frame and
testcase to test that case too.
Updated webrev
http://cr.openjdk.java.net/~psadhukhan/7042497/webrev.02/
Regards
Prasanta
On 5/16/2017 8:47 PM, Semyon Sadetsky wrote:
Yes, sorry. I meant the case I've mentioned in
13 matches
Mail list logo
