Why is NVDA not able to read the tables properly?
I have created a table with wrt to W3c guidelines by giving proper th elements, but when i try to read thru screen reader it is not reading properly.
Below is the code:
<table border="1">
<tr>
<th id="employee">Employee</th>
<th id="Gender">Gender</th>
<th id="Company">Company</th>
<th id="Skill">Skill</th>
</tr>
<tr>
<td headers="employee">Peter</td>
<td headers="Gender">male</td>
<td headers="Company">Wipro</td>
<td headers="Skill">Testing</td>
</tr>
<tr>
<td headers="employee">Lina</td>
<td headers="Gender">Female</td>
<td headers="Compnay">Mindtree</td>
<td headers="Skill">Development</td>
</tr>
</table>
Please let me know if there are any other free screen reader which works propely wrt to tables.
Below is the code:
<table border="1">
<tr>
<th id="employee">Employee</th>
<th id="Gender">Gender</th>
<th id="Company">Company</th>
<th id="Skill">Skill</th>
</tr>
<tr>
<td headers="employee">Peter</td>
<td headers="Gender">male</td>
<td headers="Company">Wipro</td>
<td headers="Skill">Testing</td>
</tr>
<tr>
<td headers="employee">Lina</td>
<td headers="Gender">Female</td>
<td headers="Compnay">Mindtree</td>
<td headers="Skill">Development</td>
</tr>
</table>
Please let me know if there are any other free screen reader which works propely wrt to tables.
[Moved from Accessify Forum by mod]
I'm not sure if you're using XHTML or HTML, but in XHTML element IDs are case sensitive, so "Employee" is not the same as "employee". Also, you misspelled "Company" in the headers attribute on the last row.
The basic issue is that NVDA doesn't yet support the headers attribute in most browsers. In general, because it's so easy to make mistakes with the headers attribute anyway, it's best to just avoid it for simple tables and instead exploit natural structural elements and relationships. Try, for example, using thead and tbody:
The code is a bit leaner, and less brittle now that you don't need to make sure you get the IDs right on every row! You can make it even shorter if you're using HTML 4.01, since a lot of the tags are optional:
I personally find it easier to read without those closing tags, though it's purely a matter of preference.
The basic issue is that NVDA doesn't yet support the headers attribute in most browsers. In general, because it's so easy to make mistakes with the headers attribute anyway, it's best to just avoid it for simple tables and instead exploit natural structural elements and relationships. Try, for example, using thead and tbody:
| Code: |
| <table>
<thead> <tr> <th>Employee</th> <th>Gender</th> <th>Company</th> <th>Skill</th> </tr> </thead> <tfoot/> <tbody> <tr> <td>Peter</td> <td>male</td> <td>Wipro</td> <td>Testing</td> </tr> <tr> <td>Lina</td> <td>Female</td> <td>Mindtree</td> <td>Development</td> </tr> </tbody> </table> |
The code is a bit leaner, and less brittle now that you don't need to make sure you get the IDs right on every row! You can make it even shorter if you're using HTML 4.01, since a lot of the tags are optional:
| Code: |
| <table>
<thead> <tr> <th>Employee <th>Gender <th>Company <th>Skill <tbody> <tr> <td>Peter <td>male <td>Wipro <td>Testing <tr> <td>Lina <td>Female <td>Mindtree <td>Development </table> |
I personally find it easier to read without those closing tags, though it's purely a matter of preference.
| Quote: | ||
| I'm not sure if you're using XHTML or HTML, but in XHTML element IDs are case sensitive, so "Employee" is not the same as "employee". Also, you misspelled "Company" in the headers attribute on the last row.
The basic issue is that NVDA doesn't yet support the headers attribute in most browsers. In general, because it's so easy to make mistakes with the headers attribute anyway, it's best to just avoid it for simple tables and instead exploit natural structural elements and relationships. Try, for example, using thead and tbody:
|
I have used HTML , but I can use it
Might I point out that you've wasted more bytes on whitespace than you've saved by omitting the optional tags?
Your code was 289 bytes, this is 213 bytes (26% less):
A quarter of the filesize can be jettisoned. And people call it 'insignificant' whitespace....
When you have lots of values which are about the same length, you can write the table in a tabular form:
As opposed to:
First sample is 174 bytes, second one is 251 bytes (not including either [...] part). That makes the first one 31% smaller. You can pad each value with up to 3 bytes of whitespace so they line up and stay within the original size. (A newline followed by a space is 2 or 3 bytes, depending on your OS.)
Honey, I Shrunk the Code!
In a code editor with syntax highlighting, you can write really compact code and it's still legible. To you, at least. In a team it's usually a lot more efficient to write in a more normal, open style.
There's also a return-on-investment calculation to be done when working professionally. If you save 3 bytes after 10 minutes of code wrangling, how much has that cost your company? How much will it save the client in bandwidth?
Compressing the text-based output from your server using Gzip will easily halve the size of those resources. Choose image formats, compression options and removing image metadata can easily save more bandwidth than tweaking HTML whitespace.
With that said, there's no sense in making a website slow due to wasteful coding habits. I see some people using 4 spaces for every level of nesting in their code. They often have divitis, so by the time you get to any significant content more than half the screen is completely wasted space. There are more bytes of whitespace than bytes of code on many lines!
Your code was 289 bytes, this is 213 bytes (26% less):
| Code: |
| <table>
<thead> <tr> <th>Employee <th>Gender <th>Company <th>Skill <tbody> <tr> <td>Peter <td>male <td>Wipro <td>Testing <tr> <td>Lina <td>Female <td>Mindtree <td>Development </table> |
When you have lots of values which are about the same length, you can write the table in a tabular form:
| Code: |
| [...]
<tr><th>Bill<td>11,011<td>0%<td>Optional<td>No<td>Yes<td>Yes <tr><th>Ben<td>5,641<td>49%<td>No<td>No<td>Yes<td>Yes <tr><th>Flower<td>5,370<td>51%<td>Yes<td>No<td>Yes<td>Yes [...] |
| Code: |
| [...]
<tr> <th>Bill <td>11,011 <td>0% <td>Optional <td>No <td>Yes <td>Yes <tr> <th>Ben <td>5,641 <td>49% <td>No <td>No <td>Yes <td>Yes <tr> <th>Flower <td>5,370 <td>51% <td>Yes <td>No <td>Yes <td>Yes [...] |
Honey, I Shrunk the Code!
In a code editor with syntax highlighting, you can write really compact code and it's still legible. To you, at least. In a team it's usually a lot more efficient to write in a more normal, open style.
There's also a return-on-investment calculation to be done when working professionally. If you save 3 bytes after 10 minutes of code wrangling, how much has that cost your company? How much will it save the client in bandwidth?
Compressing the text-based output from your server using Gzip will easily halve the size of those resources. Choose image formats, compression options and removing image metadata can easily save more bandwidth than tweaking HTML whitespace.
With that said, there's no sense in making a website slow due to wasteful coding habits. I see some people using 4 spaces for every level of nesting in their code. They often have divitis, so by the time you get to any significant content more than half the screen is completely wasted space. There are more bytes of whitespace than bytes of code on many lines!
i guess the discussing went off the line!



