Post your feature requests hereBack to Forum List
>>
Back to Topic List
>>
VIEW ALL POSTS
Accessibility in Reports
Posted Friday, 27 March 2009 By Josh Martin
NextReports -
I'm a Java developer and am very excited to potentially use your product embedded in a reporting application we use. One of our key requirements is accessibility (a.k.a. 508 compliance).
Since your reports are table-based (exactly what we're looking for), it should be easy to implement. There is a similar request (with the requirements) in the BIRT reporting tool:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=178171
Essentially, the output table headers in HTML () should support the "scope" and "id" attributes. The output table rows () should support the "headers" attribute. This is fully outlined here:
http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.4 />
Putting these values in the "Properties" section of your IDE would make it really easy to use. You would just need to take these values and putting them in the HTML output.
If this is a possibility in the short-term, it would definitely sway my decision away from using BIRT (since we really just need table-based outputs).
Thank you,
Josh
I'm a Java developer and am very excited to potentially use your product embedded in a reporting application we use. One of our key requirements is accessibility (a.k.a. 508 compliance).
Since your reports are table-based (exactly what we're looking for), it should be easy to implement. There is a similar request (with the requirements) in the BIRT reporting tool:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=178171
Essentially, the output table headers in HTML () should support the "scope" and "id" attributes. The output table rows () should support the "headers" attribute. This is fully outlined here:
http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.4
Putting these values in the "Properties" section of your IDE would make it really easy to use. You would just need to take these values and putting them in the HTML output.
If this is a possibility in the short-term, it would definitely sway my decision away from using BIRT (since we really just need table-based outputs).
Thank you,
Josh
Accessibility in Reports
Posted Monday, 30 March 2009 By Mihai
We can add in Properties panel three new accessibility properties for scope, id , headers for every cell and these will be taken into account just for html export.
For html export we use only tr and td tags. For scope we can use a combobox editor with row and col as values. For id and headers properties we will use a simple textfield editor (and user can enter anything he wants).
For a cell with ${column} from database, this cell will be generated for every entry, and all will have the same value for that property (scope, id, headers). Is that ok?
If that's ok we can implement this in a few days.
For html export we use only tr and td tags. For scope we can use a combobox editor with row and col as values. For id and headers properties we will use a simple textfield editor (and user can enter anything he wants).
For a cell with ${column} from database, this cell will be generated for every entry, and all will have the same value for that property (scope, id, headers). Is that ok?
If that's ok we can implement this in a few days.
Re: Suggested Implementation for Accessibility in Reports
Posted Tuesday, 31 March 2009 By Josh Martin
Mihai -
I think your approach sounds great. Every cell is a TD in the output, and if the user has entered anything in the scope, headers, or id attributes, it will be output.
I agree that the id and headers attributes should be free text - that makes it the most flexible. The scope attribute can be a dropdown, but it actually needs four possible values:
row
col
rowgroup
colgroup
Here's a link to the W3 definition:
http://www.w3.org/TR/html4/struct/tables.html#adef-scope />
I've never used rowgroup or colgroup in practice, but I would guess it's better to have all the allowed values.
I think your approach sounds great. Every cell is a TD in the output, and if the user has entered anything in the scope, headers, or id attributes, it will be output.
I agree that the id and headers attributes should be free text - that makes it the most flexible. The scope attribute can be a dropdown, but it actually needs four possible values:
row
col
rowgroup
colgroup
Here's a link to the W3 definition:
http://www.w3.org/TR/html4/struct/tables.html#adef-scope
I've never used rowgroup or colgroup in practice, but I would guess it's better to have all the allowed values.
Re: Suggested Implementation for Accessibility in Reports
Posted Wednesday, 01 April 2009 By Mihai
From the W3 definition I understand that rowgroup has a meaning only if rows in html are grouped into a table head, table foot, and one or more table body sections using the tags THEAD, TFOOT, and TBODY. But these tags are not used in NextReports html generation (only TR and TD are used). And the same for colgroup, it has a meaning only if the tags COLGROUP or COL are used. So, isn't it meaningless to add rowgroup and colgroup to the dropdown scope attribute?
Re: Suggested Implementation for Accessibility in Reports
Posted Wednesday, 01 April 2009 By Josh Martin
Yes that makes sense. If the output is only TR and TD tags, then adding those options would just add confusion. I.e. row and col would be fine.
Re: Suggested Implementation for Accessibility in Reports
Posted Thursday, 02 April 2009 By Mihai
Ok Then.
Version 2.2 of NextReports will have this feature. We will provide a property in next-reports.properties : accessibility.html
By default this will be set to false. Setting it to true will make the html accessibility properties visible in the layout properties panel.
Version 2.2 of NextReports will have this feature. We will provide a property in next-reports.properties : accessibility.html
By default this will be set to false. Setting it to true will make the html accessibility properties visible in the layout properties panel.