<div dir="ltr"><div>Your original question said when you found the webpage for the article, it was "in beautifully formatted and structured HTML".  That's fantastic.  All things being equal, it's easier to make a webpage accessible than a PDF document.  There is so much built in accessibility with HTML if you're using semantic elements (such as headings <h1>, tables <table>, lists <ul>, etc).  You don't have to do anything extra when you use semantic HTML elements.  It works great with screen readers and other assistive tech. <br></div><div><br></div><div>For PDF, you are at the mercy of whoever created the original document and how they created the PDF from that document.  If the original document was a Word document and the author did not use styles to mark up headings, then the resulting PDF will not have any heading info.  Then someone has to remediate the PDF by adding tagging information.  That can take a lot of effort and even if you get the PDF perfect, if the original document changes and you need a new PDF, you have to do all the remediating all over again.</div><div><br></div><div>And there's a lot of accessibility information that *can't* be included in the original document, depending on the technology you're using.  For example, if you have a Word doc and you have a table in your document, Word only lets you mark up column headers but does not let you mark up row headers.  That's a huge drawback (and is a flaw from Microsoft).  If you're a screen reader user and you are navigating vertically down a column in a table, there's no way to get the row header for that cell to be read as you navigate down.  After you generate a PDF, you can then edit the PDF and add tagging information for the table so that row headers are read, but again, that's a lot of work.  If that same table were rendered on an HTML page, it would be super easy to mark up the row headers.<br></div><div><br></div><div>I've seen some decently tagged PDF files that sound good with a screen reader but it was a huge effort to get it there.  The same information, when presented as a webpage, is so much more efficient and easier to make accessible.</div><div><br></div><div>The issue of ads and popups is somewhat separate from the page content itself.  I always run with ad blockers, but when a page refuses to show me the content if I have an ad blocker turned on, then I do as Deborah mentioned and use the browsers "reader" mode so that I only have the content.</div><div><br></div><div>So in general, making a website accessible is for the most part pretty easy and screen readers support webpage very well.  Making PDF accessible can be very difficult and until tagging information is added, it can be very hard to figure out a PDF using a screen reader.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 20, 2020 at 10:27 PM Amy Robasse <<a href="mailto:arobasse@cornellcollege.edu">arobasse@cornellcollege.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Glenn!<br>
<br>
Can you explain why html always wins out over a PDF? I work with a couple of blind students who struggle with accessing a lot of articles professors link to due to pop-ups, ads, and other barriers such as requiring a user to enter an email to view the whole article. Because of this they request any longer web articles to be converted to PDF. <br>
<br>
Is there something out there I am not aware of that would remove the barriers they are experiencing?<br>
<br>
Thanks!<br>
Amy<br>
_______________________________________________<br>
athen-list mailing list<br>
<a href="mailto:athen-list@mailman12.u.washington.edu" target="_blank">athen-list@mailman12.u.washington.edu</a><br>
<a href="http://mailman12.u.washington.edu/mailman/listinfo/athen-list" rel="noreferrer" target="_blank">http://mailman12.u.washington.edu/mailman/listinfo/athen-list</a><br>
</blockquote></div></div>