our goal is reduce the empty cells in tables, especially where headers should.
empty cells diminish the experience for assistive technology users.
through this study we'll design some accessible options we could generically use to represent dataframes.
# proper html tables with multiple indexes
our goal is reduce the empty cells in tables, especially where headers should.
empty cells diminish the experience for assistive technology users.
through this study we'll design some accessible options we could generically use to represent dataframes.
our goal is reduce the empty cells in tables, especially where headers should.
empty cells diminish the experience for assistive technology users.
through this study we'll design some accessible options we could generically use to represent dataframes.
create a sample dataframe to work with that has multiple indexes on both axes.
this facilitates our study because it is easier to remove axes than add them later. the code snippet below provides our expected outcome.
2
create a sample dataframe to work with that has multiple indexes on both axes.
this facilitates our study because it is easier to remove axes than add them later. the code snippet below provides our expected outcome.
## accessibility html recommendations
there is a long [history of html table layouts], they have existed since [html 3.2 in january 1997](http://www.w3.org/TR/REC-html32), these standards precede a lot of the history of mass data literacy.
`table`s are introduced to present 2-D data structures
> [VISICALC](https://en.wikipedia.org/wiki/VisiCalc) represented a new idea of a way to use a computer and a new way of thinking about the world. Where conventional programming was thought of as a sequence of steps, this new thing was no longer sequential in effect: When you made a change in one place, all other things changed instantly and automatically.
>> Ted Nelson[13]
considering the accessibility of `table`s means we need extend the visual representation to the tactile and audible experiences.
let's start with some popular advice from [rachele ditullio] about [5 ways to improve table accessibility]
1. Caption that table
2. Include header text for every column
3. Use alt attributes meaningfully
4. Have data in every table cell
5. Check your (con)text
this is where we start because these recommendations represent users needs before needs.
accessibility requires us to center a user's visual, audible, and tactile experience when working with data.
[5 ways to improve table accessibility]: https://racheleditullio.com/blog/2020/03/5-ways-to-improve-table-accessibility/
[rachele ditullio]: https://racheleditullio.com
[history of html table layouts]: http://www.tiernok.com/posts/history-of-html-table-layouts.html
VISICALC
represented a new idea of a way to use a computer and a new way of thinking about the world. Where conventional programming was thought of as a sequence of steps, this new thing was no longer sequential in effect: When you made a change in one place, all other things changed instantly and automatically.
 Ted Nelson[13]
considering the accessibility of
table
s means we need extend the visual representation to the tactile and audible experiences.
this is where we start because these recommendations represent users needs before needs.
accessibility requires us to center a user's visual, audible, and tactile experience when working with data.
%%-u## testing an actual dataframebasedoffthesesuggestionswecanconnectdataframeparlancetotheconsistentstandardsofhtml.whatfollowsarecommentsonhoweachall5ofthesuggestionsapplyto`pandas.DataFrame`objects.1.`pandas`tablestypicallylacka`caption`unlessthecodeauthorisawareof`df.style.set_caption`.the`caption`elementprovidesanarialabelthat`givesassistivetechnologyusersmorecontextastheynavigateinformation.df.style.set_caption("the public api for adding a caption to a dataframe.")2.asofv2.2,thereareconformationspandascolumnsandindexesthatgeneraterepresentationscontainingemptyheaders.anaccessible,assistiveexperiencewillavoidemptycells,especiallyheadercells.thefirstcellinthetableisemptyforthecaseswhere`count_empty_cell`revealsnon-zeroresults.thismeansthatassistivetechnologyuserswillfindemptycellsinmostofthepandasdataframerepresentationsavailableonline.thisoversightiscostlybecausetechnologieslikescreenreadersandbrailledisplaysrequireparsinginformationseriallyratherthanourparallelvisionexperience.defcount_empty_cell(df):`count_empty_cell`willcounttheempty`th`and`td`elementsinarendereddataframe.itwascreatedtodemonstratethedifferentconditionsondataframeindexesandcolumnsthatinfluencethecurrentvisualformofthedataframe.*ourtestdataframehasemptycellsbecausetheindexandcolumnsareunnamed.>>>assertcount_empty_cell(df)>0*adataframewithanamedcolumnindexhasnoemptycells.>>>assertcount_empty_cell(single.rename_axis(columns="upper"))==0*thereareemptycellswhentheindexisnamedbecausetheindexnameisgivenitsownrow.>>>assertcount_empty_cell(single.rename_axis(index="lower"))>0table_cells=pandas.Series(bs4.BeautifulSoup(df.to_html(),features="lxml").select("th,td"))returntable_cells.apply(any).__invert__().sum()4.addingalttexttoimagesisoutofscopeforthisinvestigation.itisveryvalid.pandasdataframesmaycontainvariousmimetypesofcontentandtheirrepresentationsshouldbeassistive.however,forthisstudy,theindexandcolumnsaretheprimaryaxesforbuildinganaccessibletablesubstrate.5.`null`and`Nan`needsemanticallymeaningfulrepresentations.theprogrammingcollquialismsforemptycontentmaynottranslatetoassistivetechnology._whataboutbraille_?itisunlikelythereisabestplaceholderforthisvaluessothisvalueshouldbeconfigurable.placeholder="not a number"df.fillna(F"<span class=sro>{placeholder}</span>").style6.yesabbreviationsandpunctuationshouldbeconsidered,butthisisanadvancedtechniquethatrequiresmanuallyscreenreadertestingliteracies.thecomparisonbetweenrachel's advice and `pandas` dataframes is just a start down the rabbit hole.we'll begin to bring in other articles, standards, and specifications to design ARIA first rule implementationsofpandastidyframes.
### more accessible tables
our next resource provides more dos and don'ts that correspond to accessible table experiences.
*✅ Designate at least one row and/or column header using the table formatting tools in your web content management system or document creation software.
`pandas` dataframes should be represented with a named index or column.
*✅ Use the `<th>` element to mark up table headers in HTML.
*❌ Table headers should never be empty. This is particularly of concern for the top-left cell of some tables.
our primary task is to remove empty cells from the `thead` porition of the dataframe representation.
currently, it is very common for screen reader users to find empty first cells in a table.
imagine how much it sucks.
*✅ If you do create a complex data table on a webpage, use the `<scope>` tag to programmatically associate the data cells with the appropriate headers.
*❌ Don't merge cells.
merging cells creates ambiguities. `td`s in dataframes will NEVER be spanned.
#### Accessible table do and don't
https://accessibility.umn.edu/what-you-can-do/start-7-core-skills/tables
<details><summary>Use Tables to Display Data</summary>
*✅ Use tables to present information in a grid, or matrix, with columns or rows that show the meaning of the information.
-❌ Don't use tables to make your webpage look a particular way. Layout tables on webpages do not pose inherent accessibility issues, but it is more difficult to make sure screen reader software reads the cells in the proper order.
-❌ Never use tables as a means of laying out a page in a Google or Microsoft Word document. While these tables can be hidden from visual users by simply eliminating the borders between cells, they cannot be hidden from screen readers.
</details>
<details><summary>Designate Row and/or Column Headers</summary>
*✅ Designate at least one row and/or column header using the table formatting tools in your web content management system or document creation software.
*✅ Use the `<th>` element to mark up table headers in HTML.
-❌ Don't create tables without table headers.
-❌ Don't just change the visual formatting of the text, such as the font size or color, to visually indicate table header rows and/or columns. Screen readers will not be able to associate the headers with the correct cells.
-❌ Table headers should never be empty. This is particularly of concern for the top-left cell of some tables.
</details>
<details><summary>Avoid or Simplify Complex Tables</summary>
*✅ Include a maximum of one header row and one header column.
*✅ Spell out abbreviations or acronyms, or use the `<abbr>` or `<acronym>` tags in HTML to ensure accessibility.
*✅ If your table has multiple header rows, merged cells, or another table embedded in it, split it into two or more simple tables.
*✅ If you do create a complex data table on a webpage, use the `<scope>` tag to programmatically associate the data cells with the appropriate headers.
-❌ Don't merge cells.
-❌ Don't include a table within another table.
</details>
<details><summary>Provide Contextual Information</summary>
*✅ Associate descriptive text about a table with its respective table by including a `<caption>` element in HTML or alt text in Microsoft Word. Captions are not necessary for each table, but can helpful for screen reader users. The caption can be visually formatted and positioned above or below the table as needed, but on webpages, the `<caption>` element must be the first one after the opening `<table>` tag.
*✅ You may use `<thead>`, `<tfoot>`, and `<tbody>` tags in HTML tables so that the head and/or foot rows repeat at the top or bottom of the table when it is printed, but these do not provide any additional accessibility benefits.
-❌ Don't repeat the same text in the caption that appears in a heading preceding the table.
-❌ You may provide a summary of the structure of the data table (not of the content) using the `<summary>` attribute, but screen reader support for it varies, and it is not part of the HTML5 specification, so WebAim does not recommend it.
-❌ If both a caption and summary are provided for one table, the summary should not duplicate information present in the caption.
</details>
<details><summary>Include Content in All Cells</summary>
*✅ Include text such as "not applicable," "none," etc. to indicate that there is no data in empty cells.
-❌ Don't leave any table cells empty.
</details>
our next resource provides more dos and don'ts that correspond to accessible table experiences.
✅ Designate at least one row and/or column header using the table formatting tools in your web content management system or document creation software.
pandas
dataframes should be represented with a named index or column.
✅ Use the
<th>
element to mark up table headers in HTML.
❌ Table headers should never be empty. This is particularly of concern for the top-left cell of some tables.
our primary task is to remove empty cells from the
thead
porition of the dataframe representation.
currently, it is very common for screen reader users to find empty first cells in a table.
imagine how much it sucks.
✅ If you do create a complex data table on a webpage, use the
<scope>
tag to programmatically associate the data cells with the appropriate headers.
❌ Don't merge cells.
merging cells creates ambiguities.
td
s in dataframes will NEVER be spanned.
✅ Use tables to present information in a grid, or matrix, with columns or rows that show the meaning of the information.
❌ Don't use tables to make your webpage look a particular way. Layout tables on webpages do not pose inherent accessibility issues, but it is more difficult to make sure screen reader software reads the cells in the proper order.
❌ Never use tables as a means of laying out a page in a Google or Microsoft Word document. While these tables can be hidden from visual users by simply eliminating the borders between cells, they cannot be hidden from screen readers.
Designate Row and/or Column Headers
✅ Designate at least one row and/or column header using the table formatting tools in your web content management system or document creation software.
✅ Use the
<th>
element to mark up table headers in HTML.
❌ Don't create tables without table headers.
❌ Don't just change the visual formatting of the text, such as the font size or color, to visually indicate table header rows and/or columns. Screen readers will not be able to associate the headers with the correct cells.
❌ Table headers should never be empty. This is particularly of concern for the top-left cell of some tables.
Avoid or Simplify Complex Tables
✅ Include a maximum of one header row and one header column.
✅ Spell out abbreviations or acronyms, or use the
<abbr>
or
<acronym>
tags in HTML to ensure accessibility.
✅ If your table has multiple header rows, merged cells, or another table embedded in it, split it into two or more simple tables.
✅ If you do create a complex data table on a webpage, use the
<scope>
tag to programmatically associate the data cells with the appropriate headers.
❌ Don't merge cells.
❌ Don't include a table within another table.
Provide Contextual Information
✅ Associate descriptive text about a table with its respective table by including a
<caption>
element in HTML or alt text in Microsoft Word. Captions are not necessary for each table, but can helpful for screen reader users. The caption can be visually formatted and positioned above or below the table as needed, but on webpages, the
<caption>
element must be the first one after the opening
<table>
tag.
✅ You may use
<thead>
,
<tfoot>
, and
<tbody>
tags in HTML tables so that the head and/or foot rows repeat at the top or bottom of the table when it is printed, but these do not provide any additional accessibility benefits.
❌ Don't repeat the same text in the caption that appears in a heading preceding the table.
❌ You may provide a summary of the structure of the data table (not of the content) using the
<summary>
attribute, but screen reader support for it varies, and it is not part of the HTML5 specification, so WebAim does not recommend it.
❌ If both a caption and summary are provided for one table, the summary should not duplicate information present in the caption.
Include Content in All Cells
✅ Include text such as "not applicable," "none," etc. to indicate that there is no data in empty cells.
it is hard to imagine a way to constructing a dataframe with two named indexes without empty cells.
we'll likely include an empty row or column. this might seem like this is authoring choice, but we can't know our viewers intent when they interrogate data. the most flexible, compromising approach would be allow for this to change on the client, where the only author choice represents the steady state.
2
it is hard to imagine a way to constructing a dataframe with two named indexes without empty cells.
we'll likely include an empty row or column. this might seem like this is authoring choice, but we can't know our viewers intent when they interrogate data. the most flexible, compromising approach would be allow for this to change on the client, where the only author choice represents the steady state.
### non-spanning frames
so far we have only illustrated spanning examples meaning that the row/column index may span multiple rows;
only headers will span for dataframes while data will not.
this experience can really suck for assistive technology introducing navigation ambiguities and complications.
so far we have only illustrated spanning examples meaning that the row/column index may span multiple rows;
only headers will span for dataframes while data will not.
this experience can really suck for assistive technology introducing navigation ambiguities and complications.
%%## visual and nonvisual shaperowsandcolumnsreferencesina`table`arethenotthesameasadataframe.conventionholdsthatdataframesshowtheirshape,theshapeofthedata.thenominalreferencesweusefordataframesareshiftedordinalreferenceswhentheshapeissharedalongsideascreenreader.theshapeofthetabletothescreenreaderinclusedtherowsandcolumns.toassistivetechnology,theshapeofthedataframeiscomputedby:df.shape[0]+df.columns.nlevels,df.shape[1]+df.index.nlevelsthisnaiveheuristicisonlytrueforcertaincombinationsofmultiindexes.amorerigorousimplementationwouldhandletheseedgecases.theseinconsistenciesmeanthatscreenreaderusersmaybereferencingandifferentindexingsystemthansightedusers.weimprovethecaptioningwiththenominalshapevstheactualshape.mentioningtherowandcolumnslevelswouldhelpparsethiscontent.ifwearerequiringfolkstodomathintheirheadsthenwe'll want an adaptive approach to discussing shape.